oid4vc-haip-sd-jwt-vc
oid4vc-haip-sd-jwt-vc copied to clipboard
openid
Use of scopes and authorization details
Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1981
Original Reporter: tlodderstedt
I would like to start a discussion whether we need two mechanisms to control the authorization for requesting the issuance of credentials.
We currently have the scope and the authorization_details parameter.
The only advantage I see with scopes is the fact they can be used to authorize issuance of multiple credentials at once (with PR #520), but this requires a metadata structure to map scope values to credential type definitions. In average the meaning of a scope is defined someplace outside of the protocol, which is not machine readable and makes its semantics ambiguous. Also, a wallet cannot request a credential without a scope value being defined in advance.
The authorization details allow the wallet to specify the credentials it wants to obtain just based on the data usually used for a certain format (without the need for further metadata structures). It is explicit and transparent about the credentials being requested, which is a good basis for interoperability in my experience.
I don’t buy the argument scopes are needed to keep things simple. authorization details might be more verbose but for the average use case, the string always looks the same and just needs to be copied and pasted (like scope values).
I think my personal preference is clear, I think authorization details are sufficient.
Imported from AB/Connect bitbucket - Original Commenter: pedro-felix
My current opinions on this subject:
-
Scopes are the original mechanism to express authorization requirements on OAuth 2.0, while RAR is a more recent non-mandatory mechanism. While RAR may provide more flexibility and expressiveness, I believe it is possible to also use scopes successfully in VCI scenarios. Due to this, I think that making RAR mandatory is an Authorization Server “barrier to entry” that is not strictly necessary for VCI.
- By not allowing for scopes on the metadata we are in practice making RAR mandatory, since most wallets will not have any way of obtaining the scopes in an out-of-band way (i.e. without using issuer metadata or credential offer).
-
PR-520 makes scope in the metadata optional, so it is perfectly OK for an AS/Issuer to only use RAR and completely ignore scopes, without any added complexity on the AS/Issuer side. I.e. we are not making the live of the AS/Issuer harder by allowing for scopes on the VCI spec. The only exception to this is the use of scopes as the by-reference mechanism on credential offer, which does require scopes (personally I preferred the offer string to be the credential_supported id and not the scope).
-
By supporting scopes I don’t think we are making the VCI spec more fragile from a security perspective. Before RAR, scopes (and the OIDC claims request parameter) were the way AS have used to express authorization requirements.
-
By supporting scopes we are indeed making wallets a bit more complex, since they now do need to support both RAR and scopes. However I believe the added complexity is small and is worthwhile given the reduced barrier to entry on the AS side. Even so, it would be important to gather some feedback from wallet authors on this added complexity.
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda
I am not comfortable removing scope option.
To reiterate on what I have already put in PR #520. Mandating RAR increases implementation barrier - not every single implementation can flexibly add support to RAR or a new authz req parameter like Taka was suggesting in the PR, especially when an existing AS is being re-used. When an AS handles billions of transactions a day, any new parameter is a breaking change and is very hard to enforce.
No one is mandating the use of scopes.
Imported from AB/Connect bitbucket - Original Commenter: authlete-taka
(personally I preferred the offer string to be the credential_supported id and not the scope)
Really. Adding scope would have been acceptable as an optional feature if id had not been replaced with scope.
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda
I think we can still add id - Issue #1922 has not been resolved.
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda
I don’t buy the argument scopes are needed to keep things simple. authorization details might be more verbose but for the average use case, the string always looks the same and just needs to be copied and pasted (like scope values).
I also do not understand this - authorization_details is an object, not a string..? you mean URL encoded authorization_details?
Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda
noting number of recent requirements around server-to-server (organization to organization) issuance/presentation flows using client_credentials grant, where scopes are used to communicate required credentials..
labeling this as 1.0 because if we decide one way or the other in the spec, it better be done in 1.0 to prevent the situation where 1.1 implementation is not interoperable with 1.0 implementations that did not support an option that was optional but is now mandatory?
currently, HAIP mandates scopes https://openid.github.io/oid4vc-haip/openid4vc-high-assurance-interoperability-profile-wg-draft.html#section-4.1-1.2 HAIP is probably a better place to make authorization_details mandatory. and we should probably keep both optional in VCI?
duplicate of #93. but copying here too:
Section 4.2 states:
MUST use the scope parameter to communicate credential type(s) to be issued. The scope value MUST map to a specific Credential type. The scope value may be pre-agreed, obtained from the Credential Offer, or the Credential Issuer Metadata.
which mandates scopes and does not allow RAR to be used. Later on, section 7.2.4 explains Authorization Details to be used with SD-JWT VCs:
The following additional claims are defined for authorization details of type openid_credential and this Credential format. [..]