Web Authorization Protocol Y. Zehavi Internet-Draft Raiffeisen Bank International Intended status: Standards Track 4 July 2026 Expires: 5 January 2027 OAuth 2.0 RAR Metadata and Error Remediation draft-zehavi-oauth-rar-metadata-05 Abstract OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] standardizes the exchange and processing of authorization details but does not define metadata for describing authorization details types. In addition, no interoperable guidance is offered to clients, to remediate failures by resource servers due to insufficient authorization details. This document addresses this interoperability challenge, allowing clients to dynamically discover metadata instead of relying on out- of-band agreements, as well as standardizes failure signaling including interoperable remediation when insufficient authorization details are the cause of failure. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://yaron- zehavi.github.io/oauth-rich-authorization-requests-metadata/draft- zehavi-oauth-rar-metadata.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-zehavi-oauth- rar-metadata/. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/. Source for this draft and an issue tracker can be found at https://github.com/yaron-zehavi/oauth-rich-authorization-requests- metadata. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Zehavi Expires 5 January 2027 [Page 1] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 5 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Remediation of failures due to insufficient authorization . . 6 5. Authorization Details Types Metadata Endpoint . . . . . . . . 9 6. RAR objects in JWT access tokens . . . . . . . . . . . . . . 10 7. Processing Rules . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Client Processing Rules . . . . . . . . . . . . . . . . . 10 7.2. Resource Server Processing Rules . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8.1. Confidentiality of resource server provided authorization_details . . . . . . . . . . . . . . . . . . 11 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 9.1. OAuth 2.0 WWW-Authenticate Error Code Registry . . . . . 12 9.2. OAuth Authorization Server Metadata Registry . . . . . . 12 10. Normative References . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 A.1. Authorization Server Metadata Examples . . . . . . . . . 13 A.1.1. Example authorization_details_types_metadata_endpoint response with Payment Initiation . . . . . . . . . . 13 Zehavi Expires 5 January 2027 [Page 2] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 A.1.2. Example authorization_details_types_metadata_endpoint response for the Norwegian Health Sector (HelseID) . 15 Appendix B. Document History . . . . . . . . . . . . . . . . . . 21 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction OAuth 2.0 Rich Authorization Requests (RAR) [RFC9396] allows OAuth clients to request detailed and structured authorization, enabling advanced authorization models across domains such as banking and healthcare. However, RAR [RFC9396] 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 authorization details type metadata, including documentation and JSON Schema definitions [JSON.Schema]. * A new normative OAuth 2.0 WWW-Authenticate Error Code, for resource servers to indicate insufficient_authorization as the cause of the error. * A new OAuth 2.0 WWW-Authenticate response parameter, authorization_remediation, which contains actionable authorization details objects, to be used directly for remediation in a follow- up OAuth request. * Authorization server considerations for when RAR authorization details objects should perhaps be omitted from JWT access tokens and provided instead through token instrospection. Providing clients with actionable authorization details objects enables: * Interoperability benefit as clients can simply and directly proceed to remediate, without first learning how to construct valid authorization details objects. * Support for ephemeral, interaction-specific attributes included by the resource server, such as a risk profile or an internal interaction identifier, guiding authorization servers on the required authentication strength and consent flows. Zehavi Expires 5 January 2027 [Page 3] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Protocol Overview Client remediates using actionable authorization details objects provided by resource server: Zehavi Expires 5 January 2027 [Page 4] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 +--------------------+ +----------+ (B) API Request | | | |---------------------->| Resource | (A) User +---| | | Server | Starts| | |<----------------------| | Flow +-->| Client | (C) 401 Unauthorized +--------------------+ | | WWW-Authenticate: Bearer | | error="insufficient_authorization", | | error_description=[human readable message], | | authorization_remediation=[required | | 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. Zehavi Expires 5 January 2027 [Page 5] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 * (C) Resource server returns HTTP 401 with a WWW-Authenticate header with error code insufficient_authorization and in authorization_remediation the *required authorization details objects*. * (D) The client uses the provided authorization details objects in a new OAuth + RAR [RFC9396] 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. 4. Remediation of failures due to insufficient authorization This document defines: * The authentication error code insufficient_authorization for the WWW-Authenticate header. Resource servers SHOULD return insufficient_authorization when access is denied due to missing or insufficient authorization details. * The authorization_remediation error parameter, which contains a base64url-encoded JSON object guiding the client on remediating the error. Its attributes are: - authorization_details: REQUIRED. Array of actionable authorization details objects, matching the format specified in RAR [RFC9396] for the authorization_details request parameter, built using the failed resource request. Their inclusion in successful new OAuth grant SHALL satisfy the resource's requirements and remediate the failure. - authorization_reference: RECOMMENDED. An opaque string generated by the resource server to enable the client to select an existing access token associated with equivalent authorization details, without requiring the client to understand the semantics of the authorization details object: o Resource server SHOULD generate the authorization_reference by canonicalizing and hashing the authorization_details object or an equivalent stable representation, so that the same or semantically equivalent authorization details produce the same authorization_reference value. Zehavi Expires 5 January 2027 [Page 6] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 o The value MUST NOT reveal any sensitive or private information. o Clients MUST treat this value as opaque and MUST NOT attempt to interpret or derive meaning from it. o Returning stable authorization_reference values enables clients to reliably match existing tokens to incoming authorization_remediation responses, to avoid requesting new tokens when a matching token is already in their possession. o The resource server SHALL NOT include this attribute when tokens issued for the provided authorization_details are intended for single-use only. Notes: * The error_description parameter MAY be included to provide a human-readable description. * The provided authorization_details are intended to be interoperable with all OAuth specifications and usable in any grant flow supporting RAR. Example HTTP response from a direct debit resource: HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer error="insufficient_authorization", error_description="Additional authorization is required", authorization_remediation=eyJhdXRob3JpemF0aW9uX2RldGFpbHMiOlt7InR5cGUiOiJkaX... The decoded authorization_remediation contents in this example are: Zehavi Expires 5 January 2027 [Page 7] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 { "authorization_details": [{ "type": "direct_debit_mandate", "DebtorAccount": { "SchemeName": "UK.OBIE.SortCodeAccountNumber", "Identification": "08080021325698", "Name": "JohnDoe" }, "CreditorAgent": { "SchemeName": "UK.OBIE.BICFI", "Identification": "NWBKGB22" }, "CreditorAccount": { "SchemeName": "UK.OBIE.SortCodeAccountNumber", "Identification": "08080021325698", "Name": "ACMECorp" }, "MandateStatus": "Active", "CreationDateTime": "2026-06-01T09:00:00+00:00" } ], "authorization_reference": "Yb7q3AC5d" } Example HTTP response from a payment initiation resource: HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer error="insufficient_authorization", error_description="Additional authorization is required", authorization_remediation=eyJhdXRob3JpemF0aW9uX2RldGFpbHMiOlt7InR5cGUiOiJkaX... The decoded authorization_remediation contents in this example are: { "authorization_details": [{ "type": "payment_initiation", "instructed_amount": { "currency": "EUR", "amount": "100.00" }, "creditor_account": { "iban": "DE02120300000000202051" } } ] } Zehavi Expires 5 January 2027 [Page 8] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 5. Authorization Details Types Metadata Endpoint The following authorization server metadata [RFC8414] parameter is introduced to indicate the server's support for Authorization Details Types Metadata: "authorization_details_types_metadata_endpoint": OPTIONAL. The URL of the Authorization Details Types Metadata endpoint. The Authorization Details Types Metadata endpoint is called with HTTP GET and responds with Content-Type application/json and a JSON object whose members are authorization details type identifiers. Each member value is an object describing a single authorization details type. { "type": { "version": "...", "description": "...", "documentation_uri": "...", "schema": { }, "schema_uri": "...", "examples": [ ] } } Attribute 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 [JSON.Schema] 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. Zehavi Expires 5 January 2027 [Page 9] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 "schema_uri": The schema_uri attribute is an absolute URI, as defined by RFC 3986 [RFC3986], 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 Appendix A.1 for non-normative response example. 6. RAR objects in JWT access tokens Pursuant with RAR [RFC9396] section 9, 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. There may however be cases, where due to various considerations such as token size or information privacy, including approved RAR objects in JWT access tokens would be advised against. It is RECOMMENDED that when an authorization server issues JWT access tokens, it should consider the size, sensitivity, and privacy implications of including the authorization_details attribute. Where appropriate, the authorization server SHOULD omit this attribute from JWT tokens and instead provide the approved RAR objects to resource servers via the token introspection endpoint. This endpoint SHOULD use appropriate client authentication methods to prevent unauthorized access, in case of token leakage. 7. Processing Rules 7.1. Client Processing Rules * When receiving an insufficient_authorization error, if the authorization_remediation parameter contains an authorization_reference attribute that matches a valid token in the client's possession, the client MAY retry the failing request using the matching token. * If the authorization_remediation parameter contains an authorization_details attribute, the client MAY include it in a subsequent OAuth request to obtain a token for retrying the failing endpoint. Zehavi Expires 5 January 2027 [Page 10] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 * If the authorization server used so far by the client does not support the required authorization details types, the client MAY use Protected Resource Metadata [RFC9728] to discover additional authorization_servers supported by the resource, and attempt remediation through them. * Clients MAY ignore authorization_reference if they do not support token reuse or caching. 7.2. Resource Server Processing Rules * Verify access token validity. * Verify required authorization details are provided, by JWT token contents or through token introspection [RFC7662]. * If authorization details are missing or insufficient, return HTTP 401 with WWW-Authenticate: Bearer error="insufficient_authorization" including the authorization_remediation parameter which provides actionable authorization_details objects constructed from the failing request's input. 8. Security Considerations 8.1. Confidentiality of resource server provided authorization_details Resource servers when providing actionable authorization_details SHOULD NOT include sensitive data in those objects. This is consistent with RAR [RFC9396] authorization_details OAuth request parameter, representing *request* semantics. Confidentiality-preserving authorization_details types SHOULD NOT include sensitive data. Instead, the end-user SHOULD 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). 9. IANA Considerations Zehavi Expires 5 January 2027 [Page 11] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 9.1. OAuth 2.0 WWW-Authenticate Error Code Registry +============================+========+============+===============+ | Error Code |Error | Change | Specification | | |Usage | Controller | Document | | |Location| | | +============================+========+============+===============+ | insufficient_authorization |Resource| IETF | RFC XXXX, | | |access | | Section X | | |error | | | | |response| | | +----------------------------+--------+------------+---------------+ Table 1 9.2. OAuth Authorization Server Metadata Registry This specification registers the following authorization server metadata parameter in the OAuth Authorization Server Metadata registry: +=============================================+=============+==========+=============+ |Metadata Name |Metadata |Change |Specification| | |Description |Controller|Document | +=============================================+=============+==========+=============+ |authorization_details_types_metadata_endpoint|URL of the |IETF |RFC XXXX, | | |Authorization| |Section X | | |Details Types| | | | |Metadata | | | | |endpoint | | | +---------------------------------------------+-------------+----------+-------------+ Table 2 10. Normative References [IANA.oauth-parameters] IANA, "OAuth Parameters", . [JSON.Schema] Wright, Ed, A., Andrews, Ed, H., Hutton, Ed, B., and G. Dennis, "JSON Schema: A Media Type for Describing JSON Documents", June 2022, . Zehavi Expires 5 January 2027 [Page 12] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, . [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . Appendix A. Examples This section provides non-normative examples of how this specification may be used to support specific use cases. A.1. Authorization Server Metadata Examples A.1.1. Example authorization_details_types_metadata_endpoint response with Payment Initiation Zehavi Expires 5 January 2027 [Page 13] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 HTTP/1.1 200 OK Content-Type: application/json { "payment_initiation": { "version": "1.0", "description": "Authorization to initiate a single payment from a payer account to a creditor account.", "documentation_uri": "https://example.com/docs/payment-initiation", "schema": { "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "Payment Initiation Authorization Detail", "type": "object", "required": [ "type", "instructed_amount", "creditor_account" ], "properties": { "type": { "const": "payment_initiation", "description": "Authorization details type identifier." }, "actions": { "type": "array", "description": "Permitted actions for this authorization.", "items": { "type": "string", "enum": ["initiate"] }, "minItems": 1, "uniqueItems": true }, "instructed_amount": { "type": "object", "description": "Amount and currency of the payment to be initiated.", "required": ["currency", "amount"], "properties": { "currency": { "type": "string", "description": "ISO 4217 currency code.", "pattern": "^[A-Z]{3}$" }, "amount": { "type": "string", "description": "Decimal monetary amount represented as a string.", "pattern": "^[0-9]+(\\.[0-9]{1,2})?$" } } Zehavi Expires 5 January 2027 [Page 14] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 }, "creditor_account": { "type": "object", "description": "Account to which the payment will be credited.", "required": ["iban"], "properties": { "iban": { "type": "string", "description": "International Bank Account Number (IBAN).", "pattern": "^[A-Z0-9]{15,34}$" } } }, "remittance_information": { "type": "string", "description": "Unstructured remittance information for the payment.", "maxLength": 140 } } } } } A.1.2. Example authorization_details_types_metadata_endpoint response for the Norwegian Health Sector (HelseID) HTTP/1.1 200 OK Content-Type: application/json { "helseid_authorization": { "version": "1.0", "description": "Allows the OAuth client to pass organization information to HelseID.", "documentation_uri": "https://utviklerportal.nhn.no/informasjonstjenester/helseid/bruksmoenstre-og-eksempelkode/bruk-av-helseid/docs/tekniske-mekanismer/organisasjonsnumre_enmd", "schema": { "$schema": "http://json-schema.org/draft-07/schema#", "title": "Organization numbers for a multi-tenant client", "type": "object", "properties": { "type": { "type": "string", "const": "helseid_autorization" }, "practitioner_role": { "type": "object", "properties": { "organization": { Zehavi Expires 5 January 2027 [Page 15] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 "type": "object", "properties": { "identifier": { "type": "object", "properties": { "system": { "type": "string" }, "type": { "type": "string" }, "value": { "type": "string" } }, "required": [ "system", "type", "value" ] } }, "required": [ "identifier" ] } }, "required": [ "organization" ] } }, "required": [ "type", "practitioner_role" ] } }, "helseid_trust_framework": { "version": "1.0", "description": "HelseID Trust Framework Information", "documentation_uri": "https://utviklerportal.nhn.no/informasjonstjenester/helseid/bruksmoenstre-og-eksempelkode/bruk-av-helseid/docs/tekniske-mekanismer/trust-framework", "schema": { "$schema": "http://json-schema.org/draft-07/schema#", "description": "Complete Trust Framework structure", "documentation_uri": "https://utviklerportal.nhn.no/informasjonstjenester/helseid/bruksmoenstre-og-eksempelkode/bruk-av-helseid/docs/tillitsrammeverk/profil_for_tillitsrammeverkmd", "type": "object", "properties": { Zehavi Expires 5 January 2027 [Page 16] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 "type": { "type": "string", "const": "nhn:tillitsrammeverk:parameters" }, "practitioner": { "type": "object", "properties": { "authorization": { "type": "object", "properties": { "code": { "type": "string" }, "system": { "type": "string" } }, "required": [ "code", "system" ] }, "legal_entity": { "type": "object", "properties": { "id": { "type": "string" }, "system": { "type": "string" } }, "required": [ "id", "system" ] }, "point_of_care": { "type": "object", "properties": { "id": { "type": "string" }, "system": { "type": "string" } }, "required": [ Zehavi Expires 5 January 2027 [Page 17] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 "id", "system" ] }, "department": { "type": "object", "properties": { "id": { "type": "string" }, "system": { "type": "string" } }, "required": [ "id", "system" ] } }, "required": [ "authorization", "legal_entity", "point_of_care", "department" ] }, "care_relationship": { "type": "object", "properties": { "healthcare_service": { "type": "object", "properties": { "code": { "type": "string" }, "system": { "type": "string" } }, "required": [ "code", "system" ] }, "purpose_of_use": { "type": "object", "properties": { Zehavi Expires 5 January 2027 [Page 18] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 "code": { "type": "string" }, "system": { "type": "string" } }, "required": [ "code", "system" ] }, "purpose_of_use_details": { "type": "object", "properties": { "code": { "type": "string" }, "system": { "type": "string" } }, "required": [ "code", "system" ] }, "decision_ref": { "type": "object", "properties": { "id": { "type": "string" }, "user_selected": { "type": "boolean" } }, "required": [ "id", "user_selected" ] } }, "required": [ "healthcare_service", "purpose_of_use", "purpose_of_use_details", "decision_ref" Zehavi Expires 5 January 2027 [Page 19] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 ] }, "patients": { "type": "array", "items": { "type": "object", "properties": { "point_of_care": { "type": "object", "properties": { "id": { "type": "string" }, "system": { "type": "string" } }, "required": [ "id", "system" ] }, "department": { "type": "object", "properties": { "id": { "type": "string" }, "system": { "type": "string" } }, "required": [ "id", "system" ] } }, "required": [ "point_of_care", "department" ] } } }, "required": [ "type", "practitioner", Zehavi Expires 5 January 2027 [Page 20] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 "care_relationship", "patients" ] } } } Appendix B. Document History -05 * Removed required authorization details types. * Changed from HTTP 403 to 401. * Moved resource servers response from body to WWW-Authenticate header. * Renamed authorization_hint to authorization_reference and clarified its usage. * Clarified authorization server broader considerations on omitting RAR from JWT access tokens. * Clarified document's interoperability with any OAuth rfc and any grant that supports RAR. -04 * Moved required authorization details types from resource metadata to resource server's response. * Adapted resource server processing rules to reflect error signaling and handling of large RAR payloads. -03 * Added authorization_reference 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 Zehavi Expires 5 January 2027 [Page 21] Internet-Draft OAuth 2.0 RAR Metadata and Error Remedia July 2026 * 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. Author's Address Yaron Zehavi Raiffeisen Bank International Email: yaron.zehavi@rbinternational.com Zehavi Expires 5 January 2027 [Page 22]