Mission Resource Access Profile for OAuth 2.0

4.1. Subset Rule

[I-D.draft-mcguinness-oauth-mission] derives, narrows, and delegates a mission_resource_access entry only as a subset of a reference entry, and refuses an entry that is not one. This section defines that relation.¶

When the AS narrows the Authority Set for a derived token, a derived mission_resource_access entry A is a subset of a Mission entry B when:¶

1. A's effective resource set is contained in B's (resource_match, Section 4): when neither entry sets resource_match: "prefix", A.resource equals B.resource; when B is a prefix entry, A (whether exact or prefix) is contained when A.resource equals B.resource or extends its path at a path-segment boundary; a prefix A is never contained in an exact B.¶

2. Every A.actions value is within some B.actions value: a value is within an equal value; a literal action is within a family whose name it extends at a segment boundary (invoices.read is within invoices.*); a family is within a reference family when its own name extends the reference's name at a segment boundary (invoices.q3.* is within invoices.*). A family is never within a literal action.¶

3. For every key K in B.constraints:¶

   • K MUST also be present in A.constraints. A key present in B but absent from A is treated as the broadest possible value and therefore fails this test.¶

   • A's value MUST be no broader than B's under K's subset rule: the specification-defined rule when K is a Common Constraint (Section 4.2), the deployment-defined comparison otherwise.¶

Resource containment under a prefix reference is compared after RFC 3986 [RFC3986] syntax-based normalization of both URIs: lowercase the scheme and host, remove a default port, uppercase the hexadecimal digits of any percent-encoding ([RFC3986] Section 2.1, so %2f and %2F are equivalent), decode percent-encoded octets of unreserved characters, and remove dot-segments. This normalization applies to comparison only, never to hashing: [I-D.draft-mcguinness-oauth-mission]'s anchor computation remains byte-exact over the recorded values and is untouched by this rule.¶

The default comparison is deliberately flat: resource matches by exact equality and a literal action by array membership. Hierarchy is opt-in and closed to the two forms above: resource_match: "prefix" for resource containment and .* action families for action containment (Section 4). A deployment that uses neither retains the flat behavior unchanged.¶

The delegation member is policy, not authority, and is not part of this comparison (Section 4.5). A derived entry's delegation, when present, MUST NOT be broader than the parent entry's:¶

• its max_depth MUST be no greater than the parent entry's;¶

• its allowed_delegates MUST be no wider than the parent entry's; and¶

• a derived entry MUST NOT introduce delegation where the parent entry has none.¶

4.2. Common Constraints

A constraints member name (Section 4) is either a specification-defined Common Constraint or a deployment-defined key. Common Constraints give independently developed deployments one vocabulary they interpret, narrow, and compare identically; further Common Constraints are defined by specification under the naming convention of Section 8.3.¶

A Common Constraint definition fixes:¶

• Value syntax: the JSON [RFC8259] value type and any additional rules.¶

• Subset rule: how a candidate value is judged no broader than a reference value, used by the subset comparison of Section 4.1.¶

• Intersection rule: how two values for the same key combine; the result MUST be no broader than either operand.¶

A constraints member whose name is a specification-defined Common Constraint is interpreted per its definition. Any other member name remains deployment-defined and is interpreted only within the issuing deployment; a consumer that does not recognize it MUST fail closed ([I-D.draft-mcguinness-oauth-mission]).¶

The same duty binds the AS side of narrowing: whenever the AS derives a candidate entry from a ceiling (a client's authority proposal narrowed to the Authority Set, or an Authority Set entry narrowed to a derived or delegated token, [I-D.draft-mcguinness-oauth-mission], Section 4.5), a registered Common Constraint key present in the ceiling entry that the AS does not implement narrowing for MUST NOT be dropped while the entry survives. The AS MUST instead fail closed: refuse the whole derivation, or omit the entry from the result, exactly as an unrecognized target_resources value already may be; the granted authorization_details echo reflects any such omission ([I-D.draft-mcguinness-oauth-mission]). Carrying the entry forward with the key dropped would widen effective authority past the ceiling exactly as an unenforced key would at the Resource Server ([I-D.draft-mcguinness-oauth-mission]).¶

This document defines the initial Common Constraints:¶

• max_amount (object): a per-action ceiling on a monetary amount. The value is an object with two members: amount (REQUIRED, a string containing a decimal number) and currency (REQUIRED, an ISO 4217 [ISO4217] currency code). Subset: no broader when the currency values are equal and the candidate amount is less than or equal to the reference amount, compared in decimal value space; differing currencies fail the comparison (no conversion is defined). Intersection: when the currency values are equal, the value with the smaller amount; differing currencies have no intersection and the combination fails.¶

• resource_issued_after (string, an RFC 3339 [RFC3339] date-time): the action applies only to resources issued at or after this instant. Subset: no broader when greater than or equal to the reference. Intersection: the later instant.¶

• resource_issued_before (string, an RFC 3339 [RFC3339] date-time): the action applies only to resources issued at or before this instant. Subset: no broader when less than or equal to the reference. Intersection: the earlier instant. The resource_ qualifier in both names marks that the window bounds resource issuance, not token issuance.¶

• tenant (string): the action applies only to resources of the named tenant. Subset: no broader when equal to the reference value. Intersection: the common value when the two are equal; otherwise there is no intersection and the combination fails.¶

• recipient_domain (string, a DNS name): the action applies only to recipients within the named domain. Subset: no broader when equal to the reference or a DNS subdomain of it. Intersection: the narrower value when one is equal to or a subdomain of the other; otherwise there is no intersection and the combination fails.¶

• time_window (object): the action may be exercised only within the window, evaluated at the point of use (unlike resource_issued_after and resource_issued_before, which bound resource issuance, and unlike token exp, which bounds the credential). The value has two members, not_before and not_after (each an RFC 3339 [RFC3339] date-time); at least one MUST be present, and an absent member is unbounded on that side. Subset: no broader when the candidate window lies within the reference window, an absent candidate bound counting as unbounded and therefore broader than any present reference bound. Intersection: the overlap (the later not_before, the earlier not_after); an empty overlap has no intersection and the combination fails.¶

• data_classification (array of strings): the action applies only to data whose classification label is among the named values. Label semantics are deployment- or registry-defined; the comparison is not. Subset: no broader when the candidate array's members are a subset of the reference array's, compared as exact strings. Intersection: the common members; an empty result has no intersection and the combination fails.¶

• allowed_tools (array of strings): the action may be exercised only through a capability whose identifier is among the named values (a tool or function identity, asserted at the point of use by the enforcing component). Subset: no broader when the candidate array's members are a subset of the reference array's, compared as exact strings. Intersection: the common members; an empty result has no intersection and the combination fails.¶

• requires_action_approval (boolean): when true, each exercise of the action requires a fresh, action-bound approval at the point of use; the enforcing component MUST NOT permit the action on Mission authority alone. A value of false is equivalent to omitting the member. Subset: no broader when the candidate is true or equals the reference (narrowing may add the requirement, never remove it). Intersection: the logical OR of the two values.¶

These comparisons are in value space, not lexical: max_amount amount members are compared as the decimal numbers the strings contain, so "500", "500.0", and "500.00" are equal; resource_issued_after and resource_issued_before values are compared as the instants they denote after normalization to UTC, so two RFC 3339 representations of the same instant that differ only in timezone offset or trailing subsecond zeros are equal; recipient_domain values are compared as DNS names, case-insensitively and on whole labels, so mail.example.com is within example.com and example.net is not. A Common Constraint definition MUST fix its subset and intersection in value-space terms, so that independent deployments compute the same result for the same values and the subset rule of Section 4.1 is reproducible.¶

A decimal-string value in a Common Constraint (max_amount's amount member, and any future Common Constraint with a decimal-valued member) MUST match ^[0-9]+(\.[0-9]{1,18})?$: one or more decimal digits, optionally followed by a single . and one to 18 further decimal digits. A leading - is out of scope for a ceiling value and MUST be rejected. A value of any other form, including scientific notation ("1e300"), a sign, a thousands separator, or a non-numeric token ("NaN", "Infinity"), is malformed, and a consumer MUST reject it rather than attempt to parse it: an authority proposal carrying one is refused at submission ([I-D.draft-mcguinness-oauth-mission]), and a Resource Server treats a malformed decimal value the same as a constraints key it cannot enforce (Section 4.3). Comparison and intersection over two such decimal-string values MUST be computed as exact decimal arithmetic (for example, by scaling both values to integers by their fractional digit count and comparing the integers) and MUST NOT parse either value into an IEEE 754 binary floating-point type: that representation does not hold every value the grammar above admits exactly and can compare or combine two values incorrectly.¶

A numeric constraint value MUST lie within the range JCS [RFC8785] serializes exactly. Monetary amounts avoid that hazard by construction: max_amount carries its amount as a string containing a decimal number, paired with an ISO 4217 [ISO4217] currency code, and a future Common Constraint for a monetary value SHOULD reuse this shape rather than a JSON number.¶

4.3. Resource Server Enforcement

[I-D.draft-mcguinness-oauth-mission] requires a Resource Server to enforce each applicable authorization_details entry according to that entry's own type specification, and to fail closed on an entry whose type it does not implement or cannot fully evaluate. This section states that specification for a mission_resource_access entry. A Resource Server:¶

• MUST enforce an entry whose resource (under resource_match, Section 4) matches the request, permitting only the listed actions subject to constraints. Where more than one applicable entry matches, entries are alternative grants of authority, not conjunctive filters.¶

• MUST treat an entry's resource_match value it does not recognize as unenforceable and fail closed (Section 4).¶

• MUST, when it matches a concrete request URI against a prefix entry, apply the RFC 3986 [RFC3986] normalization Section 4.1 defines for containment, before the prefix comparison rather than after, per the Resource Boundary Canonicalization analysis (Section 6.1).¶

• MUST fail closed on any constraints key it does not understand, or understands but cannot enforce, in an applicable entry: refuse the request (for example, a 403 with insufficient_scope [RFC6750], or the deployment's usual insufficient-authority error) rather than grant access while ignoring the key.¶

• MUST NOT reduce a constraints key to disclosure-only: an unenforced key that narrows authority silently widens the grant if treated as absent or advisory.¶

4.4. Protected Resource Metadata

A protected resource MAY advertise, in its protected resource metadata [RFC9728]:¶

mission_constraints_supported:

OPTIONAL. An array of strings: the constraints keys (Common Constraints and deployment-defined names) the resource understands and enforces (Section 4.3). It gives the AS's duty to emit only keys the serving resource is known to understand (Section 4) a discovery surface, and lets a client predict a fail-closed constraint mismatch before making the request. When absent, that knowledge is established out of band.¶

4.5. Delegate Eligibility

[I-D.draft-mcguinness-oauth-mission] gates a delegated token's carried entries on the entry type's own delegation policy, evaluated at the delegate's delegation depth d (the nesting depth of the token's act claim, as that document defines). For a mission_resource_access entry, the Authorization Server includes it in a delegated token issued at delegation depth d only if all of the following hold:¶

1. the entry carries a delegation member (otherwise it is non-delegable, which is the default);¶

2. d is less than or equal to the entry's delegation.max_depth; and¶

3. the delegate is permitted by delegation.allowed_delegates or, when that member is absent, by the AS's delegation-authorization policy, which the AS MUST apply at every exchange: an absent matcher list is a decision deferred to policy, never a blanket grant of eligibility.¶

An entry failing any of these narrows out of the delegated token, consistent with the subset rule (Section 4.1). The delegation member is policy, not authority, and is not part of the subset comparison; surviving entries are carried with their delegation member intact so the next hop is evaluated the same way.¶

Matching allowed_delegates. Each entry is a matcher object modeled on the RFC 8693 may_act actor object ([RFC8693] Section 4.4): where may_act names a single party eligible to act on a token, allowed_delegates is a per-Authority-Set-entry list of such matchers, generalized to actor-type classes. A { "sub": ... } matcher permits a specific delegate by client identifier; a { "sub_profile": ... } matcher permits any actor of that type (for example, ai_agent). An actor's sub_profile MAY carry multiple space-separated values; a { "sub_profile": ... } matcher is satisfied when its value is among the actor's values. A deployment can thus permit a specific client, a class of actors, or both, and a delegate is permitted if it matches any entry.¶

The AS MUST authenticate the delegate at the Token Exchange and assert the actor's sub and sub_profile itself. A self-asserted sub_profile MUST NOT satisfy a matcher; otherwise a client could claim any actor type to bypass the constraint.¶

A { "sub": ... } matcher is a client identifier in the issuing AS's namespace and is not portable across a trust domain; how a Resource AS evaluates conveyed matchers, failing closed and narrowing out any sub matcher it cannot resolve, is specified by the companion ([I-D.draft-mcguinness-oauth-mission-cross-domain]).¶

4.6. Scope Projection

[I-D.draft-mcguinness-oauth-mission] states the semantic subset condition and issuance algorithm an Authorization Server applies before emitting scope for any authorization_details entry: the projected scope's effective rights, together with every independently mandatory control on the target's enforcement path, MUST be a subset of the rights the applicable entries grant. This section states when that condition holds for a mission_resource_access entry.¶

A scope-projection mapping's entry for this type names, for a target Resource Server: the scope value or values it emits, the resource and resource_match the mapping covers, the actions value or values each scope value stands for, and, for every constraints key an entry may carry, whether the target independently and identically enforces that key on the scope-authorized path.¶

Projecting a mission_resource_access entry's authority to scope is safe only when all of the following hold:¶

1. The resource match is exact under the mapping. The mapping's scope value is defined over the entry's resource and resource_match. A prefix entry projects safely only when the mapping itself scopes the value to that same prefix; a scope value the target's own interpretation extends to a broader ancestor resource is not a safe projection of a narrower prefix entry.¶

2. The actions match without aggregation. The mapping's scope value stands for exactly the entry's actions, action for action. A scope value that stands for an action family, an aggregate of unrelated actions, or the union of more than one entry's actions fails this condition, because the target grants every action the union names, not only the entry's.¶

3. Every carried constraints key is independently enforced. For every key in the entry's constraints, the mapping states that the target enforces that key, under a comparison at least as tight as the entry's value, on the scope-authorized path. An entry with no constraints trivially satisfies this condition. A key the mapping does not name as independently enforced fails the condition for that entry, exactly as an unenforced key fails closed at a Resource Server that consumes authorization_details directly.¶

An entry failing any condition MUST NOT be projected to scope. Per [I-D.draft-mcguinness-oauth-mission]'s issuance algorithm, the Authorization Server then omits scope for that entry where the target's enforcement path consumes authorization_details, and refuses issuance to that target when it is scope-only and no other carried entry supplies a safe projection.¶

4.7. Transformation Capabilities

[I-D.draft-mcguinness-oauth-mission] requires an Authorization Server to declare, for every AS-supported authorization_details type, whether it understands the type's narrowing, delegation, and scope-projection semantics, through deployment documentation or, where available, the machine-readable mission_transformation_capabilities carrier that document defines.¶

For mission_resource_access, an Authorization Server that implements this document in full declares:¶

narrowing: true

The subset and intersection algebra of Section 4.1 and Section 4.2 is fully defined, over every member this document specifies.¶

delegation: true

The delegation policy of Section 4.5 is fully defined; an entry's delegation member states its own depth and eligibility bounds.¶

projection: true

A safe scope projection is defined, and decidable per entry, by Section 4.6; it is not unconditionally available for every entry, and an Authorization Server MUST still apply that section's conditions per entry before emitting scope.¶

An Authorization Server that implements only part of this document (for example, mission_resource_access entries without ever emitting scope for them) declares projection as undeclared rather than true, and [I-D.draft-mcguinness-oauth-mission]'s carried-as-approved fallback then applies to scope projection for this type at that deployment, exactly as it would for an unsupported type.¶

4.8. Modeling Tools and Function Calls

This section is non-normative guidance. A "tool" an agent invokes, such as a Model Context Protocol (MCP) tool or a function call, is modeled as a mission_resource_access entry. No separate entry type is needed, and the rules above (subset, delegation) apply unchanged; derivation, authority_hash, and the Authority Set itself remain [I-D.draft-mcguinness-oauth-mission]'s.¶

The mapping is:¶

• resource is the tool provider. For an MCP tool it is the MCP server's URL. The MCP authorization model ([MCP]) makes the server an OAuth 2.0 resource server, so this is the resource identifier a token is audience-bound to.¶

• actions are the tool names the task needs at that provider. Authorizing a tool is authorizing its name as an action, which lines up with MCP filtering its tool list by the caller's granted authority and routing each tool call for authorization.¶

• constraints carry machine-actionable bounds on a tool's arguments, for example an amount ceiling or a recipient domain (the max_amount and recipient_domain Common Constraints, Section 4.2). Like all constraints, they are committed by authority_hash and carried to the point of use, but they are evaluated against the concrete call arguments by a runtime enforcement layer, not at issuance ([I-D.draft-mcguinness-oauth-mission]).¶

For example, a Mission authorized to read invoices and post small adjustments through a finance MCP server, and to send messages through a messaging MCP server, derives:¶

[
  { "type": "mission_resource_access",
    "resource": "https://finance.example.com/mcp",
    "actions": ["query_invoices", "post_adjustment"],
    "constraints": {
      "max_amount": { "amount": "500.00", "currency": "USD" }
    } },
  { "type": "mission_resource_access",
    "resource": "https://mail.example.com/mcp",
    "actions": ["send_message"],
    "constraints": { "recipient_domain": "example.com" } }
]

Delegation to a sub-agent works unchanged: add a delegation member to a tool entry (Section 4.5). For example, an entry a sub-agent of type ai_agent may invoke at depth 1, narrowed to the read tool only:¶

{ "type": "mission_resource_access",
  "resource": "https://finance.example.com/mcp",
  "actions": ["query_invoices"],
  "delegation": {
    "max_depth": 1,
    "allowed_delegates": [{ "sub_profile": "ai_agent" }]
  } }

What this profile does not provide for tools is a typed, attenuable per-argument constraint grammar: narrowing one tool's argument schema against another (for example, amount in a range, recipient in a one_of set) as the grant is derived or delegated. Argument bounds here are the same flat, carried constraints used for any resource, evaluated at runtime. Structured per-argument attenuation ([I-D.draft-niyikiza-oauth-attenuating-agent-tokens], with object capability systems such as UCAN as prior art) is a richer primitive deferred to future work; it would extend the delegation and subset model of this document (Section 4.5, Section 4.1) rather than introduce a new entry type.¶

6.1. Resource Boundary Canonicalization

A prefix entry (Section 4) draws an authority boundary in URI space. The AS's containment test (Section 4.1) and the Resource Server's request matching (Section 4.3) MUST apply the single RFC 3986 [RFC3986] normalization defined in Section 4.1, so issuance and enforcement draw the same boundary. A matcher that normalizes differently from the party that derived the entry can admit a request the Approver never authorized, or deny one it did.¶

The normalization MUST run before the prefix comparison, never after, and the boundary MUST be evaluated on the same normalized form a downstream component will act on. The following vectors each turn on such a difference:¶

• Encoded slash (%2F). A reserved octet, left encoded by this normalization (which decodes only unreserved octets) and never a path-segment separator when matching. An intermediary that decodes it before the Resource Server enforces shifts the boundary; a deployment MUST prevent that rewriting or account for it.¶

• Encoded dot (%2e, %2e%2e). The . octet is unreserved, so this normalization decodes it and then removes dot-segments. The hazard is order: normalizing before the comparison collapses a decoded %2e%2e out of the path and draws the boundary correctly, while matching the raw string first and letting a downstream component decode and collapse afterward can escape the prefix.¶

• Double or empty path segments. An empty path and / denote the same base (Section 4); a matcher MUST NOT coalesce // or trailing-slash differences of its own, since the Section 4.1 normalization does not.¶

• Default-port presence. https://a.example:443 and https://a.example are one authority only after the default-port removal Section 4.1 performs; a matcher that skips it splits one boundary into two.¶

• Unicode and IDNA host. The Section 4.1 normalization lowercases the host but does not define Unicode to A-label (IDNA) conversion, so a deployment that accepts non-ASCII hosts MUST ensure both sides compare the same form.¶

• Percent-decoding order. This normalization decodes only unreserved octets and runs before comparison; decoding reserved octets, or decoding after the comparison, changes which characters count as separators and can move the boundary.¶

These vectors make the rule concrete. For a prefix entry whose resource is https://api.example/orders, a concrete request URI matches as follows:¶

A deployment MAY agree out of band on the canonicalization profile its AS and Resource Servers apply; this document defines one rule (Section 4.1), so no profile identifier is required for interoperation.¶

8.1. The Mission Resource Access Authorization Details Type

mission_resource_access is an authorization_details type per [RFC9396] Section 2, defined by this document in Section 4. RFC 9396 does not establish an IANA registry of authorization details types (type identifiers are interpreted by the Authorization Server), so this document creates no registry entry for it and requires no IANA action here. If a registry of authorization details types is established in the future, this type SHOULD be registered in it.¶

8.2. OAuth Protected Resource Metadata Registration

This document registers the following in the "OAuth Protected Resource Metadata" registry ([RFC9728]):¶

• Metadata Name: mission_constraints_supported¶

• Metadata Description: JSON array of the constraints keys the protected resource understands and enforces.¶

• Change Controller: IESG¶

• Specification Document(s): this document, Section 4.4¶

8.3. Common Constraints Registry

This document establishes the "Mission Common Constraints" registry. The registration policy is Specification Required [RFC8126]. A Designated Expert reviews a submission for the discipline Section 4.2 requires: a name matching ^[A-Za-z0-9_.:-]+$ not already registered, a JSON [RFC8259] value syntax precise enough for independent implementations to agree on, and a subset rule and an intersection rule both stated in value-space terms, with the intersection of any two valid values never broader than either operand. Registration does not require IETF review or a Standards Track document; a Specification Required reference that a Designated Expert can review against these criteria suffices.¶

Each registration records:¶

• Key Name: the constraints member name.¶

• Value Space: the JSON value type and any additional syntax rules.¶

• Subset Rule: how a candidate value is judged no broader than a reference value.¶

• Intersection Rule: how two values for the key combine into a result no broader than either operand.¶

• Change Controller: IETF, or the registrant for any other registration.¶

• Reference: the specification defining the key.¶

This document populates the registry with the Common Constraints it defines (Section 4.2); the "Ref" column below is this document, at the section shown, for every row, and the full Subset Rule and Intersection Rule text is there, not restated in the table:¶

Names are kept collision-free by the convention Section 4.2 already uses: a specification-defined name is coordinated through this registry, and any other name is either collision-resistant or remains deployment-defined and outside the registry.¶

9.1. Normative References

[I-D.draft-mcguinness-oauth-mission]

McGuinness, K., "Mission-Bound Authorization for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission.html>.

[ISO4217]

International Organization for Standardization, "ISO 4217:2015, Codes for the representation of currencies and funds", ISO 4217:2015, August 2015.

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

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/rfc/rfc3339>.

[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, <https://www.rfc-editor.org/rfc/rfc3986>.

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

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

[RFC8259]

Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/rfc/rfc8259>.

[RFC8693]

Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, <https://www.rfc-editor.org/rfc/rfc8693>.

[RFC8707]

Campbell, B., Bradley, J., and H. Tschofenig, "Resource Indicators for OAuth 2.0", RFC 8707, DOI 10.17487/RFC8707, February 2020, <https://www.rfc-editor.org/rfc/rfc8707>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

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

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

9.2. Informative References

[I-D.draft-mcguinness-oauth-mission-cross-domain]

McGuinness, K., "Mission Cross-Domain Projection for OAuth 2.0", 2026, <https://mcguinness.github.io/mission-bound-authorization/draft-mcguinness-oauth-mission-cross-domain.html>.

[I-D.draft-niyikiza-oauth-attenuating-agent-tokens]

Aimable, N., "Attenuating Authorization Tokens for Agentic Delegation Chains", Work in Progress, Internet-Draft, draft-niyikiza-oauth-attenuating-agent-tokens-01, 15 June 2026, <https://datatracker.ietf.org/doc/html/draft-niyikiza-oauth-attenuating-agent-tokens-01>.

[MCP]

Model Context Protocol Project, "Model Context Protocol: Authorization", 2026, <https://modelcontextprotocol.io/specification/2026-07-28/basic/authorization>.

[RFC8126]

Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.