Initial terminology #32
Conversation
concepts.md
Outdated
|
|
||
| Server hosting resources protected with [Web Access Control](https://github.com/solid/web-access-control-spec). | ||
|
|
||
| ## Resource Owner |
There was a problem hiding this comment.
note that in https://github.com/solid/web-access-control-spec#not-supported-by-design
WAC has no formal notion of a resource owner, and no explicit Owner access mode. For convenience/UI purposes, it may be assumed that Owners are agents that have Read, Write and Control permissions.
i personally think of a "Resource Owner" as being outside of what's represented in WAC, and might involve a business relationship with a resource server provider, or low-level out-of-band control of the resources (for example, with direct access to the storage filesystem with a Unix shell), that could grant the "owner" with administrative access even without acl:Control permission. or in other words, "a controller could remove their own control permission, but an owner could get it back".
i would like to propose formalizing this distinction, particularly since practical Pod providers will need a way for a Pod's "owner" to recover from ACL mistakes (which might not necessarily be by API and LDP manipulation of ACL resources). people today have locked themselves out of resources with NSS.
There was a problem hiding this comment.
For convenience/UI purposes, it may be assumed that Owners are agents that have Read, Write and Control permissions.
Having acl:Control one can always add other permissions for oneself, on the other hand having just the other permissions one can't add acl:Control, in practice it seems to boil down to that specific access mode.
i personally think of a "Resource Owner" as being outside of what's represented in WAC, and might involve a business relationship with a resource server provider.
Solid team has resources on github.com, some members have have owner access to them. I think we can consider them resource owners but it doesn't require any special relation to GitHub, Inc. Actually thinking of github, I may have only read permission and grant other clients access to those resources using OAuth2, in that case I would have Resource Owner role even though I only have read permission to that resource.
Maybe we shouldn't use this term all together and just use more verbose and precise constructs like User with control access, User with any access etc.
i would like to propose formalizing this distinction, particularly since practical Pod providers will need a way for a Pod's "owner" to recover from ACL mistakes (which might not necessarily be by API and LDP manipulation of ACL resources)
How about simply Resource Server admin? Keeping in mind that if someone offers it as service, they may have no WAC permissions to any of the resources.
concepts.md
Outdated
|
|
||
| ## User | ||
|
|
||
| Person identified with [WebID](https://www.w3.org/2005/Incubator/webid/spec/identity/). |
There was a problem hiding this comment.
Maybe "Agent" instead of "Person"? Since there can be autonomous agents with WebIDs that are not tied to a particular person.
There was a problem hiding this comment.
Good point, I think we still may need to distinguish Bots from People, we haven't touched delegation yet but in that approach some autonomous agent (aka Bot) would act on behalf of the person, so Bot would not stay listed in ACL but the person would delegate to it from one's own WebID Profile. I see that quite similar to granting permissions to applications, with possible difference that we may have application 'attended by the user and bot 'unattended'. Actually in #30 @jaxoncreed suggests requiring WebID for applications which might align things even further with delegated approach. Also in our Use Cases I included diagram and use case where application has local component and remote component, which we could consider a Bot.
Maybe we will leave User to mean person as it usually does and just add Agent, Application and Bot as additional concepts?
|
|
||
| The server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. | ||
|
|
||
| ## Solid detail |
There was a problem hiding this comment.
the subtitle Solid detail is a bit weird. I thought for a while reviewing this that this was a new term that you wanted to introduce. Given that there is only one sentence below perhaps there is no need to have a subsection.
Can't think of a better title right now...
There was a problem hiding this comment.
i made it wrong header level, but maybe i'll just make it a paragraph prefix instead to avoid confusion
|
|
||
| An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices). | ||
|
|
||
| ## Client Software [RFC7591] |
There was a problem hiding this comment.
That is too general. Client Software should not be a word that is tied to a particular authentication protocol.
I suggest OAuth client instead.
There was a problem hiding this comment.
This term comes directly from RFC7591, I think unless we find emerging consensus on not building on OAuth2 we should keep our terminology closely aligned. BTW I don't think I've seen it used anywhere in our conversations so it also doesn't seem to collide with existing use by someone meaning something else.
There was a problem hiding this comment.
RFC7591 is the OAuth Dynamic Client spec. So it makes sense that it uses the general term "Client Software" within the context of that spec. If you were to use that term in say the Internet Identity Workshop it would be very confusing, or look like you are choosing ahead of time what is being proposed.
There are many ways of doing identity, and we should not tie ourselves to one protocol through the vocabulary we use. This does not mean giving up on OAuth, it just makes it possible to speak about the other Identity protocols we are using or have been discussing such as WebID, HttpSig's keyId, or Credentials.
There was a problem hiding this comment.
In the overall context of these documents, the phrase "Client Software" is unlikely to always and only refer to "OAuth 2.0 Client Software", so I think it would be better to use the qualified label when the qualified meaning is intended.
In other words, change ## Client Software [RFC7591] to ## OAuth 2.0 Client Software [RFC7591]
|
Other terms I have found useful in the App Launcher Proposal
|
|
closing in favor of solid/authentication-panel#35 |
5 participants
This PR tries to capture some nuances in terminology encountered during today's call. Mainly calling user with
acl:Controlaccess mode to the resource as resource owner. It also clarifies concept of malicious user, some statements about proving identity of application seem not to relate to resource owner or not but to trusted or malicious user.I think we should consider clarifying those terms as ongoing process.