The OpenID for Verifiable Credential Issuance (draft 11) specification uses the authorization_details authorization request parameter, defined by RFC 9396 - OAuth 2.0 Rich Authorization Requests (RAR) specification, as a mechanism for a client/wallet to express detailed authorization information for verifiable credential issuance.
The RAR specification defines a generic mechanism based on the following ideas:
The RAR specification does not define concrete values for the type field.
Instead, those values must be defined by other specifications that use this generic framework.
The OpenID for Verifiable Credential Issuance (draft 11) is one of those specifications, defining:
The “Request Issuance of a Certain Credential Type using authorization_details Parameter” section in the verifiable credential issuance specification contains more information about the use of RAR in that context.
The following example illustrates a possible usage of RAR with credential issuance.
"types": ["VerifiableCredential", "UniversityDegreeCredential"],
"types": ["VerifiableCredential", "AlumniCredential"]
By using an authorization_details parameter with this value on an OAuth 2.0 authorization request, the client/wallet is requesting an access token that can be used on the Credential Endpoint to:
The Curity Identity Server contains experimental support for the use of the authorization_details parameter on authorization requests using the code flow:
When running the Curity Identity Server with the se.curity.verifiable-credentials.enable system property set to true, then the authorization_details authorization request parameter will be taken into consideration.
Using an array item with a type other than openid_credential will result in the rejection of the request.
When running the Curity Identity Server with the se.curity.verifiable-credentials.enable system property absent or set to false, then the authorization_details authorization request parameter will be ignored.
The Curity Identity Server support for the RAR specification (RFC 9396) is experimental and limited to the request of access tokens to be used for verifiable credential issuance.
This experimental RAR support augments the nonce, delegation, and token storage models with extra information, whose format may change in future releases of the Curity Identity Server in a way that is not backward compatible.
As a consequence, this feature should not yet be used in environments where long-term persistence and usage of nonces, delegations, and tokens is required, namely production environments.
Currently, the Curity Identity Server experimental support for the RAR specification does not show the authorization details being request on the user consent interface.
This means the user is not able to see or deny the authorization details being request, i.e., the authorization details will be automatically consented to.