OAuth Actor Receipts for Delegation Provenance

7.1. JOSE Header

The JOSE header of an actor receipt:¶

• MUST include an asymmetric digital-signature alg value;¶

• MUST NOT use alg: none or a MAC-based symmetric algorithm;¶

• MUST include typ with the value actor-receipt+jwt;¶

• SHOULD include kid when the issuer publishes multiple verification keys.¶

Receipt issuers and consumers MUST apply the JWT best practices in [RFC8725].¶

7.2. Receipt Claims

The JWT payload of an actor receipt uses the following claims:¶

iss:

REQUIRED. The issuer that created and signed the receipt for the corresponding actor hop. This value identifies the receipt signer. The act.iss value inside the receipt identifies the namespace authority for act.sub, using the meaning defined by the core actor profile. These values MAY be the same entity or different entities. When they differ, consumers MUST validate trust in the receipt signer and namespace authority according to their respective roles under local policy; the difference alone does not make the receipt invalid under this profile.¶

sub:

REQUIRED. The top-level sub value that was present in the token issued at this hop.¶

sub_profile:

OPTIONAL. The top-level sub_profile value, when the token issued at this hop carried one.¶

act:

REQUIRED. A single-hop actor object. This object:¶

• MUST conform to the core actor profile's actor-object rules;¶

• MUST include act.sub and act.iss;¶

• MAY include act.sub_profile;¶

• MUST NOT contain cnf;¶

• MUST NOT contain a nested act.¶

The prohibition on act.cnf exists because a cnf claim inside an act object would create ambiguity about whether it represents a historical key binding or a current proof-of-possession requirement for the actor. Historical presenter binding belongs at the receipt's top level in the cnf claim, where its role as provenance-only information is unambiguous. Additional claims permitted by the core actor profile in act objects MAY appear in receipt act objects unless explicitly prohibited here. A receipt that carries act.cnf is invalid under this profile.¶

cnf:

OPTIONAL. A confirmation claim as defined in [RFC7800]. When present, it MUST equal the top-level cnf claim of the token issued at this hop. This value records historical presenter-binding information for the hop represented by the receipt. It does not create a current proof-of-possession obligation for the current request. Issuers SHOULD NOT include cnf in a receipt unless the relying parties that will receive the token have been evaluated for the associated disclosure risk; omitting cnf does not invalidate the receipt.¶

prh:

OPTIONAL. Previous receipt hash. When present, prh MUST be the base64url-encoded SHA-256 hash of the complete compact serialization of the next older receipt in the chain. The oldest receipt in the chain MUST omit prh.¶

iat:

REQUIRED. The time at which the receipt was created, as defined in [RFC7519].¶

exp:

REQUIRED. Expiration time for the receipt, as defined in [RFC7519]. exp MUST be set to a value that covers the expected maximum token lifetime of any token that will carry or inherit this receipt, so that consumer validation of older receipts in a valid chain is not prematurely rejected. Short exp values on receipts limit the window during which a compromised receipt signing key can be exploited.¶

jti:

REQUIRED. A unique identifier for the receipt, as defined in [RFC7519].¶

token_id:

RECOMMENDED. The jti value of the specific outer token that this receipt was created for. When present, token_id binds the receipt to the specific token instance issued at this hop, enabling consumers to detect receipts transplanted from a different token whose visible act structure happens to match. Issuers SHOULD include token_id whenever the token they are issuing carries a jti claim.¶

A receipt MAY contain additional claims defined by another specification or by deployment policy. Consumers MUST ignore unrecognized claims unless another specification or local agreement defines their meaning.¶

7.3. Receipt-Chain Linkage

When the issuer creates a new receipt and prepends it to an inherited receipt chain:¶

• if there is an older receipt immediately following it in the array, the new receipt MUST include prh, and that value MUST hash the exact compact JWT string of that next receipt;¶

• if the new receipt is the only receipt in the array, it MUST omit prh.¶

No JSON canonicalization is applied. prh hashes the exact compact-serialized JWS string of the next older receipt as carried in the array. Systems that carry, store, or forward actor_receipts arrays MUST preserve each compact JWT string byte-for-byte without parsing, re-serializing, normalizing whitespace, or re-encoding base64url segments. Any modification to a receipt string — even a semantically equivalent one — invalidates prh for any receipt that references it.¶

8.1. Creating the First Receipt

When an issuer creates a delegated token with a new outermost actor hop and no inbound actor_receipts are being preserved, the issuer MAY create a new one-element actor_receipts array.¶

If it does so, the new receipt:¶

• MUST describe the new outermost actor hop;¶

• MUST set sub to the issued token's top-level sub;¶

• MUST set act.sub and act.iss to the new outermost actor;¶

• MUST copy the issued token's top-level cnf, if any, into the receipt cnf, subject to the disclosure considerations in Section 7.2;¶

• SHOULD set token_id to the issued token's jti, if the issued token carries a jti;¶

• MUST omit prh.¶

8.2. Extending an Existing Receipt Chain

When an issuer adds a new outermost actor hop and also preserves an inbound actor_receipts array, it:¶

1. MUST validate the inbound receipt chain before relying on it or carrying it forward.¶

2. MUST preserve each inbound receipt byte-for-byte unchanged.¶

3. MUST create exactly one new receipt for the new outermost actor hop.¶

4. MUST prepend that new receipt to the inherited array.¶

5. MUST set the new receipt's prh, if the inherited array is non-empty, to the SHA-256 hash of the exact compact serialization of the receipt that is now at the next array index.¶

An issuer MUST NOT reserialize, resign, normalize, trim, or otherwise alter a prior receipt.¶

If inbound receipts fail validation, the issuer MUST NOT propagate them. It MAY continue without actor_receipts only when local policy permits partial coverage; otherwise it MUST fail the request under the error model of the underlying protocol.¶

8.3. Reissuance Without a New Actor Hop

An issuer that reissues, translates, or introspects and re-emits a token without adding a new outermost actor hop:¶

• MAY carry an inbound actor_receipts array forward unchanged;¶

• MUST NOT create a new receipt;¶

• MUST NOT continue to carry an inherited actor_receipts array if it cannot preserve the visible hop alignment required by Section 9.¶

If such an issuer changes the visible outermost actor, it has added a new hop and MUST follow Section 8.2.¶

A change in the outer token's top-level cnf value, by itself, does not invalidate carried-forward receipts. Receipt cnf records the historical presenter binding in effect when that hop was created. The current token's top-level cnf can later change, for example because of key rotation or token reissuance, without requiring a new receipt so long as the visible actor hop itself is unchanged.¶

8.4. Partial Coverage and Full Coverage

This document permits partial receipt coverage for progressive deployment. An issuer MAY begin a new receipt chain even when older inner actor hops remain visible but uncovered.¶

However:¶

• a partial chain MUST still cover a contiguous outermost prefix of the visible actor chain;¶

• an issuer MUST NOT skip an outer visible hop and receipt only an inner visible hop;¶

• when local policy or resource requirements require full provenance, the issuer MUST either emit complete receipt coverage or fail the request under the error model of the underlying protocol.¶

8.5. Transaction Token Service Rebinding

When a Transaction Token Service establishes a new presenter and makes that presenter the new outermost actor, it follows the same receipt rules as any other issuer that adds a new outermost actor hop:¶

• it validates and preserves any inbound actor_receipts;¶

• it creates one new receipt for the newly established outermost actor;¶

• it copies the issued Transaction Token's top-level cnf, if any, into the new receipt, subject to the disclosure considerations in Section 7.2.¶

This profile does not define additional receipt claims specific to Transaction Tokens. Any transaction-specific semantics remain governed by the Transaction Token itself and its deployment profile.¶

9.1. Subject Re-Expression Across Hops

Older receipts can carry a different sub value from the current outer token when the subject has been re-expressed across issuer namespaces. This document does not define a universal subject-mapping algorithm.¶

Accordingly:¶

• only receipt[0].sub is required to equal the current outer token sub;¶

• older receipt sub values MAY differ;¶

• a recipient that applies stronger continuity requirements across older sub values MUST do so under explicit trusted local mapping rules.¶

Recipients MUST be aware that permitting differing sub values across receipts creates a cross-subject insertion risk: a receipt from an unrelated subject chain that happens to share the same actor identity could satisfy the structural hop-alignment check. Deployments where subject continuity is a security requirement SHOULD require consistent sub values across all receipts in the chain, or enforce explicit trusted subject-mapping rules that can positively confirm each distinct sub value refers to the same underlying entity. When neither condition is met, the recipient MUST treat the differing sub values as unverified subject continuity and MUST NOT rely on those older receipts for authorization decisions.¶

9.2. Complete Receipt Coverage

A recipient determines complete receipt coverage by comparing receipt count with visible actor depth. If the number of receipts equals the visible actor depth and all validation rules above succeed, the token has complete receipt coverage for the visible chain.¶

If local policy or resource requirements require full provenance, the recipient MUST reject tokens that do not have complete receipt coverage.¶

9.3. Use by Resource Servers

Resource servers can use validated actor receipts as provenance input for authorization, diagnostics, and audit. However, a valid receipt chain:¶

• proves only that trusted issuers attested specific visible actor hops;¶

• does not prove that the current token's audience, scope, or expiration were in force when older receipts were created;¶

• does not replace the need to authorize the current token itself.¶

9.4. Introspection

When an authorization server returns actor-receipt information in an OAuth Token Introspection response [RFC7662], it:¶

• MAY return actor_receipts using the same array format defined in Section 6;¶

• MAY return actor_receipts_complete to indicate whether the returned array provides complete coverage for the visible chain as known to the introspection server.¶

An introspection server that suppresses one or more receipts for privacy or policy reasons and still returns actor_receipts SHOULD return actor_receipts_complete with the value false.¶

The core actor profile [I-D.mcguinness-oauth-actor-profile] defines a separate chain_complete introspection member that indicates whether the visible act chain itself has been filtered. These two completeness signals are distinct: chain_complete: false means the introspection server has suppressed inner act hops from the chain representation, while actor_receipts_complete: false means receipt coverage is partial or filtered. A token can have chain_complete: true (full act chain visible) and actor_receipts_complete: false (some receipts suppressed), or vice versa. Consumers that rely on both signals MUST evaluate them independently. A response with chain_complete: false means the receipt array may cover only part of the true delegation chain even when actor_receipts_complete: true; in that case the receipt coverage is complete only for the visible filtered chain, not the full chain.¶

10.1. Authorization Server Metadata

The following parameter is defined for use in Authorization Server Metadata [RFC8414]:¶

actor_receipts_supported:

OPTIONAL. A boolean. When true, the authorization server advertises that it can validate inbound actor receipts and can originate, preserve, or extend receipt chains according to this document. This value does not guarantee complete historical coverage for every visible hop in every resulting token. When false or absent, clients and relying parties MUST NOT assume such support.¶

This parameter applies equally to an authorization server that issues delegated JWT outputs and to a Transaction Token Service publishing metadata through the same framework.¶

10.2. Protected Resource Metadata

The following parameters are defined for use in Protected Resource Metadata [RFC9728]:¶

actor_receipts_required:

OPTIONAL. A boolean. When true, the resource server indicates that delegated requests are expected to carry valid actor receipts covering at minimum the outermost visible actor hop. When false or absent, the resource server makes no metadata declaration about receipt-based provenance requirements.¶

actor_receipts_complete_required:

OPTIONAL. A boolean. When true, the resource server indicates that it requires complete receipt coverage — the receipt count must equal the visible actor-chain depth and actor_receipts_complete must be true in the outer token or the introspection response. This parameter refines actor_receipts_required; a resource server SHOULD NOT set actor_receipts_complete_required: true without also setting actor_receipts_required: true. When false or absent, partial receipt coverage is acceptable to the resource server, subject to any further local policy.¶

10.3. Introspection Response Members

The following members are defined for use in OAuth Token Introspection responses [RFC7662]:¶

actor_receipts:

OPTIONAL. An array of strings using the same syntax as the JWT claim of the same name.¶

actor_receipts_complete:

OPTIONAL. A boolean. When true, the introspection response indicates that the returned actor_receipts cover every visible hop in the token chain as known to the introspection server. When false, the response indicates that coverage is partial or that the server has filtered or withheld one or more receipts.¶

11.1. Current Presenter Validation

The current request is always validated against the outer token's top-level cnf, when present, using the proof mechanism appropriate to the token type and deployment. Receipt cnf values are historical only. A recipient MUST NOT treat an older receipt cnf value as sufficient proof for the current request.¶

The current top-level cnf can differ from the outermost receipt cnf after a later reissuance or key rotation that does not add a new actor hop. That difference does not by itself invalidate the receipt chain under this profile.¶

11.2. Trust in Receipt Issuers

Receipt validation is meaningful only if the recipient trusts the issuers that signed the receipts. A recipient MUST establish which issuers it trusts for receipt validation before relying on actor_receipts. Trust MUST be established through explicit pre-configuration, bilateral agreement, federation policy, or another explicit trust framework. A recipient MUST NOT treat the presence of a syntactically valid signed receipt as sufficient grounds to trust its issuer.¶

Authorization servers that support this document SHOULD advertise actor_receipts_supported: true in their AS metadata [RFC8414]. Consumers SHOULD use this metadata signal as one input to trust establishment, but MUST NOT treat metadata advertisement alone as sufficient grounds to trust a receipt issuer; the issuer must also be within the recipient's configured trust boundary.¶

To avoid attacker-controlled key resolution, a recipient MUST determine whether a receipt iss is within its trusted-issuer set before performing any network retrieval for that issuer's metadata or keys. A recipient that uses dynamic discovery for receipt validation MUST do so only within an existing trust framework or equivalent local policy that defines which issuers are permitted.¶

11.3. Receipt-to-Token Binding Limits

Receipts prove that trusted issuers attested particular actor hops and, optionally, historical presenter bindings. They do not by themselves prove that the current outer token's audience, scope, expiration, or other authorization details were in force when older receipts were created.¶

Accordingly, a recipient MUST NOT treat a valid receipt chain as evidence of historical authorization scope or audience beyond what the current outer token itself authorizes.¶

11.4. Compromised Outer Issuer

Receipts provide their strongest additional assurance against a compromised or dishonest downstream issuer attempting to fabricate prior-hop provenance. That downstream issuer cannot forge prior issuers' receipt signatures.¶

However, if the current outer token issuer is compromised, that issuer can still assemble a new outer token around previously harvested valid receipts for the same visible chain prefix. This document does not attempt to solve that class of attack. Deployments that need stronger guarantees can combine this profile with additional transparency, transaction binding, or replay-detection mechanisms outside the scope of this document.¶

11.5. Receipt Signing Key Compromise

If a receipt issuer's signing key is compromised, previously issued receipts signed with that key cannot be individually revoked. The primary remediation is to remove the compromised issuer from the trusted-issuer set; once removed, consumers will reject all receipts signed by that issuer regardless of their content.¶

Deployments SHOULD set short exp values on receipts, consistent with the REQUIRED exp defined in Section 7.2, to limit the window during which receipts signed with a compromised key remain valid. When a key compromise is detected, deployments SHOULD treat all tokens carrying receipts from the affected issuer as lacking trusted provenance for those hops and SHOULD require re-issuance through a trusted issuer.¶

11.6. Historical cnf Disclosure

Receipt cnf values can reveal prior-hop public-key identifiers or certificate thumbprints to any party that receives the token or introspection response. These are stable identifiers that can enable cross-request and cross-service correlation of actors and services over time. Issuers SHOULD NOT include cnf in receipts unless the relying parties that will receive the token have been evaluated for that disclosure risk and the risk is acceptable. Omitting cnf from a receipt does not invalidate the receipt; it means that hop lacks independently attested historical presenter binding, which is acceptable for many deployments.¶

13.1. Media Type Registration

This document requests registration of the following media type in the "Media Types" registry [RFC6838]:¶

• Type name: application¶

• Subtype name: actor-receipt+jwt¶

• Required parameters: N/A¶

• Optional parameters: N/A¶

• Encoding considerations: 8bit; an actor receipt is a JWS compact-serialized JWT consisting of base64url-encoded segments separated by period (.) characters.¶

• Security considerations: See Section 11 of this document and [RFC8725].¶

• Interoperability considerations: N/A¶

• Published specification: This document¶

• Applications that use this media type: Applications that issue, exchange, or validate OAuth Actor Receipts.¶

• Fragment identifier considerations: N/A¶

• Additional information:¶

  • Deprecated alias names for this type: N/A¶

  • Magic number(s): N/A¶

  • File extension(s): N/A¶

  • Macintosh file type code(s): N/A¶

• Person & email address to contact for further information: Karl McGuinness, public@karlmcguinness.com¶

• Intended usage: COMMON¶

• Restrictions on usage: None¶

• Author: IETF¶

• Change controller: IETF¶

The JOSE typ value actor-receipt+jwt used by this document is the media type subtype name without the application/ prefix, following common JWT typing practice.¶

13.2. JSON Web Token Claims Registration

This document requests registration of the following JWT Claims in the "JSON Web Token Claims" registry [RFC7519]:¶

• Claim Name: actor_receipts¶

• Claim Description: Array of signed actor-hop receipts providing delegation provenance¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

• Claim Name: actor_receipts_complete¶

• Claim Description: Boolean indicating whether actor_receipts covers every visible hop in the token's act chain¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

• Claim Name: prh¶

• Claim Description: Base64url-encoded SHA-256 hash of the immediately preceding (older) receipt in the actor_receipts chain¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

• Claim Name: token_id¶

• Claim Description: The jti of the specific token instance that this actor receipt was created for¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

13.3. OAuth Authorization Server Metadata Registration

This document requests registration of the following metadata name in the "OAuth Authorization Server Metadata" registry [RFC8414]:¶

• Metadata Name: actor_receipts_supported¶

• Metadata Description: Indicates support for validating, issuing, preserving, or extending actor-receipt chains¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

13.4. OAuth Protected Resource Metadata Registration

This document requests registration of the following metadata names in the "OAuth Protected Resource Metadata" registry [RFC9728]:¶

• Metadata Name: actor_receipts_required¶

• Metadata Description: Indicates that the resource expects delegated requests to carry valid actor receipts covering at minimum the outermost visible actor hop¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

• Metadata Name: actor_receipts_complete_required¶

• Metadata Description: Indicates that the resource requires complete receipt coverage for all visible actor hops¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

13.5. OAuth Token Introspection Response Registration

This document requests registration of the following names in the "OAuth Token Introspection Response" registry [RFC7662]:¶

• Name: actor_receipts¶

• Description: Array of signed actor-hop receipts returned by introspection¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

• Name: actor_receipts_complete¶

• Description: Indicates whether the returned actor receipts provide complete visible-hop coverage¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

14.1. Two-Hop Delegation Chain

The outer token carries the following visible actor chain:¶

{
  "sub": "https://idp.enterprise.example/users/alice",
  "act": {
    "sub": "https://tools.example.com/booking-tool",
    "iss": "https://as.travel-provider.example",
    "sub_profile": "service",
    "act": {
      "sub": "https://agents.example.com/travel-assistant",
      "iss": "https://as.enterprise.example",
      "sub_profile": "ai_agent"
    }
  },
  "cnf": {
    "jkt": "ToolJKT"
  },
  "actor_receipts": [
    "<receipt-0>",
    "<receipt-1>"
  ],
  "actor_receipts_complete": true
}

actor_receipts[0] is the newest receipt, created by the travel-provider AS when it added the booking tool as the new outermost actor:¶

{
  "iss": "https://as.travel-provider.example",
  "sub": "https://idp.enterprise.example/users/alice",
  "act": {
    "sub": "https://tools.example.com/booking-tool",
    "iss": "https://as.travel-provider.example",
    "sub_profile": "service"
  },
  "cnf": {
    "jkt": "ToolJKT"
  },
  "prh": "0QvKZr5A4XW7N9LQW0u4e7z8k2Kqz6I7xL4V4Vh2nRc",
  "iat": 1776745200,
  "exp": 1776832000,
  "jti": "c8e29c11-0c3a-4e6f-a0a6-30a52c4a8149",
  "token_id": "d3a1b2c0-9f4e-4a1d-b8e7-12345678abcd"
}

actor_receipts[1] is the older receipt, created by the enterprise AS when it first added the AI agent:¶

{
  "iss": "https://as.enterprise.example",
  "sub": "https://idp.enterprise.example/users/alice",
  "act": {
    "sub": "https://agents.example.com/travel-assistant",
    "iss": "https://as.enterprise.example",
    "sub_profile": "ai_agent"
  },
  "cnf": {
    "jkt": "AgentJKT"
  },
  "iat": 1776741600,
  "exp": 1776832000,
  "jti": "1d4c4d30-fb6d-4172-b7eb-775b6b9c2b85",
  "token_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890"
}

This example shows the key provenance property of this profile: the current token is bound to ToolJKT, while the older receipt preserves that the earlier actor hop was bound to AgentJKT when it was created.¶

14.2. Transaction Token Service Rebinding

Suppose the booking tool exchanges the access token above at a TTS, and the TTS rebinds the issued Transaction Token to an internal workload identified as https://wimse.travel-provider.example/workloads/payments.¶

The resulting Transaction Token can carry:¶

{
  "sub": "https://idp.enterprise.example/users/alice",
  "act": {
    "sub": "https://wimse.travel-provider.example/workloads/payments",
    "iss": "https://tts.travel-provider.example",
    "sub_profile": "service",
    "act": {
      "sub": "https://tools.example.com/booking-tool",
      "iss": "https://as.travel-provider.example",
      "sub_profile": "service",
      "act": {
        "sub": "https://agents.example.com/travel-assistant",
        "iss": "https://as.enterprise.example",
        "sub_profile": "ai_agent"
      }
    }
  },
  "cnf": {
    "jkt": "PaymentsJKT"
  },
  "actor_receipts": [
    "<receipt-tts>",
    "<receipt-0>",
    "<receipt-1>"
  ],
  "actor_receipts_complete": true
}

The new leading receipt created by the TTS is:¶

{
  "iss": "https://tts.travel-provider.example",
  "sub": "https://idp.enterprise.example/users/alice",
  "act": {
    "sub": "https://wimse.travel-provider.example/workloads/payments",
    "iss": "https://tts.travel-provider.example",
    "sub_profile": "service"
  },
  "cnf": {
    "jkt": "PaymentsJKT"
  },
  "prh": "C4zv2FK0kPjxzJz8F7G3mslmbb0TQmVQvls0gA1lV3Q",
  "iat": 1776747000,
  "exp": 1776832000,
  "jti": "8b1ab6d1-c345-4bd3-8af2-f302d54444b7",
  "token_id": "f0e1d2c3-b4a5-6789-cdef-012345678901"
}

The inherited receipts for the booking tool and the AI agent are carried forward unchanged.¶

16.1. Normative References

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.

[RFC7515]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, <https://www.rfc-editor.org/info/rfc7515>.

[RFC7519]

Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, <https://www.rfc-editor.org/info/rfc7519>.

[RFC7662]

Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, <https://www.rfc-editor.org/info/rfc7662>.

[RFC7800]

Jones, M., Bradley, J., and H. Tschofenig, "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)", RFC 7800, DOI 10.17487/RFC7800, April 2016, <https://www.rfc-editor.org/info/rfc7800>.

[RFC8414]

Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, <https://www.rfc-editor.org/info/rfc8414>.

[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/info/rfc8693>.

[RFC8725]

Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, <https://www.rfc-editor.org/info/rfc8725>.

[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/info/rfc9728>.

[I-D.ietf-oauth-transaction-tokens]

Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-08, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-08>.

[I-D.mcguinness-oauth-actor-profile]

McGuinness, K., "OAuth Actor Profile for Delegation", 27 April 2026, <https://mcguinness.github.io/draft-mcguinness-oauth-actor-profile/draft-mcguinness-oauth-actor-profile.html>.

[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/info/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/info/rfc8174>.

16.2. Informative References

[RFC6749]

Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.

[RFC7638]

Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/info/rfc7638>.

[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/info/rfc8126>.

[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/info/rfc9068>.

[RFC9449]

Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, <https://www.rfc-editor.org/info/rfc9449>.

[RFC9700]

Lodderstedt, T., Bradley, J., Labunets, A., and D. Fett, "Best Current Practice for OAuth 2.0 Security", BCP 240, RFC 9700, DOI 10.17487/RFC9700, January 2025, <https://www.rfc-editor.org/info/rfc9700>.