COAZ-RAR: COAZ Binding for OAuth 2.0 Rich Authorization Requests

	coaz-rar	October 2026
Gazitt	Standards Track	[Page]

Abstract

This specification defines COAZ-RAR, the COAZ binding, as defined by the COAZ Framework [COAZFW], for OAuth 2.0 Rich Authorization Requests [RFC9396]. An authorization details type is typically defined by one party and processed by others: an authorization server decides whether to grant an entry of that type, and a resource server decides whether a call is permitted under it. This binding lets the definer of a type publish, once, how an entry of that type maps onto an OpenID AuthZEN Authorization API request [AUTHZEN], and lets both enforcement points apply that mapping. The authorization server applies it at token issuance, under the AuthZEN profile for OAuth 2.0 token issuance [ISSUANCE]; the resource server applies it when a call arrives. Both ask the Policy Decision Point their questions in one vocabulary. The mapping is published as a member of the type's entry in the authorization details types metadata defined by [RARMETA].¶

1. Introduction

Rich Authorization Requests [RFC9396] let a client ask for structured, fine-grained access: a payment to a named creditor for a stated amount, read access to one patient's records, a set of file paths. Each entry in an authorization_details array has a type, and the type determines which members the entry may carry and what they mean.¶

A type is usually defined by someone other than the authorization server (AS) that processes it. Open banking and health ecosystems define types that many servers must handle, which is why Section 2.1 of [RFC9396] recommends collision-resistant type names for APIs "expected to be deployed across different servers." The resource server (RS) whose API a type describes is another definer. So is a Model Context Protocol [MCP] server, whose tool input schemas are type definitions in all but name.¶

RFC 9396 leaves the decision to grant an entry, and the RS's decision on a call made under it, to each server. Two pieces of adjacent work narrow that gap from different sides:¶

The AuthZEN profile for OAuth 2.0 token issuance [ISSUANCE] lets an AS externalize the issuance decision to a Policy Decision Point (PDP). It decomposes an entry along RFC 9396's common data fields (locations, actions, datatypes) and asks one question per cell. It does not decompose identifier, privileges, or any type-specific member, so for a type whose meaning lives in its own members, such as the creditor and amount of a payment, the PDP never sees what the decision is about.¶
[RARMETA] defines an AS metadata endpoint that publishes a JSON Schema for each type, and a challenge with which an RS that refuses a call tells the client exactly which entry to request.¶

Neither says how an entry of a given type becomes an authorization question. The party that knows is the type's definer. The COAZ Framework [COAZFW] exists for exactly this split between a party that describes an operation and a party that enforces it: COAZ-MCP [COAZMCP] lets an MCP server declare, in a tool's input schema, how a call to that tool maps onto an AuthZEN request, so that a gateway with no knowledge of the server's business logic can enforce it.¶

This specification is COAZ-RAR, the COAZ binding for authorization details. It treats an authorization details type as the operation description, and the types metadata of [RARMETA] as the place a mapping is published. Two enforcement points apply it:¶

The AS, at issuance, for each cell of each requested entry, in place of the per-cell projection of [ISSUANCE].¶
The RS, when a call arrives, for the entry the call amounts to.¶

Because both apply the same mapping, both ask the PDP in one vocabulary. Where the entry names a specific resource, as it does when the RS built it from a call it refused, the AS and the RS ask the same question. Where it doesn't, as with a standing grant, the AS asks about the class of resource and the RS asks about the member of it that the call touches.¶

1.1. Requirements Notation and Conventions

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.¶

1.2. Terminology

This specification uses the terms defined in the COAZ Framework [COAZFW], notably binding, information model, input variable, mapping, literal, expression, default mapping, declared mapping, PEP, and PDP, and the terms authorization details, authorization details type, and common data fields defined by [RFC9396]. It adds the following:¶

Entry:: One object in an authorization_details array.¶
Cell:: One combination of a locations value, an actions value, and, where present, a datatypes value of an entry. Section 2.2 of [RFC9396] defines an entry as the product of these values; a cell is one element of that product.¶
Type Definer:: The party that defines an authorization details type and its meaning: an ecosystem, a resource server operator, or an MCP server.¶
Issuance PEP:: The AS, acting as a PEP when it decides whether to grant an entry under [ISSUANCE].¶
Resource PEP:: The RS, or a gateway in front of it, acting as a PEP when it decides whether to permit a call.¶
Projection:: The entry and cell that an RS determines a call amounts to.¶
Prospective Token:: The set of claims the AS will place in the access token it is about to issue, as known before the PDP is asked.¶

2. Relationship to the COAZ Framework

This binding fulfils the binding conformance requirements of the COAZ Framework [COAZFW] as summarized below; each row is specified in the referenced section.¶

Table 1
Framework requirement	This binding
Information model	`detail`, `cell`, `token`, `params` (Section 3)
Mapping location	`authzen_mapping` in the type's metadata entry, else `x-authzen-mapping` in the type's schema, else the default (Section 6)
Literal/expression discriminator	Framework default: `$` prefix, `$$` escape (Section 4)
Expression language	Framework default: CEL [CEL] (Section 4)
Envelopes	`evaluation` and `evaluations` (Section 5)
Operations in scope	One cell of one entry; no pass-through set (Section 5.1)
Default mapping behavior	The per-cell projection of [ISSUANCE] (Section 7)
Declared mapping behavior	The type definer MAY declare a mapping; it overrides the default for that type (Section 8)
Trust-anchored fields	`subject.id`, by verification (Section 8)
Error transport	OAuth error responses at the AS, HTTP status at the RS (Section 10)
Discoverability	The types metadata endpoint of [RARMETA] (Section 6)

2.1. Architecture

 Type definer -----> AS types metadata endpoint, read by both PEPs
 (ecosystem, RS,     { "<type>": { "schema": {...},
  MCP server)                      "authzen_mapping": {...} } }

 +--------+
 |        |                        +----------------+
 |        |  (1) call              |  Resource PEP  |
 |        |----------------------->| (RS / gateway) |
 |        |<-----------------------|                |
 |        |  (2) 401, remediation  +----------------+
 |        |
 |        |                        +----------------+      +-------+
 |        |  (3) token request     |  Issuance PEP  | (4)  |       |
 | Client |----------------------->|      (AS)      |----->|       |
 |        |<-----------------------|                |      |       |
 |        |  token                 +----------------+      |       |
 |        |                                                |  PDP  |
 |        |                        +----------------+      |       |
 |        |  (5) retry             |  Resource PEP  | (6)  |       |
 |        |----------------------->| (RS / gateway) |----->|       |
 |        |<-----------------------|                |      |       |
 |        |  200                   +----------------+      +-------+
 +--------+

Figure 1: One mapping, two enforcement points

The client calls the RS with a token that does not cover the call.¶
The RS projects the call onto an entry and answers with the remediation challenge of [RARMETA], carrying that entry.¶
The client requests a token for the entry.¶
The AS applies the type's mapping to each cell of the entry and asks the PDP, under [ISSUANCE]. It issues a token for what the PDP permits.¶
The client retries the call with the new token.¶
The RS applies the same mapping to its projection of the call and asks the PDP before permitting it.¶

Steps 1 and 2 are absent when a client requests an entry without having been refused, as with a standing grant. Step 6 occurs on every call the token covers, whether or not the entry came from a remediation.¶

The PDP at step 4 and the PDP at step 6 need not be the same. In a cross-domain deployment the AS's PDP holds the policy of the organization whose user or agent is asking, and the RS's PDP holds the policy of the organization that owns the resource. The mapping gives them a common vocabulary without requiring a common policy.¶

3. Information Model

This binding exposes four input variables to expressions. Each is populated differently at the two enforcement points.¶

Table 2
Variable	At the Issuance PEP	At the Resource PEP
`detail`	The entry being evaluated, after any enrichment by the AS (Section 3.4)	The entry of the projection (Section 3.2)
`cell`	The cell being evaluated (Section 3.1)	The cell of the projection
`token`	The prospective token (Section 3.3)	The claims of the presented access token
`params`	`{"name": <type>, "arguments": <detail>}`	The same, or the MCP `params` object where the Resource PEP is an MCP gateway

detail:: A map holding the entry, with every member it carries, including type.¶
cell:: A map with a location key (string), an action key (string), a datatype key (string) that is present only when the cell has a datatype, and a name key (string) holding the action name [ISSUANCE] forms for the cell: the action alone, or the action and datatype joined by a colon.¶
token:: A map of access token claims. At the Resource PEP these are the decoded claims of a JWT access token [RFC9068] or the members of a token introspection response [RFC7662].¶
params:: A map holding the operation's name and arguments in the shape COAZ-MCP [COAZMCP] exposes for tools/call. It exists so that a mapping written for an MCP tool runs unchanged when that tool is also used as an authorization details type (Section 8.4).¶

3.1. Cells

At the Issuance PEP, the cells of an entry and their order are those of the Authorization Detail Tuple section of [ISSUANCE], including its substitutions for absent members: an absent locations takes each requested target, an absent actions takes the reserved name authorization_detail, and an absent datatypes yields cells without a datatype key. This binding does not change how many cells an entry has; it changes only how each cell becomes evaluations.¶

At the Resource PEP, the cell is the location, action, and datatype that the call occupies, in the type's own vocabulary.¶

3.2. The Resource PEP's Projection

A Resource PEP MUST be able to project each call it authorizes under this binding onto an entry and a cell. The entry's type is the type that describes the call, and its other members are the values the call supplies for that type's members.¶

Where a call addresses a specific resource and the type allows identifier (Section 2.2 of [RFC9396]: "a specific resource available at the API"), the projection MUST set identifier to that resource. This is what lets a mapping ask about the instance at the RS while the AS, given an entry without an identifier, asks about the class (Section 8.3).¶

The projection is also the basis of the remediation entry of [RARMETA], which that document says is "built using the failed resource request." A Resource PEP that issues a remediation challenge SHOULD construct its entry from the projection, adding locations, actions, and datatypes from the cell only where the type's schema allows those members. Building the remediation from the projection is what makes the AS evaluate, at issuance, the question the RS will ask when the call is retried.¶

3.3. The Prospective Token

At issuance there is no token yet. The Issuance PEP binds token to the claims it will place in the token it is about to issue: at least sub, client_id, and aud, and any other claim it will mint that does not depend on the PDP's response. Claims that the PDP's response would add, such as those of the claims key of [ISSUANCE], are not available.¶

A mapping intended for both enforcement points MUST use optional selection (.?) for any claim other than sub, so that an AS that does not mint the claim produces an absent value rather than a mapping error.¶

3.4. Enrichment

Section 7.1 of [RFC9396] allows an AS to enrich an entry with values the user selects during the interaction, such as a specific record. At the Issuance PEP, detail MUST be the entry after enrichment. A mapping that selects a member the client did not send, such as identifier, would otherwise fail on every request from a client that relies on enrichment.¶

5. Mapping Envelopes

This binding permits both envelope keys defined by the framework:¶

evaluation, for a cell that needs one decision. The default mapping uses it, and it is RECOMMENDED for declared mappings that need one decision.¶
evaluations, for a cell that needs several, such as a transfer that must be authorized both as a debit of the source account and as a payment to the payee. The evaluations array MUST be a literal array; an expression in its place is a mapping error, as Section 2.6 of [COAZFW] requires.¶

Any other envelope key is a mapping error.¶

5.1. Operations in Scope

The COAZ operation for this binding is one cell of one entry. A mapping is applied once per cell, and the cell is permitted only if every evaluation the mapping produces for it is a permit, which is the fail-closed rule of the framework applied to the cell.¶

At the Issuance PEP, the number of cells is set by the entry and by [ISSUANCE], not by the mapping. That is how this binding keeps the number of decisions fixed by the envelope, as the framework requires, while an entry still yields as many questions as its product contains. How the cells of an entry combine into what is granted, and what the AS does when some are denied, is defined by [ISSUANCE] ("A Denied Cell Narrows an Entry") and is outside this binding.¶

There is no pass-through set. Every cell of every entry is authorized. An entry whose type the AS does not support is rejected under Section 5 of [RFC9396] before any mapping is selected.¶

6. Declaring a Mapping

A type's mapping is published in the response of the authorization_details_types_metadata_endpoint of [RARMETA], as a member of the object describing that type:¶

authzen_mapping:: OPTIONAL. A COAZ mapping, as defined by [COAZFW] and constrained by this binding, for entries of this type.¶

A PEP selects the mapping for a type as follows:¶

If the type's metadata object has an authzen_mapping member, use it.¶
Otherwise, if the type's schema (or the document at its schema_uri) has an x-authzen-mapping member at its top level, use it. This is where COAZ-MCP places a tool's mapping, so a tool's input schema adopted as a type's schema brings its mapping with it.¶
Otherwise, use the default mapping (Section 7).¶

The mapping is authored by the type definer, which is the authority for it as it is for the type's schema. The type definer may be an ecosystem, an RS, or an MCP server. An AS operator adopts the mapping in the same act by which it adopts the type's schema today, and takes it on as configuration; the AS does not fetch a mapping from a type definer at request time. The AS's types metadata endpoint is the channel through which the mapping is distributed, not the source of its authority. A Resource PEP obtains the mapping from that endpoint, so that both enforcement points apply the type definer's mapping.¶

Where one type is used by several RSs, possibly under different operators, the type and its mapping are their shared vocabulary. Each RS brings its own PDP and policy (Section 2.1).¶

The types metadata endpoint is not access-controlled. Publishing a mapping there discloses which members of a type the policy considers, which is the shape of the authorization question and not the policy that answers it. An AS that considers even that shape sensitive can omit authzen_mapping from the published metadata and provision the Resource PEP with it by other means.¶

8. Declared Mappings

A type definer MAY declare a mapping for a type. A declared mapping overrides the default for every cell of every entry of that type, and for no other type.¶

subject.id is trust-anchored, enforced by verification. A declared mapping MAY set subject.id; if it does, it MUST set it to $token.sub, and the PEP MUST verify that the resolved value equals the authenticated subject: at the Issuance PEP, the subject [ISSUANCE] places in the request; at the Resource PEP, the sub claim of the presented token. A mismatch is a mapping error. If a declared mapping omits subject or subject.id, the PEP supplies them as it would for the default mapping.¶

A declared mapping using the evaluations envelope MUST NOT set subject in any entry of its evaluations array; a PEP MUST treat one that does as a mapping error.¶

Every attribute a declared mapping supplies other than the verified subject.id, including subject.type and every properties member, is untrusted input under Section 2.9 of [COAZFW]. A policy that grants on the basis of an elevated role or privilege MUST rely on the verified subject.id, not on a declared subject.type.¶

8.1. Payment Initiation

The payment_initiation type of RFC 9396 Figure 2. The decision is about the creditor and the amount, both type-specific members that the default mapping does not reach. The declared mapping puts the creditor in the five-tuple and the amount, a parameter of the act, in action.properties:¶

{
  "evaluation": {
    "action": {
      "name": "$cell.action",
      "properties": {
        "amount": "$detail.instructedAmount.amount",
        "currency": "$detail.instructedAmount.currency"
      }
    },
    "resource": {
      "type": "creditor_account",
      "id": "$detail.creditorAccount.iban"
    },
    "context": { "agent": "$token.?client_id" }
  }
}

Figure 3: A declared mapping for payment_initiation

A mapping can branch per action where actions concern different entities; a cancel cell, for instance, might be asked about the payment rather than the creditor. The CEL conditional operator serves for that, as COAZ-MCP's examples show.¶

For the initiate cell of the Figure 2 entry, the Issuance PEP produces:¶

{
  "action": {
    "name": "initiate",
    "properties": { "amount": "123.50", "currency": "EUR" }
  },
  "resource": {
    "type": "creditor_account",
    "id": "DE02100100109307118603"
  },
  "context": { "agent": "fintech-app" }
}

When the client retries POST /payments with the token, the Resource PEP projects the request body onto the same entry and produces the same evaluation.¶

8.2. Two Decisions per Cell

A transfer type with no common data fields at all, so each entry is a single cell with the substituted action authorization_detail. The mapping ignores that action and asks two questions:¶

{
  "evaluations": {
    "context": { "agent": "$token.?client_id" },
    "evaluations": [
      {
        "action": {
          "name": "debit",
          "properties": {
            "amount": "$detail.instructed_amount.amount",
            "currency": "$detail.instructed_amount.currency"
          }
        },
        "resource": {
          "type": "account",
          "id": "$detail.debtor_account.account_id"
        }
      },
      {
        "action": {
          "name": "pay",
          "properties": {
            "amount": "$detail.instructed_amount.amount",
            "currency": "$detail.instructed_amount.currency"
          }
        },
        "resource": {
          "type": "pix_key",
          "id": "$detail.creditor_account.pix_key"
        }
      }
    ]
  }
}

Figure 4: A declared mapping with two decisions per cell

8.3. Class and Instance

The customer_information type of RFC 9396 Figure 5, with identifier allowed. A client requesting a standing grant sends no identifier; a call to GET /customers/c-77/contacts names one. The mapping asks about the collection in the first case and about the customer in the second:¶

{
 "evaluation": {
  "action": { "name": "$cell.name" },
  "resource": {
   "type":
    "$has(detail.identifier) ? 'customer' : 'customer_information'",
   "id":
    "$has(detail.identifier) ? detail.identifier : cell.location"
  }
 }
}

Figure 5: One mapping, two levels of detail

At issuance the PDP is asked read:contacts on customer_information:https://example.com/customers, which today's policy may answer by role. At the RS it is asked read:contacts on customer:c-77, which a policy may answer by the subject's relationship to that customer. The policy can move from the first answer to the second without either enforcement point changing, because the RS was asking about the instance all along. A PDP that does not hold the relation between a customer and the collection can be given it by the mapping, as a resource property set only when identifier is present.¶

A token granted on the class does not cover every instance. A call about a customer the subject has no relationship with is refused by the Resource PEP's own evaluation, even though the token covers the call. When an RS remediates a refused call (Section 3.2), the entry carries the identifier, and the AS asks about the instance as well.¶

8.4. MCP Tools as Authorization Details Types

An MCP tool can be used as an authorization details type: its type is a URI naming the tool, its members are the tool's arguments, and its schema is the tool's input schema. If that input schema carries a COAZ-MCP x-authzen-mapping, step 2 of Section 6 selects it, and the params variable lets it run unchanged: params.arguments is the entry at the Issuance PEP and the tools/call arguments at an MCP gateway, and token.sub is the authenticated subject at both.¶

An MCP gateway that refuses a tools/call can therefore remediate with an entry built from the call's arguments, and the AS evaluates, at issuance, the call the gateway will see on retry. This gives issuance a decision on the concrete arguments of a specific call, which it otherwise does not have.¶

9. PEP Behavior

9.1. Issuance PEP

When an AS processes a token request carrying authorization_details under [ISSUANCE], it MUST, for each entry:¶

Apply any enrichment (Section 3.4).¶
Select the type's mapping (Section 6).¶
Form the entry's cells (Section 3.1).¶
For each cell, populate the input variables (Section 3), resolve the mapping, verify the trust-anchored subject.id (Section 8), and add the resulting evaluations to the batch in place of the evaluation [ISSUANCE] would form for that cell.¶

The AS then sends the batch, including the gate tuples [ISSUANCE] defines, and composes the result as [ISSUANCE] defines, treating a cell as permitted only if every evaluation the mapping produced for it is a permit. The response shaping, no-broadening, and structural-check rules of [ISSUANCE] are unchanged.¶

9.2. Resource PEP

When an RS receives a call it authorizes under this binding, it MUST:¶

Validate the access token as it otherwise would.¶
Project the call onto an entry and a cell (Section 3.2).¶
Determine whether the token's authorization_details cover the projection, using the details the AS made available to it (Section 9 of [RFC9396]). If they do not, the RS SHOULD answer with the remediation challenge of [RARMETA], built from the projection, and MUST NOT perform the call.¶
Select the type's mapping, populate the input variables, resolve the mapping, and verify the trust-anchored subject.id.¶
Send the constructed request to the PDP and permit the call only if every decision is a permit.¶
Before performing the call, confirm that the call's projection is unchanged from the one evaluated, as COAZ-MCP requires of a message, and re-evaluate or refuse it otherwise.¶

Step 3 asks whether the token covers the call; step 5 asks whether policy permits it. Both are required. A token is evidence of what was granted at issuance; it is not evidence that the call, as made, is permitted now.¶

Table 3
Category	Issuance PEP	Resource PEP
Mapping error	`invalid_authorization_details` [RFC9396]	HTTP 500
Authorization denial	As [ISSUANCE] defines for denied cells and gates	HTTP 403
PDP communication error	As [ISSUANCE] defines: HTTP 503 with `Retry-After`	HTTP 503

11. Guidance for Mapping Authors

This section is non-normative.¶

Table 4
The member is	Put it in	Example
An entity the decision is about	`resource` (`type` and `id`)	`creditor_account:DE02...`
The specific resource, when the entry or call names one	`resource.id`, from `identifier`	`customer:c-77`
A quantity or parameter of the act	`action.properties`	`{"amount": "123.50", "currency": "EUR"}`
A second entity the act touches	A second evaluation	a debit of the source and a payment to the payee
A filter the client placed on its request	`resource.properties`	a sensitivity filter on a records request
An assertion about who is asking	`subject.properties` or `context`	a practitioner role

Entities belong in the five-tuple because every PDP, including one that reasons over relationships, can use them. A quantity does not: an amount has no identity and no relationships, and a relationship-based engine takes such a value as request context for a condition rather than as an object. Section 5.3.1 of [AUTHZEN] provides for it directly: action properties "can include ... parameters of the action that is being requested."¶

Do not reduce a value the policy might compare into a category in the mapping. A mapping that sends "sensitivity": "high" for any amount over a threshold lets the PDP distinguish small payments from large ones, but not 25,000 from 60,000. COAZ-MCP's discussion of authorization granularity applies equally here: an input a mapping does not project is not evaluated by the PDP.¶

A filter the client places on its request (a set of sensitivity labels, say) exists in the entry but not in a call, so the AS and RS will see different properties for it. That is expected and is one reason decision-critical inputs belong in the five-tuple.¶

An assertion about who is asking, carried in an entry, is client-supplied and untrusted. The AS has to verify it against an authoritative source; the mapping cannot make it trustworthy.¶

14. References

14.1. Normative References

[AUTHZEN]: OpenID Foundation AuthZEN Working Group, "Authorization API 1.0", 11 January 2026, <https://openid.net/specs/authorization-api-1_0-final.html>.
[CEL]: Google, "Common Expression Language", 2024, <https://cel.dev/>.
[COAZFW]: Olivier, A. and A. Tulshibagwale, "COAZ: A Framework for Mapping Information Models to AuthZEN Authorization Requests", 2026, <https://openid.github.io/authzen/authzen-coaz-framework-1_0.html>.
[ISSUANCE]: Gazitt, O., "AuthZEN Profile for OAuth 2.0 Token Issuance", 2026, <https://openid.github.io/authzen/authzen-oauth-token-issuance-1_0.html>.
[RARMETA]: Zehavi, Y., "OAuth 2.0 RAR Metadata and Error Remediation", Work in Progress, Internet-Draft, draft-ietf-oauth-rar-metadata-remediation-00, 23 August 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-metadata-remediation-00>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9396]: Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0 Rich Authorization Requests", RFC 9396, DOI 10.17487/RFC9396, May 2023, <https://www.rfc-editor.org/rfc/rfc9396>.

14.2. Informative References

[AUTHMETA]: Zehavi, Y., "OAuth 2.0 Authority Metadata", Work in Progress, Internet-Draft, draft-zehavi-oauth-authority-metadata-00, 11 October 2026, <https://datatracker.ietf.org/doc/html/draft-zehavi-oauth-authority-metadata-00>.
[COAZMCP]: Tulshibagwale, A. and A. Olivier, "COAZ-MCP: COAZ Binding for the Model Context Protocol", 2026, <https://openid.github.io/authzen/authzen-coaz-mcp-binding-1_0.html>.
[MCP]: "Model Context Protocol Specification", 2025, <https://modelcontextprotocol.io/specification>.
[RFC6750]: Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/rfc/rfc6750>.
[RFC7662]: Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/rfc/rfc7662>.
[RFC9068]: Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October 2021, <https://www.rfc-editor.org/rfc/rfc9068>.
[RFC9728]: Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/rfc/rfc9728>.

Appendix E. Notices

The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft, Final Specification, or Final Specification Incorporating Errata Corrections solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts, Final Specifications, and Final Specification Incorporating Errata Corrections based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.¶

The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy (found at openid.net) requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. OpenID invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.¶

COAZ-RAR: COAZ Binding for OAuth 2.0 Rich Authorization Requests - Draft 1