OID4VCI: Use of scopes and authorization details

[Torsten Lodderstedt]

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.

[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.

‌

[Kristina Yasuda]

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.

[Takahiko Kawasaki]

(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.

[Kristina Yasuda]

I think we can still add id - Issue #1922 has not been resolved.

[Kristina Yasuda]

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?

[Kristina Yasuda]

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..

[Mark Haine]

Migrated to GitHub

https://github.com/openid/OpenID4VCI