Add section on Authorization. Fix #204. #257
Conversation
|
Sorry but I still have problems with this wording, specifically "This specification does not contemplate such a usage (i.e. an authorization mechanism) of verifiable credentials". If you read the Use Cases document, you will that the use case invariably use VCs for authorisation purposes. Quote "From educational records to payment account access, the next generation of web applications will authorize entities to perform actions based on rich sets of credentials issued by trusted parties." So how we can assert that we do not contemplate that VCs will be used for authorisation when our use case document says they will be? This really is a Kafkaesque world. So lets be honest. We do envisage that VCs will be used for authorisation, but we recognise that additional controls will be needed in order to provide a fault proof authorisation framework built on top of the data model. If we are not to provide a full set of controls in V1 of the specification, then we need to say that this is what we have not done. (Rather than pretending that VCs will not be used for what we know they will be used for) |
index.html
Outdated
| It is arguable that <a>verifiable credentials</a> or | ||
| <a>verifiable presentations</a> should be used as authorization mechanisms | ||
| that a <a>holder</a> could use to access various | ||
| systems. This specification does not contemplate such a usage of verifiable |
There was a problem hiding this comment.
| systems. This specification does not contemplate such a usage of verifiable | |
| systems. This specification MUST NOT be considered an authorization framework on its own. |
There was a problem hiding this comment.
How about
Verifiable credentials are intended as a means of reliably identifying subjects. Whilst it is recognized that role based access controls (RBAC) and attribute based access controls (ABAC) rely on this identification as a means of authorizing subjects to access resources, this ?recommendation|specification? should not be used for authorization purposes without an accompanying authorization framework. This is because complex authorization issues such as delegation of authority are not addressed in this recommendation.
There was a problem hiding this comment.
@brentzundel only issue with your MUST NOT is that it's not testable and we try to not put RFC language on non-testable things. That said, my point is a nitpick and I'd like us to take a stronger position on it... so we could just put it in and remove the language if anyone complains.
index.html
Outdated
| <a>verifiable presentations</a> should be used as authorization mechanisms | ||
| that a <a>holder</a> could use to access various | ||
| systems. This specification does not contemplate such a usage of verifiable | ||
| credentials and MUST NOT be considered an authorization framework on its own. |
There was a problem hiding this comment.
| credentials and MUST NOT be considered an authorization framework on its own. |
msporny
force-pushed
the
msporny-authorization
branch
from
4e22b72 to
aeb8686
Compare
msporny
force-pushed
the
msporny-authorization
branch
from
aeb8686 to
072e6df
Compare
|
Applied both of @David-Chadwick and @brentzundel's suggestions. |
Preview | Diff