[Feature] Explore the use of RFC 9396 Rich Authorization Requests (RAR) to support multiple purposes

[jpengar]

Problem description

Currently, the CAMARA framework simplifies consent management by restricting an authorization request to a single purpose. As detailed in the CAMARA Security Interoperability documentation, this is enforced by requiring the client to provide the purpose as a dedicated scope value, which MUST follow the format dpv:<dpvValue>. The specification explicitly states that there MUST be exactly one such purpose scope per request.

Possible evolution

This issue proposes an exploration into integrating OAuth 2.0 Rich Authorization Requests (RAR), as defined in RFC 9396, into the CAMARA Identity and Consent Management.

The primary goal is to leverage the authorization_details parameter to allow clients to request access to different sets of scopes, with each set being associated with a specific purpose. This would enable a single authorization request to specify granular access needs, for instance, requesting access to a user's location for dpv:FraudPreventionAndDetection and to manage quality on demand sessions for dpv:RequestedServiceProvision within the same transaction. The granted purpose for each scope or group of scopes should then be reflected in the resulting access token.

To ensure a comprehensive implementation, we have identified several key points that require discussion and definition by the Working Group:

1. Standard authorization_details Type(s):

   • We need to define one or more standard type values for the authorization_details objects that will be supported by CAMARA Authorization Servers. A minimal viable approach would be a type that allows specifying a list of scopes and a single purpose.

2. JSON Schema Definition:

   • A clear and robust JSON schema must be defined for the custom type(s) we introduce. This will ensure interoperability and proper validation. A starting point could be an object per purpose, containing an array of corresponding scopes.

3. Coexistence of scope and authorization_details:

   • Should clients be allowed to use both the scope and authorization_details parameters in the same authorization request? We need to define the expected behavior and potential precedence rules if both are present.

4. Error Handling:

   • We must specify the behavior for error scenarios related to authorization_details, such as the invalid_authorization_details error. This includes cases like:
     • Requesting the same scope under different purpose values in a single request.
     • Using an unsupported purpose or a malformed structure.

5. Partial Authorization:

   • How should the Authorization Server handle requests where only a subset of the requested authorization_details is granted by the user or the server? The mechanism for communicating the granted permissions back to the client needs to be clearly defined.

6. Refresh Token Behavior:

   • What is the expected behavior when a refresh token is used to obtain a new access token? If the authorization_details associated with the original grant have changed, how should this be handled?

7. Integration with Different Grant Types:

   • The implementation of authorization_details needs to be considered across all relevant flows, including:
     • Authorization Code and CIBA flows: as a parameter in the authorization request.
     • Client Credentials: as a parameter in the token request.
     • JWT Bearer Grant: as a top-level claim within the JWT assertion.
   • Signed authentication requests using authorization_details MUST also be considered.

8. Pushed Authorization Requests (PAR - RFC 9126):

   • Given that authorization_details can significantly increase the size of the authorization request, should we consider recommending or requiring the use of PAR (RFC 9126) to pass these parameters securely and reliably?

9. Token Response and Introspection:

   • The authorization_details granted by the server should be included in the token response. Furthermore, the token introspection endpoint must be updated to return the granted authorization_details associated with the access token.

10. Server Metadata:

    • Should publishing the supported authorization_details_types_supported in the Authorization Server's metadata be mandatory?

However, for some of the above topics, CAMARA may rely directly on RFC9396 without further definitions. We look forward to receiving feedback from the Working Group on these points, which will help us to shape the direction of this feature.

Alternative solution

N/A

Additional context

• https://github.com/camaraproject/IdentityAndConsentManagement/blob/main/documentation/CAMARA-Security-Interoperability.md#purpose
• Consider allowing multiple purpose-scope combinations in the API request ConsentInfo#11 The idea is to come up with a common solution that is valid not only for authentication requests, but also for consent info API requests. For example, use the same format in both cases to declare multiple combinations of scope(s) and purpose(s).