Experimental

Rich Authorization Requests (RAR) support¶

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_details parameter, 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 type string field, identifying the authorization requirement being expressed. The remaining JSON object fields depend on that type value.

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_credential value for the type field.
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.

Listing 168 Example of an authorization_details parameter value (line breaks and spacing added for readability).¶

[
  {
    "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 types VerifiableCredential and UniversityDegreeCredential, as well as the optional claims given_name, last_name, and degree.
Request verifiable credentials with the format jwt_vc_json, and the types VerifiableCredential and AlumniCredential.

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 type is openid_credential, i.e., the type associated with verifiable credential issuance.
It is not yet possible to use the authorization_details parameter on token requests. The authorization details associated to access tokens and refresh tokens are defined by the authorization_details parameter 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.

Caution

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.

Warning

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.