Meeting minutes
Introductions and announcements
ericP: no newcomer, no announcement
Action Items
https://
ericP: Hadrian is not here, so let's move on
… let's also cancel the use-case status as well
Discussion: Authorization
ericP: the plan was to give people a sense of how authorization differs from authentication
… we prepared some slides.
https://
… authentication is proving your identity
… authorization is when you get particular access to a particular resource
… could be "this person can access this resource", or "any doctor can access any of my health record"
… WAC is good for the former, it is simple and RDF-native
… ACP is a little more flexible, but still can't grant access to "health record" (only to a given resource or container)
… slide 3: important distinction between authorization by identity vs. by capability
… WAC and ACP do the first
… in the example above, I don't know who all the doctors are, I want to delegate that to another server
… that's authorization by capability
… ACP and WAC could do in principle do that (if I give the IRI of a group rather than a principal), but I don't know if that's implemented
jesse: in ACP, you can express a match based on claims in a verifiable credential
… but I'm not sure how widely it is implemented (ESS for sure, CSS apparently not)
<uvdsl> It is not part of the ACP spec :) there is just the acp:vc property, nothing more in the spec about that...
ericP: we need to understand what is currently possible, and what can someone expect from every implementation
… the more we require from every implementation, we higher the bar for implementers
… the less we require, the more burden on users and applications
… I'm not sure what Aaron wanted to get through with the "API Scope" item.
gibsonf1: we discussed this last week.
… An example of delegation was given: you see a doctor, and sign a for allowing anyone from the office to access your data.
… What prevents us from doing that with WAC, using the WebID of the *office*?
… What is odd to me is the idea that delegations can be further delegated, so that the initial user has no idea who has access.
… I'm not sure how capability are used in this context.
ericP: the idea of "by capability" is that the authorization server issues a claim that this person is indeed a member of this group.
… you suggest to use the WebID of the group instead right?
gibsonf1: that's what we do: we have a hierarchy of groups, and we can use any node of the hierarchy in WAC.
jesse: so gibsonf1, on your server you have a declaration of this hierarchy?
gibsonf1: no, we are simply using standard WebID lookup
dmitri: making a parallel with Google Docs: you can share with specific individuels (by identity) or set up that anybody with the link can view (by capability).
… and both are possible.
… Another aspect is being able to identify clients, not just principles.
… One common critique of identity-based authorization is that your app runs as your user.
… This is not new to solid, it was a challenge of the 70's mainframes, where any application had access to all the files of the user.
… Capabilities provide guardrails in a world of standalone services that the use delegates to.
gibsonf1: capability effectiveky is public access with a restricted context of action, right?
<Zakim> gibsonf, you wanted to ask about delegation
dmitri: no, it can do that, but that's not the essential part.
… capabilities allow you to have flexible social access control, e.g. "anyone with the link can edit this doc"
… with the social contract that if you have the link, you should not share it with other people
… but the capabilities do not have to be public access
<Zakim> uvdsl, you wanted to ask about "API scope"
uvdsl: I wanted to ask about "API Scope", did we reach that?
ericP: we did, but I'm not sure what Aaron meant by that...
jesse: from the discussions I had with Aaron, I think he thinks of @@
uvdsl: I'm still confuse about the values in this row
jesse: my guess is that in "by identity", you need to describe what kind of authentication protocol you use
… while in "by capability", you need to describe the format of the token you present to the authorization server
… In theory, the server that issues the access grant can be distinct from your authorization server and your resource server.
… you only need to prove that you have the capability, not a specific authorization
uvdsl: but the resource server needs to be able to understand the structure of the token, and becomes an authorization server
… I thought that the point of an authorization server was to decouple the two
… not arguing against the whole idea of capability
dmitri: access token and authorization mechanism vary for may implementation details
… I claim that we need both
<Zakim> ryey, you wanted to comment on the word "capability": intuitively to me, "things are possible / promised to the data consumer" (i.e. "capable") are "capability"; so what alternative terms should be used for that
ryey: intuitively, "capability" means "being able to do something", so related to functionality
… but in the examples provided, "capability" seems to be a verifiable token
… I see value in being able to describe a client's "ability".
dmitri: the term "by capability" has been used for a long time, by you are right, it means more in English than in this particular case
pchampin: is it true that auth by ID could be modeled as a subset of auth by capability (taking into account that "capability" is scoped)?
pchampin: I assume that "by identity" could be thought as a subset of "by capability"?
dmitri: its tempting to see it that way, but that's not the case
… the important difference is who holds the authorization knowledge
<Zakim> gibsonf, you wanted to ask about "simple" capability at Authorization vs resource server
gibsonf1: on uvdsl's point about the resource server needing to think harder
… ultimately the resource needs to know what it can deliver; assuming that it can trust the authorization server, a simple message from the authorization server to the resource server telling it "this is what you should deliver" should do the trick, right?
ericP: the resource server still needs to understand the token it gets
gibsonf1: what would happen if the ACL were on the authorization server side?
uvdsl: on that topic I hard dmitri say that there is not always an authorization server, but only a server delivering a token
… for a future discussion, probably
dmitri: the resource server and authorization server blend at some point, this is mostly an implementation detail
uvdsl: we should define what we expect from such each conceptual role
… re. pchampin's question, about capability being a superset of identity
… could I just not write myself a ticket
Dmitri: in low risk situation (e.g. movie ticket) we use capability alone
… in high risk situation (e.g. plane ticket) we use both (you need the ticket, and *also* to prove your identity)
uvdsl: so capability is not about proving identity, but also proving other things
dmitri: yes
<uvdsl> in particular, it is not tied to defining the structure of a access token
ericP: this is a complicated topic with a lot of terminology
… Dmitri, any idea of homework for us?
<uvdsl> we could define a structure of an access token for identity-based authorization
<uvdsl> and for capability-based authorization that is required
Dmitri: can't think of any off the top of my head, but my advice would be to read through the OAuth2 specification
… that helps set a baseline
<ericP2> homework: read OAuth2 spec
https://
<ericP2> pchampin: UC&R doc has a glossary
https://
<ericP2> ... we should make sure it meets our conversation needs here
pchampin: next week is ESWC, probably several people from this group will be there
<ericP2> uvdsl: requrest no important decisions be resolved while folks are at ESWC next week