Expand section 2 - Concepts. #44
Conversation
dmitrizagidulin
force-pushed
the
concepts
branch
from
a322f34 to
53a24b7
Compare
dmitrizagidulin
force-pushed
the
concepts
branch
from
53a24b7 to
bc36ebc
Compare
| apps, desktop apps, constrained apps and IoT devices. | ||
| - Clients that have their own identity (bots/services) vs clients that are | ||
| always “piloted” by a user (apps) | ||
| - “Attended” vs “Unattended” clients |
There was a problem hiding this comment.
Could you provide a description of what his is? Is this not a repeat of the bullet above?
|
|
||
| - By deployment type: Server-side web apps, in-browser JS web apps, mobile | ||
| apps, desktop apps, constrained apps and IoT devices. | ||
| - Clients that have their own identity (bots/services) vs clients that are |
There was a problem hiding this comment.
Earlier sections suggest that both the user and the client have distinct identity. This section seems to either try to touch (attended / unattended) topic solid/authorization-panel#38 or suggests that bots/services don't need to act on behalf of any user and sometimes themselves stay considered as a user.
| (whenever technically possible) a tuple of: *(controller id, client id)*. To | ||
| put it another way, for any given action (such as an [authenticated | ||
| request]() to a data store), the access control mechanism needs to know _who_ | ||
| performed the action, and _what software/client_ they were using to perform |
There was a problem hiding this comment.
Can we formulate it in a way which doesn't suggest that client needs to always be attended by the user when making requests. In case of a bot it can make requests on behalf of the user any time, similar some server-side client which periodically checks for updates or even uses subscription mechanism to listen for changes. Nowadays even on device clients can use background-sync to make requests when they detect connectivity available but user may not attend those actions at that moment.
In spirit of considering OAuth2 a delegation framework, I would like to consider expressing both attended and unattended client activities as. client acting on behalf of a user so we get something like:
the access control mechanism needs to know what client (always a software) performs the request and on behalf of who (always a user) that client performs the request.
|
Closing this PR. The main panel spec has moved in a different direction. |
Part of ongoing implementation of https://github.com/solid/specification/issues/74