11. Implementation Considerations

11.1. Using authorization_details in a Certain Deployment

An ecosystem using this specification will define the type values and authorization detail types that are used and which extension fields are defined for each such type. Such a definition SHOULD include a JSON Schema (or other suitable formalism) for each such type value to facilitate validation by the AS and the client.

Authorization servers SHOULD publish the authorization_details_types_supported metadata parameter and declare supported type values for their deployment.

When deciding whether to use scope or authorization_details for a certain deployment or use case, the following considerations might be helpful:

• scope can be used for those use cases where every scope value conveys a unique meaning.
• authorization_details should be used if the privileges conveyed can be made granular by further authorization details.

Developers should not use both authorization data formats to specify the same kind of authorization data to limit complexity and avoid confusion.

11.2. Minimal Product Implementation

Systems desiring to implement only the most minimal functionality for RAR can do so by implementing a subset of features:

• A client MAY support only one specific type value and only the common data fields (Section 2.1) for that specific type.
• An AS MAY support only one specific type value and only the common data fields (Section 2.1) for that specific type.
• A Resource Server (RS) MAY check only the locations element against the resource indicator at the RS and MAY ignore other authorization_details content.

11.3. Size of Authorization Requests

In deployments that make use of this specification, the size of authorization requests is likely to increase due to the additional details being conveyed. Deployments should ensure that there is sufficient buffer space allocated in their systems to be able to handle the anticipated size increase. Authorization request URIs (e.g., in HTTP redirect bindings) may grow larger as the result of the content encoded in the authorization request. Systems implementers should configure their systems to be able to handle the anticipated size increases without causing errors at the client, AS, or any intermediate infrastructure components like proxies and caches.

As shown in Section 12, request integrity and confidentiality protection using [RFC9101] and [RFC9126] can also help to keep the size of the URL path component within bounds.