search

openid / oid4vc-haip-sd-jwt-vc

High Assurance Profile of OID4VP and OID4VCI using SD-JWT VC and mdocs that is privacy preserving, secure, and meets regulatory requirements
29 stars 7 forks source link

Clarify the use of Authorization Details (RAR) #93

Open c2bo opened 9 months ago

c2bo commented 9 months ago

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

We should consider to support RAR (in addition to scopes) which is the path I would prefer or remove the example.

Sakurann commented 8 months ago

the intent was to mandate scopes for the sake of interop. so we should discuss adding RAR, but the first step is probably to remove the examples defined in section 7.2.4

tlodderstedt commented 8 months ago

yes we should discuss this.

as far as I remember, we assumed scopes would be easier to use. From an interop standpoint, I think RAR is the more direct approach as the wallet can directly use the types etc as defined by issuer or standards body for a certain credential without the need to negotiate scopes (in advance or ad-hoc through issuer metadata).

yaron-zehavi commented 8 months ago

Dears, Please consider supporting both scopes and rar, for different uses (not both used together to denote required presentation_definition). For example in a payment approval journey, the verifier might request presentation of payment method credentials (card, account, etc) while also adding to the request the specific payment details for approval

c2bo commented 8 months ago

Dears, Please consider supporting both scopes and rar, for different uses (not both used together to denote required presentation_definition). For example in a payment approval journey, the verifier might request presentation of payment method credentials (card, account, etc) while also adding to the request the specific payment details for approval

I was coming from a similar use-case, +1 from me to consider adding RAR