]> Raiffeisen Bank International

yaron.zehavi@rbinternational.com

Security Web Authorization Protocol RAR Step-up oauth OAuth 2.0 Rich Authorization Requests (RAR) , standardizes the exchange and processing of authorization details but does not define metadata to describe authorization details types. The document addresses a practical interoperability challenge regarding metadata of authorization details types, allowing clients tp dynamically discover metadata instead of relying on out-of-band agreements. It also standardizes error signaling, in case insufficient RAR was provided and offers structured ways of remediation. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction OAuth 2.0 Rich Authorization Requests (RAR) allows OAuth clients to request detailed and structured authorization, enabling advanced authorization models across domains such as banking and healthcare. However, RAR does not specify how clients discover metadata describing valid authorization details objects. Such metadata and documentation are obtained out-of-band. This document defines:

• A new authorization server endpoint: authorization_details_types_metadata_endpoint, providing metadata for authorization details types, including documentation and JSON Schema definitions .
• Adds required authorization details types to OAuth 2.0 Protected Resource Metadata response.
• A new normative OAuth 2.0 WWW-Authenticate Error Code, for resource servers to indicate insufficient_authorization_details as the cause of error.
• An OPTIONAL response body that MAY accompany the insufficient_authorization_details error, providing an informative and actionable authorization details object. This object can be used directly in a follow-up OAuth request.
• RECOMMENDED handling of large RAR authorization details objects when issuing JWT access tokens, to avoid failures due to token sizes exceeding header size restrictions.

The optional providing of actionable authorization details objects by resource servers enables:

• Simplification for clients who can directly remediate without learning to construct valid authorization details objects.
• Support for ephemeral, interaction-specific claims from resource server, such as for example a risk profile or an internal interaction identifier, guiding authorization servers on required authentication strength and consent flows.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Protocol Overview There are two main proposed flows:

• Client remediates using metadata of required authorization details types.
• Client remediates using actionable authorization details objects provided by resource server.

Client remediates using metadata of required authorization details types | Resource | (A) User +---| | | Server | Starts| | |<----------------------| | Flow +-->| | (C) 403 Forbidden +---------------------+ | | WWW-Authenticate: Bearer | | error="insufficient_authorization_details", | | resource_metadata="[resource metadata url]" | | : | | Resource +---------------------+ | | (D) Metadata Request | Resource Server | | |---------------------->|+-------------------+| | | || Resource Metadata || | Client |<----------------------|| Endpoint || | | (E) Metadata Response |+-------------------+| | | (Discover also +---------------------+ | | expected RAR types) | | : +---------------------+ | | RAR Types | Authorization | | | (F) Metadata Request | Server | | |---------------------->|+-------------------+| | | || RAR Types || | |<----------------------|| Metadata Endpoint || | | (G) Metadata Response |+-------------------+| | | : | | | | (H) Construct RAR | | | | Using Metadata | | | | : | | | | (I) Authorization | | | | Request + RAR | | | |---------------------->|+-------------------+| | | || Authorization || | |<----------------------|| Endpoint || | | (J) Authorization Code|| || | | : |+-------------------+| | | : | | | | (K) Token Request |+-------------------+| | |---------------------->|| || | | || Token Endpoint || | |<----------------------|| || | | (L) Access Token |+-------------------+| | | : +---------------------+ | | : | | (M) API Call with | | Access Token +---------------------+ | |---------------------->| | | | | Resource Server | | |<----------------------| | | | (N) 200 OK + Resource +---------------------+ | | +----------+ ]]> Figure: Client remediates using metadata of required authorization details types

• (A) The user starts the flow.
• (B) The client calls an API with an access token.
• (C) Resource server returns HTTP 403 Forbidden including a WWW-Authenticate header with error code insufficient_authorization_details and the resource metadata url (OAuth 2.0 Protected Resource Metadata ).
• (D-E) The client discovers expected authorization details types from resource metadata endpoint's response.
• (F-G) The client consumes authorization details types metadata from authorization server's authorization_details_types_metadata_endpoint.
• (H-I) The client constructs a valid authorization details object and makes an OAuth + RAR request.
• (J) Authorization server returns authorization code.
• (K-L) The client exchanges authorization code for access token.
• (M) The client makes an API request with the (RAR) access token.
• (N) Resource server validates access token and returns successful response.

Client remediates using actionable authorization details objects provided by resource server | Resource | (A) User +---| | | Server | Starts| | |<----------------------| | Flow +-->| Client | (C) 403 Forbidden +--------------------+ | | WWW-Authenticate: Bearer | | error="insufficient_authorization_details", | | resource_metadata="[resource metadata url]" | | + | | HTTP body provides authorization_details | | : | | : +--------------------+ | | : | Authorization | | | (D) Authorization | Server | | | Request + RAR |+------------------+| | |---------------------->|| || | | || Authorization || | |<----------------------|| Endpoint || | | (E) Authorization Code|| || | | : |+------------------+| | | : | | | | (F) Token Request |+------------------+| | |---------------------->|| || | | || Token Endpoint || | |<----------------------|| || | | (G) Access Token |+------------------+| | | : +--------------------+ | | : | | : | | (H) Retry API Call +--------------------+ | | with Token | | | |---------------------->| Resource | | | | Server | | |<----------------------| | | | (I) 200 OK + Resource +--------------------+ | | +----------+ ]]> Figure: Client remediates using actionable authorization details objects provided by resource server

• (A) The user starts the flow.
• (B) The client calls an API with an access token.
• (C) Resource server returns HTTP 403 Forbidden including a WWW-Authenticate header with error code insufficient_authorization_details and in the response body includes the required authorization details objects.
• (D) The client uses the obtained authorization details objects in a new OAuth + RAR request.
• (E) Authorization server returns authorization code.
• (F-G) The client exchanges authorization code for access token.
• (H) The client makes an API request with the (RAR) access token.
• (I) Resource server validates access token and returns successful response.

OAuth 2.0 Protected Resource Metadata This document specifies a new OPTIONAL metadata attribute: authorization_details_types_required, to be included in the response of OAuth Protected Resource Metadata .

"authorization_details_types_required":

RECOMMENDED. a JSON object that conforms to the syntax described in for a required types expression.

The following is a non-normative example response with the new authorization_details_types_required attribute: Note: When resource servers accept access tokens from several authorization servers, clients can discover which authorization details types each authorization server supports.

Required types expression syntax The following JSON syntax defines a required types expression that describes permitted combinations of required authorization_details types. This expression allows selection operators (oneOf, allOf) and boolean composition (and, or) to be combined in a predictable manner. A required types expression is a JSON object whose top-level claims MUST contain exactly one of the following attributes:

• and
• or
• oneOf
• allOf

Attributes definition:

"and":

OPTIONAL. a non-empty JSON array of required types expressions. When and is specified, the expression is satisfied if all contained expressions are satisfied.

"or":

OPTIONAL. a non-empty JSON array of required types expressions. When or is specified, the expression is satisfied if at least one contained expression is satisfied.

"oneOf":

OPTIONAL. a non-empty JSON array of strings identifying authorization_details types. When oneOf is specified, the expression is satisfied if exactly one of the listed types is present.

"allOf":

OPTIONAL. a non-empty JSON array of strings identifying authorization_details types. When allOf is specified, the expression is satisfied if all of the listed types are present.

Required types expression examples

Example expression using "and" operator Specifies that the selection MUST include a and b, and one of c or d.

Example expression using "or" operator Specifies that the selection MUST include either c and d, or one of a or b.

Authorization Details Types Metadata Endpoint The following authorization server metadata parameter is introduced to signal the server's support for Authorization Details Types Metadata:

"authorization_details_types_metadata_endpoint":

OPTIONAL. The URL of the Authorization Details Types Metadata endpoint.

Authorization Details Types Metadata Endpoint Response The Authorization Details Types Metadata endpoint's response is a JSON document with the key authorization_details_types_metadata whose attributes are authorization details type identifiers. Each identifier is an object describing a single authorization details type. Attributes definition:

"version":

OPTIONAL. String identifying the version of the authorization details type definition. The value is informational and does not imply semantic version negotiation.

"description":

OPTIONAL. String containing a description of the authorization details type. Clients MUST NOT rely on this value for authorization or validation decisions.

"documentation_uri":

OPTIONAL. URI referencing external documentation describing the authorization details type.

"schema":

The schema attribute contains a JSON Schema document that describes a single authorization details object. The schema MUST validate exactly one authorization details object and MUST restrict the type attribute to the corresponding authorization details type identifier. This attribute is REQUIRED unless schema_uri is specified. If present, schema_uri MUST NOT be included.

"schema_uri":

The schema_uri attribute is an absolute URI, as defined by RFC 3986 , referencing a JSON Schema document describing a single authorization details object. The referenced schema MUST satisfy the same requirements as the schema attribute. This attribute is REQUIRED unless schema is specified. If this attribute is present, schema MUST NOT be present.

"examples":

OPTIONAL. An array of example authorization details objects. Examples are non-normative.

See Examples for non-normative response example.

Resource Server Error Signaling of insufficient authorization_details This document defines a new error code in the OAuth 2.0 WWW-Authenticate Error Code Registry, insufficient_authorization_details, which resource servers SHALL return using the WWW-Authenticate header, to signal access is denied due to missing or insufficient authorization details. Example HTTP response:

OPTIONAL authorization_details in response body Resource server MAY include, alongside the insufficient_authorization_details error, an informative HTTP response body with content type application/json containing the required authorization details objects needed to satisfy the failing request. Note:

• The audience of authorization details objects provided by a resource server in an error response is its trusted authorization servers, as advertised by the Resource Server’s metadata endpoint.
• Resource servers SHOULD provide authorization_details objects only if all trusted authorization servers accept the authorization details type used.

HTTP response body definition:

"authorization_details":

OPTIONAL. Array of authorization details objects, matching the format specified in RAR for the authorization_details request parameter.

"authorization_hint":

RECOMMENDED. String serving as a stable reference, enabling the client to select existing access tokens linked to authorization details objects without having to understand RAR object semantics. Its value SHALL be identical for semantically equal authorization_details and it SHALL NOT be returned in case tokens resulting from provided authorization_details are single-use only.

Clients MAY use the provided authorization_details in a subsequent OAuth request to obtain an access token satisfying the resource's requirements. Example resource server response with OPTIONAL authorization_details:

Handling large RAR objects when issuing access tokens RAR section 9 instructs that authorization servers MUST provide approved RAR objects to resource servers for enforcement. The authorization server MAY add the authorization_details attribute to access tokens in JSON Web Token (JWT) format or to token introspection responses. Including large RAR objects in JWT access tokens may cause interoperability loss due to token sizes exceeding header size restrictions. Authorization servers SHOULD support a configurable maximum approved RAR objects size threshold (in bytes). If the size exceeds this threshold, JWT access tokens SHALL NOT include the authorization_details claim; instead, approved authorization details will be accessed via token introspection .

Processing Rules

Client Processing Rules

• When receiving error insufficient_authorization_details, if response body contains an authorization_hint claim that matches a valid token in client's possession, client SHOULD retry calling the failing endpoint using the matching token.
• If the response body contains an authorization_details claim, the client MAY include it in a subsequent OAuth request to obtain a token, which it MAY then use to retry the failing endpoint.
• Otherwise, the client MAY consult metadata:
  • Fetch resource metadata to discover accepted authorization servers and required authorization_details types.
  • Fetch authorization server metadata to discover authorization_details_types_supported.
  • Fetch authorization server's authorization_details_types_metadata_endpoint to obtain authorization details type metadata and schemas.
  • Locate schema or retrieve schema_uri.
• Construct authorization details conforming to the schema and include in subsequent OAuth request to obtain a token with which it MAY retry calling the failing endpoint.

Resource Server Processing Rules

• Advertise in resource metadata authorization_details_types_required, where relevant.
• Verify access tokens against required authorization details.
• If insufficient, the resource server MUST return HTTP 403 with WWW-Authenticate: Bearer error="insufficient_authorization_details".
• OPTIONALLY provide also an HTTP body with an informative actionable authorization_details object.

Security Considerations

Cacheability and Intermediaries HTTP 403 responses with response bodies may be cached or replayed in unexpected contexts. Recommended mitigation is resource servers SHALL use Cache-Control: no-store response header.

Confidentiality of resource server provided authorization_details Resource server providing actionable authorization_details SHOULD NOT include sensitive data within them. This is consistent with RAR authorization_details OAuth request parameter, representing request semantics. Confidentiality-preserving authorization_details types SHOULD NOT include sensitive data. Instead, end-user SHALL provide such information when interacting with the authorization server. Alternatively, authorization_details MAY refer to specific end-user resources using opaque reference handles (e.g "account_1a" instead of using explicit IBAN).

IANA Considerations

OAuth 2.0 WWW-Authenticate Error Code Registry

Error Code	Description
insufficient_authorization_details	The request is missing required authorization details or the provided authorization details are insufficient.

OAuth Metadata Attribute Registration The metadata attribute authorization_details_types_metadata_endpoint is defined for OAuth 2.0 authorization server metadata as a URL. The metadata attribute authorization_details_types_required is defined for OAuth 2.0 protected resource metadata .

Normative References A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This specification defines a method for a protected resource to query an OAuth 2.0 authorization server to determine the active state of an OAuth 2.0 token and to determine meta-information about this token. OAuth 2.0 deployments can use this method to convey information about the authorization context of the token from the authorization server to the protected resource. This specification defines a metadata format that an OAuth 2.0 client can use to obtain the information needed to interact with an OAuth 2.0 authorization server, including its endpoint locations and authorization server capabilities. This document specifies a new parameter authorization_details that is used to carry fine-grained authorization data in OAuth messages. This specification defines a metadata format that an OAuth 2.0 client or authorization server can use to obtain the information needed to interact with an OAuth 2.0 protected resource. IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.

Examples This section provides non-normative examples of how this specification may be used to support specific use cases.

Authorization Server Metadata Examples

Example authorization_details_types_metadata_endpoint response with Payment Initiation

Example authorization_details_types_metadata_endpoint response for the Norwegian Health Sector (HelseID)

Protected Resource Metadata Examples

Example Protected Resource Metadata response of payments resource

Example Protected Resource Metadata response from the Norwegian Health Sector (HelseID)

Payment initiation with RAR error signaling

Client initiates API request Client uses access token obtained at login to call payment initiation API

Resource server signals insufficient_authorization_details with actionable RAR object Resource server requires payment approval and responds with: Note: the resource server has added the ephemeral attributes interaction_id and risk_profile.

Client initiates OAuth flow using the provided authorization_details object After user approves the request, client obtains an access token representing the approved payment

Client re-attempts API request

Resource server authorizes the request

Document History -03

• Added authorization_hint to guide client on token selection and updated client processing rules accordingly
• Added security consideration on confidentiality of RS-provided authorization_details
• Added authorization server considerations for handling large RAR objects in JWT access tokens

-02

• Defined the required types expression
• Added Protected Resource Metadata examples

-01

• Authorization details moved to HTTP body and made OPTIONAL
• Metadata pointer from resource metadata url, full authorization details types metadata on authorization server new endpoint

-00

• Document creation

Acknowledgments The authors would like to thank the following individuals who contributed ideas, feedback, and wording that helped shape the final specification: Rune Grimstad.