Rich Authorization Requests (RAR) Support#
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.
Introduction#
The OpenID for Verifiable Credential Issuance (draft 13) 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 specified
authorization_detailsparameter, used on OAuth 2.0 authorization requests, contains a JSON array. Each item on that array is a JSON object representing an authorization requirement. - Each JSON object must contain a
typestring field, identifying the authorization requirement being expressed. The remaining JSON object fields depend on thattypevalue.
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 13) is one of those specifications, defining:
- The
openid_credentialvalue for thetypefield. - The additional fields that may appear on an authorization detail JSON object of this type.
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.
[
{
"type": "openid_credential",
"format": "jwt_vc_json",
"credential_definition": {
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"credentialSubject": {
"given_name": {},
"last_name": {},
"degree": {}
}
}
},
{
"type": "openid_credential",
"format": "jwt_vc_json",
"credential_definition": {
"type": ["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:
- Request verifiable credentials with the format
jwt_vc_json, the typesVerifiableCredentialandUniversityDegreeCredential, as well as the optional claimsgiven_name,last_name, anddegree. - Request verifiable credentials with the format
jwt_vc_json, and the typesVerifiableCredentialandAlumniCredential.
The Curity Identity Server contains experimental support for the use of the authorization_details parameter on authorization requests using the code flow:
- The only supported
typeisopenid_credential, i.e., the type associated with verifiable credential issuance. - It is not yet possible to use the
authorization_detailsparameter on token requests. The authorization details associated to access tokens and refresh tokens are defined by theauthorization_detailsparameter used on authorization requests. - The introspection of access tokens and refresh tokens will now contain a representation of the authorization details associated to those tokens.
- The authorization details associated to access tokens will be taken into consideration when using those tokens on the Credential Endpoint.
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.
Currently, the Curity Identity Server experimental support for the RAR specification does not show the authorization details being requested on the user consent interface. This means the user is not able to see or deny the authorization details being requested, that is, the authorization details will be automatically consented to.