Web Authorization Protocol K. McGuinness Internet-Draft Independent Intended status: Standards Track 9 October 2026 Expires: 12 April 2027 OAuth Actor Receipts for Delegation Provenance draft-mcguinness-oauth-actor-receipts-01 Abstract This document defines OAuth Actor Receipts, an optional companion to the OAuth Actor Profile for Delegation. Each receipt is a signed JSON Web Token (JWT) attesting which issuer added an actor hop and, optionally, the hop's historical presenter binding. The actor_receipts claim carries a hash-linked chain of receipts that recipients verify against each hop's issuer. This document specifies receipt processing rules and the associated metadata parameters and introspection response members. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mcguinness.github.io/draft-mcguinness-oauth-actor-profile/ draft-mcguinness-oauth-actor-receipts.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- mcguinness-oauth-actor-receipts/. Discussion of this document takes place on the Web Authorization Protocol Working Group mailing list (mailto:oauth@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/oauth/. Subscribe at https://www.ietf.org/mailman/listinfo/oauth/. Source for this draft and an issue tracker can be found at https://github.com/mcguinness/draft-mcguinness-oauth-actor-profile. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. McGuinness Expires 12 April 2027 [Page 1] Internet-Draft OAuth Actor Receipts October 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Actor Receipts Overview . . . . . . . . . . . . . . . . . . . 6 4. The actor_receipts Claim . . . . . . . . . . . . . . . . . . 7 5. Actor Receipt JWT Format . . . . . . . . . . . . . . . . . . 7 5.1. JOSE Header . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Receipt Claims . . . . . . . . . . . . . . . . . . . . . 8 5.2.1. Identity Claims . . . . . . . . . . . . . . . . . . . 8 5.2.2. Historical Presenter Binding . . . . . . . . . . . . 9 5.2.3. Chain Linkage . . . . . . . . . . . . . . . . . . . . 10 5.2.4. Time and Uniqueness . . . . . . . . . . . . . . . . . 10 5.2.5. Outer-Token Binding . . . . . . . . . . . . . . . . . 11 5.2.6. Excluded Standard Claims . . . . . . . . . . . . . . 12 5.2.7. Extension Claims . . . . . . . . . . . . . . . . . . 12 5.3. Receipt-Chain Linkage . . . . . . . . . . . . . . . . . . 12 6. Issuer Processing . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Creating the First Receipt . . . . . . . . . . . . . . . 13 6.2. Extending an Existing Receipt Chain . . . . . . . . . . . 13 6.3. Reissuance Without a New Actor Hop . . . . . . . . . . . 14 6.4. Partial Coverage and Full Coverage . . . . . . . . . . . 16 6.5. Transaction Token Service Rebinding . . . . . . . . . . . 17 7. Consumer Processing . . . . . . . . . . . . . . . . . . . . . 17 7.1. Receipt Instance Binding . . . . . . . . . . . . . . . . 21 7.2. Subject Re-Expression Across Hops . . . . . . . . . . . . 22 7.3. Complete Receipt Coverage . . . . . . . . . . . . . . . . 22 McGuinness Expires 12 April 2027 [Page 2] Internet-Draft OAuth Actor Receipts October 2026 7.4. Use by Resource Servers . . . . . . . . . . . . . . . . . 23 7.5. Introspection . . . . . . . . . . . . . . . . . . . . . . 23 8. Discovery and Capability Signaling . . . . . . . . . . . . . 24 8.1. Authorization Server Metadata . . . . . . . . . . . . . . 24 8.2. Protected Resource Metadata . . . . . . . . . . . . . . . 24 8.3. Introspection Response Members . . . . . . . . . . . . . 25 8.4. Claim-Pair Convention for Sibling Profiles . . . . . . . 26 9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Authorization Server and Transaction Token Service Errors . . . . . . . . . . . . . . . . . . . . . . . . . 27 9.2. Resource Server Errors . . . . . . . . . . . . . . . . . 27 9.3. Introspection Server Behavior . . . . . . . . . . . . . . 28 10. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 28 11. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 30 11.1.1. Adversaries Mitigated by This Profile . . . . . . . 30 11.1.2. Adversaries Not Mitigated . . . . . . . . . . . . . 30 11.2. Current Presenter Validation . . . . . . . . . . . . . . 31 11.3. Trust in Receipt Issuers . . . . . . . . . . . . . . . . 31 11.4. Receipt-to-Token Binding Limits . . . . . . . . . . . . 32 11.4.1. Strict-Mode Validation . . . . . . . . . . . . . . . 33 11.5. Hash Algorithm Agility . . . . . . . . . . . . . . . . . 33 11.6. Compromised Outer Issuer . . . . . . . . . . . . . . . . 33 11.7. Receipt Freshness and Replay . . . . . . . . . . . . . . 34 11.8. Receipt Signing Key Compromise . . . . . . . . . . . . . 34 11.9. Receipt Chain Size . . . . . . . . . . . . . . . . . . . 34 11.10. Historical cnf Disclosure . . . . . . . . . . . . . . . 34 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 12.1. What Receipts Disclose . . . . . . . . . . . . . . . . . 35 12.2. Minimization . . . . . . . . . . . . . . . . . . . . . . 35 12.3. Selective Disclosure . . . . . . . . . . . . . . . . . . 35 12.4. Audience Restriction . . . . . . . . . . . . . . . . . . 36 12.5. Unnecessary Hop Disclosure . . . . . . . . . . . . . . . 36 12.6. Cross-Service Correlation . . . . . . . . . . . . . . . 36 12.7. Detached Verification Privacy . . . . . . . . . . . . . 37 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 13.1. Media Type Registration . . . . . . . . . . . . . . . . 37 13.2. JSON Web Token Claims Registration . . . . . . . . . . . 38 13.3. OAuth Authorization Server Metadata Registration . . . . 39 13.4. OAuth Protected Resource Metadata Registration . . . . . 40 13.5. OAuth Token Introspection Response Registration . . . . 40 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 15.1. Normative References . . . . . . . . . . . . . . . . . . 41 15.2. Informative References . . . . . . . . . . . . . . . . . 43 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 44 A.1. Example: Two-Hop Delegation Chain . . . . . . . . . . . . 44 A.2. Example: Transaction Token Service Rebinding . . . . . . 46 McGuinness Expires 12 April 2027 [Page 3] Internet-Draft OAuth Actor Receipts October 2026 A.3. Example: Partial Receipt Coverage . . . . . . . . . . . . 48 A.4. Example: Reissuance Without a New Actor Hop . . . . . . . 50 Document History . . . . . . . . . . . . . . . . . . . . . . . . 51 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 52 1. Introduction The OAuth Actor Profile for Delegation [I-D.mcguinness-oauth-actor-profile] makes actor identity visible in delegated tokens through a common act claim. A recipient can read that chain but cannot, on the basis of the outer token alone, verify prior hops independently of the current token issuer. The core profile treats inner actors as context whose authenticity rests on the outer token issuer, and leaves per-hop provenance to companion profiles that add top-level claims. This document defines OAuth Actor Receipts, an optional companion profile that adds independently signed per-hop provenance. Each issuer adding a covered actor hop signs a receipt; receipts travel with the token in actor_receipts, linked by hashes and verifiable against the individual issuers' keys. The design center is: * keep the visible actor chain in act; * keep active presenter binding in the token's top-level cnf; * carry prior-hop provenance, including historical cnf values when disclosed, in separately signed receipts. Deployments can enable receipts per resource or trust domain without changing client request flows, and resource servers that do not consume receipts need no change. A token that carries receipts follows the core actor profile's rules for companion profiles: its top-level cnf identifies only the current token presenter, and its nested act objects carry no independently trusted prior-hop key history. Receipts do not: * replace the outer token's signature or issuer trust model; * change the request semantics of [RFC8693] or of Transaction Tokens, audience and scope evaluation, AS-to-RS trust establishment, or sender-constrained token validation for the current presenter, which follow OAuth [RFC6749] and the core actor profile; McGuinness Expires 12 April 2027 [Page 4] Internet-Draft OAuth Actor Receipts October 2026 * prove which scope, audience, or token lifetime was in force when a receipt was created; * reconcile subject identifiers that differ across receipts (Section 7.2); or * define a cross-token correlation identifier, transparency logs, or non-repudiation. Receipts are most useful when several issuers contribute hops: recipients can verify each attestation independently of the current outer token issuer. In a single-issuer deployment, the outer token's signature already supplies that issuer's attestation, so deployments SHOULD weigh receipt overhead against that limited benefit. Recipients must configure trust for every receipt issuer (Section 11.3), so large deployments need a trust-distribution mechanism, such as federation, which this document does not define. Unlike token introspection [RFC7662], which returns the AS's current view of token status and claims, receipts preserve signed hop history that can be verified without an introspection endpoint, including after intermediate systems become unavailable. A deployment can use either mechanism, both (Section 7.5), or neither. Related drafts differ chiefly in where delegation evidence resides and who can verify it. [I-D.mw-oauth-actor-chain] carries an issuer- signed cumulative commitment in the token while the per-hop evidence stays at the authorization server, so recipients depend on issuer retention and out-of-band access; receipts are themselves the evidence, carried with the token at the cost of per-hop token growth. [I-D.liu-oauth-authorization-evidence] and [I-D.liu-oauth-chain-delegation] carry authorization-server-signed consent and per-hop delegation records that are not chained to one another and are re-signed at trust-domain boundaries; receipts are byte-preserved and linked by prh, so recipients verify each hop against the issuer that created it. This informative comparison does not preempt working group discussion of convergence. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. McGuinness Expires 12 April 2027 [Page 5] Internet-Draft OAuth Actor Receipts October 2026 This document uses OAuth terminology from [RFC6749] and [RFC8693], and Transaction Token terminology from [I-D.ietf-oauth-transaction-tokens]. AS, RS, and TTS denote authorization server, resource server, and Transaction Token Service, respectively. This document uses the following terms: Actor Receipt: A signed JWT that attests one visible actor hop in a delegated token chain. Outer Token: The access token (JWT-formatted or opaque), JWT assertion grant, or Transaction Token with which a receipt chain is associated. A JWT-formatted outer token carries the actor_receipts claim inline; for an opaque token, the receipts are returned via introspection (see Section 7.5). Receipt Chain: The ordered actor_receipts array carried in a token or introspection response. Historical Presenter Binding: The presenter-binding state of a hop at the time the hop was created. When recorded, it appears as the receipt's cnf claim, equal to the top-level cnf value of the token issued at that hop. Historical presenter binding is informational provenance; it does not create an active proof-of-possession obligation for the current request. Complete Receipt Coverage: A condition in which the number of receipts in actor_receipts equals the number of visible actor hops in the token's act chain, and every receipt aligns with the corresponding visible hop. Examples in this document are illustrative and omit unrelated claims, signatures, and validation steps that a complete deployment would need. 3. Actor Receipts Overview The actor_receipts array is ordered newest first and preserves older entries unchanged. Index 0 corresponds to the outermost act object, index 1 to act.act, and so on. A valid receipt chain records issuer attestations of past delegation. It conveys no authority and does not establish that delegation remains active. Current authorization decisions MUST evaluate the current outer token, current policy, and current state, not the receipt chain alone. McGuinness Expires 12 April 2027 [Page 6] Internet-Draft OAuth Actor Receipts October 2026 4. The actor_receipts Claim This document defines actor_receipts as a top-level JWT claim for tokens that conform to both the core actor profile and this companion provenance profile. actor_receipts: OPTIONAL. An array of strings. Each string MUST be the compact serialization of a signed JWT receipt as defined in Section 5. When present, the array: * MUST NOT be empty; issuers MUST omit the claim rather than including an empty array; * MUST be ordered from newest covered hop to oldest covered hop; * MUST NOT contain more entries than the visible actor-chain depth of the token's act claim; * MUST represent a contiguous outermost prefix of the visible act chain. If a token carries the actor_receipts claim, it MUST also carry an act claim conforming to the core actor profile. actor_receipts_complete: OPTIONAL. A boolean JWT claim in the outer token. When true, the issuer attests that actor_receipts covers every visible hop in the token's act chain. The attestation is relative to the visible chain at issuance time; it does not attest that the visible chain is itself unfiltered (see the chain_complete introspection member in the core actor profile [I-D.mcguinness-oauth-actor-profile]). Step 4 of Section 7 defines consumer enforcement, including the count- equality check. Issuers SHOULD set actor_receipts_complete to true for complete coverage and false for partial coverage; an issuer extending a chain sets true only as step 8 of Section 6.2 allows. An absent claim provides no completeness attestation; consumers that require the literal value true treat absence as false. 5. Actor Receipt JWT Format Each element of the actor_receipts array is a signed JWT represented using JWS compact serialization [RFC7515]. McGuinness Expires 12 April 2027 [Page 7] Internet-Draft OAuth Actor Receipts October 2026 5.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 the typ header parameter with the value actor- receipt+jwt; * SHOULD include the kid header parameter when the issuer publishes multiple verification keys; * MAY include the crit header parameter per Section 4.1.11 of [RFC7515]; step 5 of Section 7 rejects a receipt whose crit header parameter lists an extension header parameter the consumer does not understand. Receipt issuers and consumers MUST apply the JWT best practices in [RFC8725] when creating and validating receipts, except for the audience requirements of Section 3.9 of [RFC8725], from which this profile departs by prohibiting the aud claim as described in Section 5.2. 5.2. Receipt Claims The JWT payload of an actor receipt uses the claims defined below, grouped by purpose. 5.2.1. Identity 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, with the meaning defined by the core actor profile. These two values MAY identify the same entity or different entities. When they differ, consumers MUST evaluate two distinct trust questions: * trust in iss as a receipt signer: whether this issuer's signature attests receipts under local policy; * trust in act.iss as the namespace authority for act.sub: whether this issuer's namespace produces actor identifiers the recipient accepts. McGuinness Expires 12 April 2027 [Page 8] Internet-Draft OAuth Actor Receipts October 2026 These evaluations are independent even when the same entity holds both roles. A difference between iss and act.iss 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. The receipt iss claim identifies the signer, not the subject namespace. Recipients interpret sub in the namespace of the represented hop, which MAY differ across receipts. Reconciliation relies on trusted local mappings; see Section 7.2. sub_iss: OPTIONAL. The namespace authority under which the receipt sub value is interpreted. The (sub_iss, sub) pair identifies the subject just as (act.iss, act.sub) identifies the actor. If sub_iss is absent, recipients MUST determine the namespace, when needed, from trusted local context for the represented hop. This flat pair records the token's issued claims; it does not use the structured Subject Identifier formats in [RFC9493]. 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 NOT contain cnf; * MUST NOT contain a nested act. Historical presenter binding belongs in the receipt-level cnf claim. Other core-profile actor extensions MAY appear unless prohibited here; a receipt containing act.cnf is invalid. These restrictions apply to the receipt's actor object. The issuer constructs that object for visible-hop alignment (step 7 of Section 7), separately from the token's act chain. A confirmation member in the token's actor object remains subject to the core profile's extension and preservation rules; creating a receipt does not remove it from the token. 5.2.2. Historical Presenter Binding cnf: OPTIONAL. A confirmation claim as defined in [RFC7800]. When McGuinness Expires 12 April 2027 [Page 9] Internet-Draft OAuth Actor Receipts October 2026 present, it MUST equal the top-level cnf claim of the token issued at this hop. Its source is the top-level cnf claim of the token issued at that hop, not a confirmation member in the token's act chain. Whether an issuer includes cnf is governed by Section 11.10; omitting cnf does not invalidate the receipt. 5.2.3. Chain Linkage prh: OPTIONAL. Previous receipt hash. When present, prh MUST be the base64url encoding without padding ([RFC7515]) of the hash of the ASCII octets of the complete compact serialization of the next older receipt in the chain, computed using the algorithm identified by prh_alg (defaulting to SHA-256 when prh_alg is absent). The oldest receipt in the chain, including a single- element chain in which the sole receipt is both newest and oldest, MUST omit prh. prh_alg: OPTIONAL. An identifier of the hash algorithm used to compute prh. * Values MUST be drawn from the IANA "Named Information Hash Algorithm Registry" [RFC6920], which uses lowercase forms such as sha-256, sha-384, and sha-512. * When absent, the default is sha-256. * When present, the value MUST identify a hash algorithm whose collision and preimage resistance is at least equivalent to sha-256. * All receipts in an array MUST carry the same prh_alg value or all omit it. Mixing omission with explicit sha-256 is invalid even though both select SHA-256. A single-element chain MAY carry prh_alg, but the value has no effect unless a later receipt links to it. * An issuer extending an inbound chain preserves the inbound prh_alg or rejects the chain (step 7 of Section 6.2). 5.2.4. Time and Uniqueness iat: REQUIRED. The time at which the receipt was created, as defined in [RFC7519]. exp: REQUIRED. The expiration time of the receipt, as defined in [RFC7519]. McGuinness Expires 12 April 2027 [Page 10] Internet-Draft OAuth Actor Receipts October 2026 The exp of a newly created receipt MUST NOT be earlier than the exp of the outer token issued with it, and SHOULD cover the expected maximum token lifetime of any token that will carry or inherit this receipt. An exp value set too early causes propagation failure: issuers that later retain the receipt apply the following receipt lifetime rule. When an issuer retains receipts in a token it issues (extending the chain under Section 6.2, or reissuing or refreshing under Section 6.3) and a retained receipt's exp is earlier than the exp the issuer would set, the issuer: 1. MAY lower the issued token's exp to the earliest retained receipt exp; 2. otherwise, where local policy permits the issued token to lack the retained receipts, MUST drop the array; 3. otherwise MUST fail the request, with the invalid_grant error code on a refresh or JWT bearer grant request (Section 5.2 of [RFC6749]) or the invalid_request error code on a Token Exchange request (Section 2.2.2 of [RFC8693]). Because the originating issuer cannot enumerate every downstream issuer that might inherit a receipt, deployments typically coordinate a bounded delegated-session lifetime to avoid propagation failure while limiting signing-key exposure; see Section 6.3. jti: REQUIRED. A unique identifier for the receipt, as defined in [RFC7519]. 5.2.5. Outer-Token Binding origin_jti: RECOMMENDED. The jti of the outer token at the time this receipt was created (the receipt's origin outer token). This value is fixed at receipt creation; after reissuance, the current outer token's jti can differ. It binds the chain to the current token only when both receipt[0].iss and receipt[0].origin_jti match that token's iss and jti, respectively. Issuers SHOULD include origin_jti when the issued token has a jti claim. See Section 7.1 and Section 11.4.1 for validation and reissuance handling. McGuinness Expires 12 April 2027 [Page 11] Internet-Draft OAuth Actor Receipts October 2026 5.2.6. Excluded Standard Claims aud: Prohibited. Issuers MUST NOT include aud in a receipt, and consumers MUST reject a receipt that carries it (step 5 of Section 7). Receipts are validated as part of outer-token processing, not as independent JWTs against an audience; the outer token carries the audience scoping for the request. A present aud would suggest an independent audience constraint, which receipts do not assert; rejecting it gives the result that Section 4.1.3 of [RFC7519] requires when the processing principal does not identify itself with the aud value. 5.2.7. Extension Claims A receipt MAY contain additional claims defined by another specification or by deployment policy. Consumers ignore unrecognized claims unless another specification or local agreement defines their meaning, per Section 4 of [RFC7519]. 5.3. Receipt-Chain Linkage A new receipt prepended to an inherited chain includes a prh claim computed over the older receipt that follows it; a receipt that is the only one in the array omits prh (Section 5.2; step 6 of Section 6.2). The hash input is the exact compact JWS string, without JSON [RFC8259] canonicalization. Systems that carry, store, or forward actor_receipts arrays MUST preserve each receipt byte-for-byte. Re- encoding changes the hash even when the claims remain equivalent. 6. Issuer Processing When an issuer adds a new outermost actor hop and creates the corresponding receipt, that issuer also signs the outer token. Consequently, receipt[0].iss equals the outer token's iss for tokens issued under Section 6.1 or Section 6.2. When the issuer includes origin_jti, receipt[0].origin_jti equals the outer token's jti in those originating-issuance cases. Reissuance without a new actor hop (Section 6.3) is the only case in which receipt[0] can legitimately diverge from the current outer- token instance; the consumer rules in Section 7 rely on this property to scope the bind-to-current checks for receipt[0]. McGuinness Expires 12 April 2027 [Page 12] Internet-Draft OAuth Actor Receipts October 2026 6.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 the issuer does so, the new receipt: * MUST describe the new outermost actor hop; * MUST set iss to the issued token's iss; * MUST set sub to the issued token's top-level sub; * MUST set act.sub and act.iss to identify the new outermost actor; * MAY copy the issued token's top-level cnf, if any, into the receipt cnf, subject to the disclosure considerations in Section 11.10; * includes origin_jti as recommended in Section 5.2; * omits prh (Section 5.2). A one-element array is complete coverage only when the visible act chain has depth 1; the actor_receipts_complete value follows the rules in Section 4. 6.2. Extending an Existing Receipt Chain When an issuer adds a new outermost actor hop and also preserves the actor_receipts array of the token carrying the inbound delegation chain ([I-D.mcguinness-oauth-actor-profile]), such as the token in the subject_token parameter of a Token Exchange request, the issuer: 1. MUST validate the inbound receipt chain by applying the consumer processing rules in Section 7 before relying on it or carrying it forward. 2. MUST apply the receipt lifetime rule in Section 5.2 when an inbound receipt's exp is earlier than the issued outer token's exp. Issuers MAY allow a small, deployment-defined clock-skew margin consistent with consumer validation, but MUST NOT accept a larger expiry gap. 3. MUST preserve each inbound receipt byte-for-byte unchanged. McGuinness Expires 12 April 2027 [Page 13] Internet-Draft OAuth Actor Receipts October 2026 4. MUST create exactly one new receipt for the new outermost actor hop, with claims set as in Section 6.1 except prh and prh_alg, which steps 6 and 7 govern. 5. MUST prepend that new receipt to the inherited array. 6. When the inherited array is non-empty, MUST set the new receipt's prh to the hash of the exact compact serialization of the receipt now at the next array index, computed using the algorithm named by prh_alg (defaulting to SHA-256 when prh_alg is absent). 7. MUST set the new receipt's prh_alg to the inherited value, or omit prh_alg if the inherited chain omits it (preserving the SHA-256 default for the chain). An issuer that does not support the inbound prh_alg value MUST reject the chain rather than rehash; rehashing would invalidate prior issuers' signatures. 8. MUST NOT set actor_receipts_complete to true unless every inbound receipt validated and the issued token's receipt count equals its visible actor-chain depth, and SHOULD set it to false otherwise. Byte-for-byte preservation (Section 5.3) precludes reserializing, re- signing, normalizing, trimming, or otherwise altering a prior receipt. If inbound receipts fail validation, the issuer MUST NOT propagate them. It MAY continue without them only when local policy permits the issued token to lack them, and it MAY then begin a new chain at its own hop under Section 6.1; the result is partial coverage and MUST NOT carry actor_receipts_complete: true. Otherwise, it MUST fail the request under the error model of the underlying protocol. 6.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 forward, unchanged, an actor_receipts array received in an inbound token or its introspection response, and MUST first validate it against that token under Section 7, as step 1 of Section 6.2 requires for extension; an array the issuer retained across refresh follows the refresh rules below instead. If the array fails validation, the issuer MUST NOT carry it forward, and MUST fail the request under the error model of the underlying protocol unless local policy permits the issued token to lack it; * MUST NOT create a new receipt; McGuinness Expires 12 April 2027 [Page 14] Internet-Draft OAuth Actor Receipts October 2026 * MUST preserve actor_receipts_complete when carrying the array unchanged. An issuer that would change that value MUST drop the array entirely instead; disclosure is all-or-nothing (Section 7.5); * MUST NOT continue to carry an inherited actor_receipts array if it cannot preserve the visible hop alignment required by Section 7; * MUST NOT change the top-level sub claim while retaining receipts. Subject re-expression breaks alignment with receipt[0].sub and requires dropping the array; * MUST NOT set the outer token's exp later than the earliest exp among the retained receipts; an issuer that would set a later exp applies the receipt lifetime rule in Section 5.2. If such an issuer changes the visible outermost actor, it has added a new hop and MUST follow Section 6.2. Reissuance MAY change aud, scope, cnf, and other current-request claims without changing receipts, and MAY change exp within the limit above. The receipt cnf claim remains historical, so key rotation alone does not invalidate the chain. Reissuance can make receipt[0] diverge from the current outer-token instance in two ways: * *Different-issuer reissuance*: receipt[0].iss differs from the outer token's iss, for example when an introspection endpoint operated as a separate trust principal re-emits the token, a token translator at a domain boundary reissues it, or a TTS issues a Transaction Token by presenter continuation from a token whose newest receipt another issuer created. A common case is a Resource Authorization Server that redeems an Identity Assertion JWT Authorization Grant (ID-JAG) or other JWT assertion grant ([I-D.mcguinness-oauth-actor-profile]) without adding a hop; the actor alignment and subject alignment of steps 7 and 8 of Section 7 still apply. * *Same-issuer reissuance*: receipt[0].iss matches the outer token's iss, but a present receipt[0].origin_jti differs from the outer token's jti, for example when an AS refreshes its own access token. McGuinness Expires 12 April 2027 [Page 15] Internet-Draft OAuth Actor Receipts October 2026 In either case, origin_jti remains historical and no longer binds the chain to the current instance. Recipients accept different-issuer reissuance only under the reissuing-issuer policy in Section 11.4 (case 4 of Section 7.1), and same-issuer reissuance only as provenance without instance binding (case 3 of Section 7.1). Refresh-token reissuance is a special case of reissuance under this section. An AS that supports refresh tokens for delegated access tokens: * needs to retain the actor_receipts array associated with the original access token in issuer-controlled state across refresh, either in durable storage (for example, a token-state database or refresh-token state) or embedded in a self-contained refresh token, so that each refreshed access token can carry the receipts forward unchanged. * needs receipt exp values (Section 5.2) that accommodate a bounded maximum delegated-session lifetime that local policy defines; otherwise refresh and downstream extension shorten tokens or lose receipt-based provenance. * takes the array from that retained state rather than from the previous access token: it validates the refresh request per Section 6 of [RFC6749], checks the retained receipts against its issuance state, and does not require the previous access token to remain unexpired or re-run Section 7 against it. * applies the receipt lifetime rule in Section 5.2 when a retained receipt's exp is earlier than the exp it would set for the refreshed token. Refresh adds no actor hop, so receipt provenance resumes only through a new delegated issuance that adds a hop and begins a chain under Section 6.1. 6.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 still covers a contiguous outermost prefix of the visible actor chain (Section 4), so an issuer cannot skip an outer visible hop and issue a receipt only for an inner visible hop; McGuinness Expires 12 April 2027 [Page 16] Internet-Draft OAuth Actor Receipts October 2026 * 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. Partial coverage leaves the oldest hops uncovered, including the original subject-to-actor delegation. Deployments needing evidence for that hop should enable receipt support at the origin issuer first. When an introspection server filters the visible act chain (see the chain_complete introspection member defined in the core actor profile [I-D.mcguinness-oauth-actor-profile]), actor_receipts covers only the visible filtered chain. In that case, actor_receipts_complete describes coverage relative to the visible filtered chain, not the unfiltered delegation chain; recipients that need true-chain completeness evaluate chain_complete separately. Filtering only inner actors that no receipt covers preserves the full array and its alignment; filtering a covered actor breaks hop alignment (step 7 of Section 7), so the array cannot be kept (Section 7.5). For JWT-formatted outer tokens, this document defines no chain_complete JWT claim. A recipient that needs true-chain completeness for such tokens obtains that signal from trusted deployment context, introspection, or another profile; actor_receipts_complete: true alone attests only to complete receipt coverage of the visible act chain. 6.5. Transaction Token Service Rebinding A TTS that adds a presenter as the new outermost actor follows Section 6.2, or Section 6.1 if no receipts exist. The new receipt can record the presenter's cnf value under Section 5.2; inherited receipts retain their historical bindings. [I-D.ietf-oauth-transaction-tokens] defines no jti claim but permits additional claims (Section 9.2 of [I-D.ietf-oauth-transaction-tokens]), so a TTS MAY include a jti claim in a Transaction Token. Without a jti claim, a Transaction Token's receipt chain is never instance-bound, because case 1 of Section 7.1 requires the outer token's jti; recipients that require instance binding need a TTS that includes jti. 7. Consumer Processing An issuer, resource server, or other recipient that relies on actor_receipts MUST perform the following steps. McGuinness Expires 12 April 2027 [Page 17] Internet-Draft OAuth Actor Receipts October 2026 1. Validate the outer token according to its token type and the core actor profile, including any presenter proof the core actor profile requires of the recipient. At a resource server, actor authorization under the core actor profile follows this processing, so it can use validated receipts (Section 7.4). 2. If actor_receipts is absent, treat the token as lacking receipt- based provenance. Local policy or Protected Resource Metadata parameters (such as actor_receipts_required and actor_receipts_complete_required, defined in Section 8) determine whether that is acceptable. If actor_receipts_complete is present with the value true while actor_receipts is absent, the combination is malformed; the recipient MUST treat this as a failed required check and apply the rejection rule following step 11. 3. Verify that actor_receipts, if present, is a non-empty JSON array of strings. Verify that actor_receipts_complete, if present, is a JSON boolean. 4. Verify that the number of receipts does not exceed the visible actor-chain depth of the outer token. If the outer token carries actor_receipts_complete: true, verify that the receipt count exactly equals the visible actor-chain depth; if it does not, the check fails. 5. For each receipt, in array order: * parse the string as a compact JWT; * verify that typ equals actor-receipt+jwt; * verify that the receipt issuer is within the recipient's pre- configured trusted-issuer set before performing any network retrieval for that issuer's metadata or keys; * verify that the JOSE header uses an asymmetric digital- signature alg value accepted for that receipt issuer, and reject receipts that use alg: none or a MAC-based symmetric algorithm; * resolve the signing key from the receipt issuer's authorization server metadata jwks_uri [RFC8414] (where the receipt's iss claim identifies the receipt issuer, which can differ from the outer token's issuer) or from local configuration; * validate the JWT signature; McGuinness Expires 12 April 2027 [Page 18] Internet-Draft OAuth Actor Receipts October 2026 * reject a receipt whose crit header parameter lists an extension header parameter the consumer does not understand; * verify that all REQUIRED receipt claims are present and have the expected JSON types, including iss, sub, act, iat, exp, and jti; * verify that OPTIONAL claims used by this profile have the expected JSON types when present, including sub_iss, sub_profile, cnf, prh, prh_alg, and origin_jti; * verify that the receipt act object is single-hop, contains no nested act, and contains no cnf; * reject a receipt that contains aud (Section 5.2); * enforce exp, iat, and other JWT validity rules. An expired receipt is invalid even for an older hop; only the small clock-skew leeway of Section 4.1.4 of [RFC7519] applies; * for receipt[0], apply Section 7.1. For older receipts, origin_jti is historical information only. 6. Verify receipt-chain linkage: * each receipt other than the oldest MUST include prh; * each non-oldest receipt's prh MUST hash the next older receipt using the algorithm named by prh_alg, defaulting to sha-256 when prh_alg is absent; * all receipts in the chain MUST carry the same prh_alg value (or all omit it); a mixed-algorithm chain MUST be rejected; * the named algorithm MUST be one the recipient supports; a chain naming an unsupported algorithm MUST be rejected; * the oldest receipt MUST omit prh. 7. Verify visible-hop alignment: * receipt[0].act.sub MUST equal the outer token's act.sub, and receipt[0].act.iss MUST equal the outer token's act.iss; * receipt[1].act.sub MUST equal the outer token's act.act.sub, and receipt[1].act.iss MUST equal the outer token's act.act.iss; McGuinness Expires 12 April 2027 [Page 19] Internet-Draft OAuth Actor Receipts October 2026 * and so on for the number of receipts present; * when act.sub_profile is present in the receipt act object, the corresponding visible act object MUST contain act.sub_profile with the same value; * sub_profile values are compared as sets: the space-delimited values are compared case-insensitively, their order is insignificant, and duplicate values are ignored (Section 3.3 of [I-D.mora-oauth-entity-profiles]); comparison never rewrites a signed receipt; * when act.sub_profile is present only in the visible act object, the receipt remains aligned for this profile. The visible value is not independently attested by that receipt, and recipients that require receipt coverage for actor classification MUST reject the receipt chain or apply explicit local mapping rules. 8. Verify subject alignment: * receipt[0].sub MUST equal the outer token's top-level sub; * when receipt[0].sub_iss is present and the recipient has a top-level subject namespace authority for the outer token's sub from local configuration, an inbound subject token's claims, or another deployment-defined source, the two MUST identify the same namespace authority, evaluated by case- sensitive string comparison; treating lexically distinct identifiers as the same authority requires explicit trusted local mapping rules; * when receipt[0].sub_profile is present and the outer token contains top-level sub_profile, the values MUST match under the set comparison of step 7; * when receipt[0].sub_profile is present but the outer token does not contain top-level sub_profile, recipients that require receipt coverage for subject classification MUST reject the receipt chain or apply explicit local mapping rules; * when receipt[0].sub_profile is absent but the outer token contains top-level sub_profile, the receipt remains aligned for this profile. The visible value is not independently attested by that receipt, and recipients that require receipt coverage for subject classification MUST reject the receipt chain or apply explicit local mapping rules; McGuinness Expires 12 April 2027 [Page 20] Internet-Draft OAuth Actor Receipts October 2026 * older receipts MAY carry differing sub, sub_iss, or sub_profile values; see Section 7.2. 9. Treat each receipt cnf value, if present, only as historical provenance for that hop. A mismatch between the current outer token's top-level cnf and the outermost receipt cnf MUST NOT by itself invalidate the receipt chain under this profile. 10. Receipt cnf values MUST NOT replace validation of the current request against the outer token's top-level cnf. 11. Apply any additional consumer-processing rules defined by companion profiles whose claims appear in the receipt or outer token (see Section 10). Companion-profile rules can add rejection conditions but cannot relax any requirement needed for conformance to this profile. Unless a companion profile states otherwise, a failure under its rules rejects only that companion's evidence and is not a failed required check of this profile. Step 1 is a prerequisite: an outer token that fails its own validation is rejected under the rules for its token type, not treated as lacking receipts. If any later required check fails, the recipient MUST reject the receipt chain and treat the token as lacking receipt-based provenance (step 2). The recipient rejects the token only when local policy or Protected Resource Metadata requires that evidence, using the underlying protocol's error handling for the stage at which the failure occurred. A recipient that has rejected a receipt chain under this profile MAY, under explicit local policy, extract structural information from the chain for use by companion profiles (for example, applying a companion's verification rules to the trusted prefix of an otherwise- invalid chain). The recipient MUST NOT treat such partial validation as conformance with this profile; the rejection requirements defined above still apply. Companion profiles defining partial-validation modes MUST do so under their own normative scope. 7.1. Receipt Instance Binding Consumer step 5 applies the following cases, in order, to receipt[0]: 1. If its iss matches the outer issuer and its origin_jti is present and matches the outer token's jti, the chain is bound to that token instance. McGuinness Expires 12 April 2027 [Page 21] Internet-Draft OAuth Actor Receipts October 2026 2. If the issuers match but the outer token has no jti, the chain supplies provenance without instance binding. Any origin_jti is informational. 3. If the issuers match and the outer token has jti, but origin_jti is absent or differs from that jti, the recipient MAY accept provenance under local policy. It MUST NOT treat the chain as instance-bound. 4. Otherwise (the issuers differ), the recipient MUST reject the chain unless local policy trusts the outer issuer to reissue chains led by this receipt issuer (Section 11.4.1). A recipient that requires instance binding MUST reject the chain unless case 1 applies. 7.2. Subject Re-Expression Across Hops Only receipt[0].sub is matched against the outer token's top-level sub; older receipts can carry different subject identifiers (step 8 of Section 7). Matching actor identities alone do not establish subject continuity. A receipt from an unrelated subject chain that shares the same actor identity can satisfy the hop-alignment check, whether by accident or because a compromised upstream issuer minted it for insertion. Deployments requiring subject continuity SHOULD establish it either by exact, namespace-aware matching of subject identifiers throughout (the same sub under the same namespace authority; see sub_iss in Section 5.2) or by positive reconciliation through trusted mappings. When neither applies, recipients MUST treat continuity as unverified and MUST NOT use the differing older receipts to support authorization that requires subject continuity (for example, a decision that treats every covered hop as having acted for the current token's subject). 7.3. Complete Receipt Coverage Coverage is structurally complete when all validation succeeds and the receipt count equals the visible actor-chain depth. This suffices when local policy requires only structural completeness. With actor_receipts_complete_required: true, the token or introspection response MUST also carry actor_receipts_complete: true. Recipients MUST reject tokens that fail the applicable completeness requirement. McGuinness Expires 12 April 2027 [Page 22] Internet-Draft OAuth Actor Receipts October 2026 7.4. Use by Resource Servers Resource servers can use validated receipts as provenance input for authorization, diagnostics, and audit, subject to the limits in Section 11.1. Such use rests on the validated top-level actor_receipts claim: nested act objects remain informational for access control (Section 4.1 of [RFC8693]), and, under this profile, a prior actor is an authorization input only as a hop covered by a receipt validated under Section 7. A valid receipt chain proves only that trusted issuers attested specific visible actor hops. It conveys no authority, does not replace authorization of the current token, does not imply that the represented delegation remains active, and does not prove that the current token's audience, scope, or expiration were in force when older receipts were created. 7.5. 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 4; * MAY return actor_receipts_complete to indicate whether the returned array provides complete coverage for the visible chain as known to the introspection server. For opaque tokens, the issuer stores receipts and returns them to authorized resource servers through introspection. The same format and consumer rules apply, with the introspection response treated as the outer token's claim set. An introspection response carrying receipts MUST include the members needed for Section 7: the token's top-level sub, the visible act chain, and the token's iss. It SHOULD include the token's jti when maintained by the server; when the response omits jti, recipients apply the no-jti case in Section 7.1. If present, actor_receipts_complete MUST be a boolean. An RS receiving both inline and introspected receipts MUST select an authoritative source under local policy. If it consumes both, differing arrays or completeness values MUST cause rejection of receipt-based provenance. McGuinness Expires 12 April 2027 [Page 23] Internet-Draft OAuth Actor Receipts October 2026 An introspection server MUST return the full stored array or omit actor_receipts. Removing an older entry breaks prh linkage; removing the newest entry breaks hop alignment. A server that filters the visible act chain can still return the full array when it filters only inner actors that no receipt covers; if it filters a covered actor, it MUST omit both actor_receipts and actor_receipts_complete. When the returned array does not cover every hop of the returned act chain, the introspection server MUST include actor_receipts_complete: false. For an inactive token, the introspection server MUST NOT return actor_receipts or actor_receipts_complete. Consumers that rely on both signals evaluate chain_complete and actor_receipts_complete independently (Section 6.4); complete receipt coverage does not prove that no actors were filtered. 8. Discovery and Capability Signaling 8.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, the AS makes no claim of such support. This parameter applies equally to an authorization server that issues delegated JWT outputs and to a Transaction Token Service that publishes metadata through the same framework. 8.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. McGuinness Expires 12 April 2027 [Page 24] Internet-Draft OAuth Actor Receipts October 2026 This parameter is a policy declaration for deployment coordination, not a request-time protocol signal: this document defines no parameter by which a client requests receipt issuance, so a deployment satisfies the declaration by configuring receipt issuance at the authorization servers that serve the resource. Clients MAY use it, together with actor_receipts_supported, to select an authorization server that can issue receipt-bearing tokens. actor_receipts_complete_required: OPTIONAL. A boolean. When true, the resource server indicates that it requires complete receipt coverage: the receipt count equals the visible actor-chain depth and actor_receipts_complete is 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. No metadata parameter indicates that a resource server requires receipts to carry cnf. Because issuers omit receipt cnf by default (Section 11.10), resource servers that need historical sender- constraint provenance coordinate that requirement with issuers through deployment policy. 8.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 actor_receipts JWT claim. actor_receipts_complete: OPTIONAL. A boolean. When true, the introspection response indicates that the returned actor_receipts array covers every visible hop in the token chain as known to the introspection server. When false, the response makes no attestation of complete coverage. Consumer use of these members is described in Section 7.5; introspection-server failure handling is addressed in Section 9.3. McGuinness Expires 12 April 2027 [Page 25] Internet-Draft OAuth Actor Receipts October 2026 8.4. Claim-Pair Convention for Sibling Profiles Companion profiles that define their own per-hop signed artifact arrays SHOULD use the same naming convention, SHOULD advertise support in AS metadata [RFC8414], and SHOULD advertise requirements in Protected Resource Metadata [RFC9728]: +============================+==========================+ | Purpose | Name | +============================+==========================+ | Artifact array | | +----------------------------+--------------------------+ | Coverage attestation | _complete | +----------------------------+--------------------------+ | AS support | _supported | +----------------------------+--------------------------+ | Resource requirement | _required | +----------------------------+--------------------------+ | Complete-coverage | _complete_required | | requirement, if applicable | | +----------------------------+--------------------------+ Table 1 Companion profiles add per-hop signal in two distinct patterns, and SHOULD pick the one that matches their signer: * *Parallel artifact arrays*: a companion outer-token claim parallel to actor_receipts, following the plus _complete convention above. Each entry is a separately signed JWT. This pattern is appropriate when the artifact needs its own signer trust independent of the receipt issuer (for example, actor-signed proofs whose threat model differs from AS-signed receipts, or recipient-signed acknowledgments). * *Per-receipt extension claims*: a claim added to each receipt JWT and verified as part of the receipt's signature. This pattern is appropriate when the receipt issuer already attests the assertion (for example, per-hop authority bounds, delegation-flow correlation, or lifecycle-state snapshots). Recognition of such claims follows the unrecognized-claims rule in Section 5.2, and cross-receipt verification follows Section 10. The two patterns serve different threat models and have different completeness semantics: parallel-array companions inherit the claim- pair coverage mechanism defined here; per-receipt-claim companions define their own completeness rules over the set of receipts that carry the claim. McGuinness Expires 12 April 2027 [Page 26] Internet-Draft OAuth Actor Receipts October 2026 9. Error Handling Receipt validation failures use the underlying protocol's error mechanism for the stage at which validation occurs. This document defines no new OAuth error codes. 9.1. Authorization Server and Transaction Token Service Errors When an authorization server or Transaction Token Service rejects a request because inbound actor_receipts cannot be validated under Section 6.2 or Section 6.3 (signature failure, expired receipt, unsupported prh_alg, broken prh chain, hop or subject misalignment, or untrusted receipt issuer), it returns an error response per Section 5.2 of [RFC6749]: the invalid_request error code for a Token Exchange request, as Section 2.2.2 of [RFC8693] requires, or the invalid_grant error code for a JWT bearer grant request (Section 3.1 of [RFC7523]) or a refresh request. An absent receipt array that local policy requires, whether missing from the inbound token or from retained refresh state, is an input-validation failure: the invalid_request error code for a Token Exchange request, or the invalid_grant error code for a JWT bearer grant or refresh request. When the failure reflects an actor-authorization decision rather than a structural validation failure, the issuer uses the actor_unauthorized error code, as the core actor profile [I-D.mcguinness-oauth-actor-profile] requires. 9.2. Resource Server Errors When a resource server rejects a request because actor_receipts validation fails under Section 7, it SHOULD return the invalid_token error code (Section 3.1 of [RFC6750]) in a challenge that uses the authentication scheme the core actor profile's resource server processing selects, such as DPoP for a DPoP-bound token. For a Transaction Token, the recipient instead rejects the request through the deployment's Transaction Token handling, because [I-D.ietf-oauth-transaction-tokens] defines no error response. When the failure is specifically that required receipts are absent or coverage is incomplete (per actor_receipts_required or actor_receipts_complete_required), the resource server SHOULD include an error_description value identifying a receipt-coverage failure so that clients and operators can distinguish it from generic token- validation failures. McGuinness Expires 12 April 2027 [Page 27] Internet-Draft OAuth Actor Receipts October 2026 9.3. Introspection Server Behavior When an introspection server cannot return receipts that the requesting resource server requires, it returns the introspection response per [RFC7662], not an OAuth error, with actor_receipts absent or with a partial array and actor_receipts_complete: false; the resource server then applies its local policy to decide whether to accept the token. 10. Extensibility Companion profiles that build on the OAuth Actor Profile for Delegation [I-D.mcguinness-oauth-actor-profile] can extend this profile through five surfaces: * *New claims inside a receipt JWT* for additional per-hop attributes (for example, historical scope or additional binding data). Consumers ignore unrecognized claims (Section 5.2), so additive claims do not break the validation rules of this document. * *New top-level claims on the outer token, parallel to actor_receipts*, for per-hop artifacts that need their own signature semantics, following the claim-pair convention in Section 8. * *New JOSE typ values* for receipt-shaped artifacts that are not AS-signed receipts conforming to this document. The typ value actor-receipt+jwt defined here is reserved for receipts conforming to this document and MUST NOT be used by other artifacts. * *New outer-token binding claims*, analogous to origin_jti, that record an outer-token field other than jti (for example, a workflow correlation identifier). Such claims are independently verifiable as current-token bindings only on the same terms as origin_jti; see Section 11.4. * *Events not tied to a new visible actor hop*, such as re- authorization without a hop change, lifecycle-state changes, receiver acknowledgments, or sender-constraint rotation. Companion profiles SHOULD use a separate JWT type and a parallel outer-token array. They SHOULD anchor each event to a receipt jti or a defined flow identifier, such as Transaction Token txn [I-D.ietf-oauth-transaction-tokens]. Event chaining with prh / prh_alg and the completeness convention are optional. Companion profiles MUST NOT add event entries to actor_receipts, which is reserved for the AS-signed hop receipts defined by this document. McGuinness Expires 12 April 2027 [Page 28] Internet-Draft OAuth Actor Receipts October 2026 Companion profile authoring rules: * Companion profiles MAY extend consumer processing under Section 7 by adding rejection conditions; they MUST NOT relax any requirement needed for conformance to this profile. * Companion-profile claims and discovery metadata MUST be registered with IANA in the registries used by this document. * Companion profiles MAY reuse the prh and prh_alg chain-linkage construction defined in Section 5.2 when their per-hop signed artifacts form a similar chain structure, so that recipients can apply a single chain-validation routine across companions. * Companions whose artifacts do not form a chain (for example, independent per-hop attestations or recipient acknowledgments that are not linked to one another) MAY define their own integrity structure. * Companion profiles MAY define cross-receipt verification rules (for example, monotonicity rules over per-hop authority bounds, alignment rules between per-hop attestations, or aggregation rules over per-hop assertions) that compare claims across receipts in the chain. Companion profiles defining cross-receipt rules MUST tolerate sparse coverage (not every receipt is required to carry the companion's claims) unless they explicitly require completeness. Cross-companion alignment: companion artifacts that need to reference a specific receipt (for example, an actor-signed proof at hop N referencing the corresponding AS-signed receipt at hop N) SHOULD do so by the receipt's jti, which is REQUIRED on receipts and, as Section 4.1.7 of [RFC7519] requires when an application uses multiple issuers, free of collisions across issuers. This profile does not define a hop-index claim; cross-companion alignment is established through jti reference plus the prh chain's structural integrity, not through array-position metadata. Conflict resolution: when a recipient implements multiple companion profiles whose rules conflict, local policy determines precedence. Companion profiles SHOULD be designed to add, not contradict, other profiles' rejection conditions, so that conflicts arise only between profiles whose threat models are genuinely incompatible. McGuinness Expires 12 April 2027 [Page 29] Internet-Draft OAuth Actor Receipts October 2026 11. Security Considerations The OAuth 2.0 Security Best Current Practice [RFC9700] and the JWT best practices in [RFC8725] apply to systems implementing this profile, except that the audience requirements of the latter do not apply to receipt JWTs (see aud in Section 5.2). 11.1. Threat Model 11.1.1. Adversaries Mitigated by This Profile * *Compromised downstream issuer fabricating prior-hop provenance.* Such an issuer cannot forge prior issuers' receipt signatures, and the prh chain prevents it from reordering retained receipts or removing one from between receipts it retains. * *Token mutation in transit.* Each receipt is independently signed; modification invalidates the receipt's signature and any newer receipt's prh. * *Receipt transplantation between tokens with matching visible act chains.* The outer-token signature prevents parties other than the issuer from constructing a substitute outer token to host transplanted receipts. receipt[0].origin_jti adds diagnostic confirmation in the originating-issuance case (Section 11.4) but no defense against a compromised outer issuer (Section 11.6). * *Partial-coverage misclaim.* Step 6 of Section 7 rejects a chain with a dropped inner receipt or a trimmed oldest end, so an issuer can withhold coverage of the oldest hops only by beginning a new chain, and it cannot claim actor_receipts_complete: true unless the receipt count matches the visible actor-chain depth. 11.1.2. Adversaries Not Mitigated * *Omission at a compromised signing hop.* A compromised issuer can drop the newest receipts it received by linking its own receipt to an older suffix of the chain (Section 11.4). * *Compromised current outer token issuer.* Such an issuer can wrap previously harvested valid receipts in a new outer token (Section 11.6). * *Compromised receipt signing key for any one issuer.* Forged receipts are indistinguishable from legitimate ones and cannot be revoked individually. Remediation: remove the compromised issuer from the trusted-issuer set; a short receipt exp bounds the exposure window. McGuinness Expires 12 April 2027 [Page 30] Internet-Draft OAuth Actor Receipts October 2026 * *Compromised actor at a hop.* Receipts attest issuer assertions, not actor non-repudiation. Actor-signed proofs from a companion profile (Section 10) show that an actor's key signed its participation, but do not mitigate a compromised actor key or a malicious actor. * *Cross-namespace subject graft with a compromised upstream issuer.* An attacker who compromises one upstream issuer can mint receipts for any subject in that issuer's namespace and graft them onto a re-expressed downstream chain. Mitigation: exact, namespace-aware subject matching across the chain or trusted out- of-band subject mapping (Section 7.2). * *Replay of an entire token plus its receipts.* This profile does not define replay detection; receipts inherit the outer token's replay characteristics (Section 11.7). Companion profiles (Section 10) can extend the set of mitigated adversaries; for example, an actor-signed-proofs companion can prevent a current outer token issuer from fabricating actor participation at proof-covered hops when recipients require those proofs and resolve actor keys independently of that issuer, though not from re-embedding a proof submitted to it. 11.2. Current Presenter Validation When the outer token carries a top-level cnf claim ([RFC7800]), the current request is validated against it whenever the core actor profile requires the recipient to verify that binding (a resource server always; an AS in presenter rebind does not verify the previous presenter's binding), using the proof mechanism appropriate to the token type and deployment, such as DPoP [RFC9449] or mutual-TLS [RFC8705] (steps 9 and 10 of Section 7). Recipients MUST distinguish receipt JWTs (identified by typ value actor-receipt+jwt) from outer tokens that carry cnf for current-request proof-of-possession; receipt cnf records historical binding and never satisfies a current- request PoP requirement under [RFC7800], [RFC9449], or [RFC8705]. 11.3. Trust in Receipt Issuers A syntactically valid signed receipt is not by itself grounds to trust its issuer. A recipient needs to 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. McGuinness Expires 12 April 2027 [Page 31] Internet-Draft OAuth Actor Receipts October 2026 Authorization servers that support this document SHOULD advertise actor_receipts_supported: true in their AS metadata [RFC8414]. Consumers SHOULD use that metadata signal as one input to trust establishment, but metadata advertisement alone is not 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, step 5 of Section 7 checks the trusted-issuer set before any network retrieval for an issuer's metadata or keys. Trust is per-issuer and not transitive: each receipt is validated against the recipient's own trusted-issuer set, independent of the outer token's issuer or neighboring receipts. If any receipt in the presented actor_receipts array is signed by an issuer that is not trusted for receipt validation, the recipient MUST reject the receipt chain for the purposes of this profile. This document does not define trusted-prefix validation across an untrusted inner receipt, so deployments need to establish trust with every receipt issuer that can appear in tokens they accept. 11.4. Receipt-to-Token Binding Limits Receipts do not prove that the current outer token's audience, scope, expiration, or other authorization details were in force when older receipts were created. A recipient MUST NOT treat a valid receipt chain as evidence of historical authorization scope or audience beyond what the current outer token authorizes. In the originating-issuance case, a present receipt[0].origin_jti, signed by the issuer that signed the outer token and equal to that token's jti, binds receipt[0] to that outer-token instance and prevents transplantation from a different token whose visible act structure happens to match; prh then extends that binding to every inner receipt. Without that leading anchor (case 1 of Section 7.1), the chain supplies issuer-signed hop provenance only; inner origin_jti values are historical. A compromised issuer can omit some or all of its own receipts and, at its own hop, the newest receipts it received: it can link its receipt to an older suffix of the inbound chain, and a later honest issuer then extends that shortened chain. It cannot fabricate receipts signed by other trusted issuers, reorder retained receipts, or remove one from between receipts it retains, because their signatures and prh links commit to that history. Receipts prove that each retained hop was attested, not that every intermediate issuer preserved what it received. McGuinness Expires 12 April 2027 [Page 32] Internet-Draft OAuth Actor Receipts October 2026 Divergence in issuer or token identifier removes current-instance binding (Section 7.1). This profile provides no in-band means to distinguish legitimate reissuance from malicious rewrapping, so unexpected divergence warrants investigation. Companion profiles MAY define additional outer-token binding claims following the origin_jti pattern: each records an identifier from the outer token at receipt creation, with consumer verifiability conditioned on issuer alignment and equality with the current outer- token field. 11.4.1. Strict-Mode Validation When no trusted reissuing issuers are configured, recipients use strict mode, in which issuer divergence causes rejection. A missing or differing leading origin_jti under a matching issuer does not; case 3 of Section 7.1 governs it. Strict mode is the recommended default; deployments that accept tokens reissued by a different issuer, such as re-emitted or translated tokens, configure the trusted reissuing issuers explicitly, through local policy or an out-of-band trust framework. 11.5. Hash Algorithm Agility The prh_alg claim (Section 5.2) selects a hash algorithm other than the sha-256 default from the IANA Named Information Hash Algorithm Registry [RFC6920], without requiring a successor specification. Migration is whole-chain, not partial: a chain begun under one algorithm remains on it for its lifetime, consumers reject mixed or unsupported algorithms (step 6 of Section 7), and an extending issuer does not rehash inbound receipts, which would invalidate prior signers' prh values (step 7 of Section 6.2). New chains can adopt a different algorithm independently. Deployments SHOULD begin issuing new chains under the target algorithm well before any indication that the legacy algorithm is reaching end of life, so that legacy chains expire naturally. 11.6. Compromised Outer Issuer Receipts mitigate fabrication of prior-hop provenance by a compromised or dishonest _downstream_ issuer (Section 11.1), not a compromised current outer token issuer. Such an issuer can assemble a new outer token wrapping previously harvested valid receipts for the same visible chain prefix. Deployments needing stronger guarantees can combine this profile with transparency, transaction binding, or replay-detection mechanisms. McGuinness Expires 12 April 2027 [Page 33] Internet-Draft OAuth Actor Receipts October 2026 11.7. Receipt Freshness and Replay Receipts can outlive the outer token they were issued with and can be carried forward across reissuance and refresh (Section 6.3) while their exp permits. Receipt expiration bounds use of the artifact, not the delegation's lifetime: reuse of a receipt within its exp window, including in extended, fanned-out, and reissued tokens, is not in itself an attack, and replay protection for the whole token follows its token type. Active delegation status, fresh authorization, and current revocation state come from the AS via introspection ([RFC7662]), fresh token issuance, or another mechanism. 11.8. Receipt Signing Key Compromise Deployments SHOULD keep receipt exp no longer than the delegated- session lifetime it needs to cover (Section 5.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.9. Receipt Chain Size The chain grows linearly with delegation depth. At a typical 400 to 800 bytes per signed receipt, chains beyond approximately 10 hops approach the 8 KB Authorization header budget common in HTTP infrastructure (an illustrative figure). Deployments SHOULD verify that the outer token plus its actor_receipts array fits within the header-size budget of every component on the request path; returning receipts via introspection (Section 7.5) instead of embedding them avoids header pressure for bearer-token clients. 11.10. Historical cnf Disclosure Receipt cnf values reveal stable prior-hop public key identifiers or certificate thumbprints to any party that receives the token or introspection response, enabling cross-request and cross-service correlation of actors and services over time. Issuers SHOULD NOT include cnf in receipts unless the recipients that will receive the token have been evaluated for that disclosure risk and the risk is acceptable. McGuinness Expires 12 April 2027 [Page 34] Internet-Draft OAuth Actor Receipts October 2026 12. Privacy Considerations Receipts expose delegation history that recipients can retain and verify after the outer token expires. 12.1. What Receipts Disclose Receipts can expose, to any party that receives the token or introspection response: * the set of issuers that participated in the delegation chain (receipt iss values); * historical presenter-key identifiers across requests, enabling cross-session correlation of actors and services; * internal service identities and intermediary actors that a deployment might otherwise have kept visible only to intermediate issuers; * workload identifiers (for example, act.sub values) that might reveal organizational structure or orchestration topology; * subject re-expression patterns across namespaces, which can reveal cross-domain identity mappings. 12.2. Minimization Deployments SHOULD minimize receipt disclosure when full provenance is not required: * Issuers and introspection servers MAY suppress actor_receipts entirely when policy does not permit disclosure. * Resource servers SHOULD request or require actor receipts only when they materially improve authorization, audit, or risk controls. * Deployments SHOULD prefer per-resource-server policy on receipt requirements over blanket inclusion in every token. 12.3. Selective Disclosure This profile does not define a per-claim selective-disclosure mechanism for receipts: chain integrity requires byte-for-byte preservation of each receipt JWT, so selective omission of individual claims within a receipt would break the chain. Selective disclosure is therefore coarse-grained: McGuinness Expires 12 April 2027 [Page 35] Internet-Draft OAuth Actor Receipts October 2026 * Issuers MAY emit partial-coverage chains that cover only the outermost hops (see Section 6.4); this is the only mechanism for omitting individual hops, and it operates at issuance time. * Issuers and introspection servers MAY withhold the actor_receipts array entirely; a strict subset of an existing array cannot validate under Section 7 (see Section 7.5). Finer-grained selective disclosure would require a different chain- linkage construction, for example one linking against a stable hash that survives claim redaction; adding a selective-disclosure claim alone cannot achieve it within the current prh construction. 12.4. Audience Restriction A receipt is carried with the outer token to whichever audiences the outer token serves; receipts have no independent audience scoping (Section 5.2). Deployments needing audience-specific disclosure constraints SHOULD partition receipt issuance by audience at issuance time (for example, issue receipt-bearing tokens only to audiences with adequate disclosure agreements) rather than relying on receipt- level audience restriction, which this profile does not provide. 12.5. Unnecessary Hop Disclosure Receipts expose every hop the issuer chose to include. Some hops might be deployment-internal (orchestration layers, internal workload-identity services) that the deployment would not otherwise expose to recipients. Issuers SHOULD evaluate, at issuance time, which hops are appropriate to expose to which audiences. Where inner hops are not appropriate to expose, issuers SHOULD use partial coverage (omitting the inner-hop receipts) rather than fabricating, suppressing, or rewriting visible act chain entries; the latter would violate the core actor profile. 12.6. Cross-Service Correlation Stable identifiers in receipts (iss, act.sub, cnf, and any companion correlation claim such as a delegation-flow identifier) enable cross- service correlation of actors, subjects, and workflows over time. Deployments operating in privacy-sensitive contexts SHOULD evaluate the correlation risk before enabling receipts: * An audit pipeline that aggregates receipts across services builds a graph of who delegated to whom and when, across organizational boundaries. McGuinness Expires 12 April 2027 [Page 36] Internet-Draft OAuth Actor Receipts October 2026 * Receipts from a single workflow are linked by prh chain hashes, exposing the delegation graph even when individual hops are routed through privacy-preserving infrastructure. * Receipts persist longer than the outer tokens they were issued for and might be retained in audit logs indefinitely; correlation risk is not bounded by token lifetime. Extension claims can expose additional scope, audience, resource, or lifecycle information. Companion profiles defining extension claims SHOULD document the disclosure and correlation risks specific to their claims, including retention beyond token lifetime. 12.7. Detached Verification Privacy Any holder with the issuers' public keys can verify receipts, including unintended recipients. Deployments SHOULD treat token distribution as disclosure of the full carried provenance and SHOULD limit distribution accordingly. 13. IANA Considerations 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 [RFC7515] [RFC7519] 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. McGuinness Expires 12 April 2027 [Page 37] Internet-Draft OAuth Actor Receipts October 2026 * 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: Karl McGuinness, public@karlmcguinness.com * 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: IETF * 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: IETF McGuinness Expires 12 April 2027 [Page 38] Internet-Draft OAuth Actor Receipts October 2026 * Specification Document(s): This document * Claim Name: sub_iss * Claim Description: Issuer or namespace authority for the subject in an Actor Receipt JWT * Change Controller: IETF * Specification Document(s): This document * Claim Name: prh * Claim Description: Base64url-encoded hash of the immediately preceding (older) receipt in an Actor Receipt JWT chain * Change Controller: IETF * Specification Document(s): This document * Claim Name: prh_alg * Claim Description: Hash algorithm identifier (from the IANA Named Information Hash Algorithm Registry) naming the algorithm used to compute prh in an Actor Receipt JWT * Change Controller: IETF * Specification Document(s): This document * Claim Name: origin_jti * Claim Description: The jti of the outer token at the time an Actor Receipt JWT was created (the receipt's origin outer token) * Change Controller: IETF * 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, originating, preserving, or extending actor-receipt chains McGuinness Expires 12 April 2027 [Page 39] Internet-Draft OAuth Actor Receipts October 2026 * Change Controller: IETF * 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: IETF * 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: IETF * 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: IETF * Specification Document(s): This document * Name: actor_receipts_complete * Description: Indicates whether the returned actor receipts provide complete visible-hop coverage * Change Controller: IETF McGuinness Expires 12 April 2027 [Page 40] Internet-Draft OAuth Actor Receipts October 2026 * Specification Document(s): This document 14. Acknowledgments This document builds on the OAuth Actor Profile for Delegation [I-D.mcguinness-oauth-actor-profile], on the OAuth 2.0 Token Exchange specification [RFC8693], on the OAuth 2.0 Transaction Tokens work [I-D.ietf-oauth-transaction-tokens], and on prior OAuth Working Group discussion of delegation transparency, sender-constrained tokens, and proof-of-possession mechanisms ([RFC7800], [RFC8705], [RFC9449]). The author thanks the working group for that foundation. Contributors and reviewers will be acknowledged in future revisions. 15. References 15.1. Normative References [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6750] Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . McGuinness Expires 12 April 2027 [Page 41] Internet-Draft OAuth Actor Receipts October 2026 [RFC7523] Jones, M., Campbell, B., and C. Mortimore, "JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants", RFC 7523, DOI 10.17487/RFC7523, May 2015, . [RFC7662] Richer, J., Ed., "OAuth 2.0 Token Introspection", RFC 7662, DOI 10.17487/RFC7662, October 2015, . [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, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . [RFC8414] Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0 Authorization Server Metadata", RFC 8414, DOI 10.17487/RFC8414, June 2018, . [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, . [RFC8705] Campbell, B., Bradley, J., Sakimura, N., and T. Lodderstedt, "OAuth 2.0 Mutual-TLS Client Authentication and Certificate-Bound Access Tokens", RFC 8705, DOI 10.17487/RFC8705, February 2020, . [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best Current Practices", BCP 225, RFC 8725, DOI 10.17487/RFC8725, February 2020, . [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, . McGuinness Expires 12 April 2027 [Page 42] Internet-Draft OAuth Actor Receipts October 2026 [RFC9728] Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, . [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-11, 30 July 2026, . [I-D.mcguinness-oauth-actor-profile] McGuinness, K., "OAuth Actor Profile for Delegation", Work in Progress, Internet-Draft, draft-mcguinness-oauth-actor- profile-00, 30 April 2026, . [I-D.mora-oauth-entity-profiles] Mora, S. C., Dingle, P., and K. McGuinness, "OAuth Entity Profiles", Work in Progress, Internet-Draft, draft-mora- oauth-entity-profiles-01, 17 April 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 15.2. Informative References [RFC9493] Backman, A., Ed., Scurtescu, M., and P. Jain, "Subject Identifiers for Security Event Tokens", RFC 9493, DOI 10.17487/RFC9493, December 2023, . [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, . McGuinness Expires 12 April 2027 [Page 43] Internet-Draft OAuth Actor Receipts October 2026 [I-D.mw-oauth-actor-chain] Prasad, A., Krishnan, R., Lopez, D., and S. Addepalli, "Cryptographically Verifiable Actor Chains for OAuth 2.0 Token Exchange", Work in Progress, Internet-Draft, draft- mw-oauth-actor-chain-01, 15 June 2026, . [I-D.liu-oauth-chain-delegation] Liu, D., Zhu, J., Krishnan, S., and A. Parecki, "Delegation Chain for OAuth 2.0", Work in Progress, Internet-Draft, draft-liu-oauth-chain-delegation-00, 7 June 2026, . [I-D.liu-oauth-authorization-evidence] Liu, D., Zhu, J., Krishnan, S., and A. Parecki, "Authorization Evidence and Audit Trail for OAuth 2.0 Access Tokens", Work in Progress, Internet-Draft, draft- liu-oauth-authorization-evidence-01, 22 June 2026, . Appendix A. Examples The examples in this appendix show decoded receipt contents. Actual receipts are JWS compact-serialized JWT strings carried in the actor_receipts array. The iat and exp values shown are illustrative only; in deployments, receipt exp is set per Section 5.2 and Section 6.2 so that no inbound receipt expires before the outer token that carries it. Examples that contain the cnf claim illustrate explicit disclosure of historical presenter binding. Whether to include it follows Section 11.10. A.1. Example: Two-Hop Delegation Chain The following example shows an outer token that carries a two-hop visible actor chain: McGuinness Expires 12 April 2027 [Page 44] Internet-Draft OAuth Actor Receipts October 2026 { "jti": "d3a1b2c0-9f4e-4a1d-b8e7-12345678abcd", "iss": "https://as.travel-provider.example", "sub": "https://idp.enterprise.example/users/alice", "act": { "sub": "https://tools.travel-provider.example/booking-tool", "iss": "https://as.travel-provider.example", "sub_profile": "service", "act": { "sub": "https://agents.enterprise.example/travel-assistant", "iss": "https://as.enterprise.example", "sub_profile": "ai_agent" } }, "cnf": { "jkt": "ToolJKT" }, "actor_receipts": [ "", "" ], "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.travel-provider.example/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", "origin_jti": "d3a1b2c0-9f4e-4a1d-b8e7-12345678abcd" } actor_receipts[1] is the older receipt, created by the enterprise AS when it first added the AI agent: McGuinness Expires 12 April 2027 [Page 45] Internet-Draft OAuth Actor Receipts October 2026 { "iss": "https://as.enterprise.example", "sub": "https://idp.enterprise.example/users/alice", "sub_iss": "https://idp.enterprise.example", "act": { "sub": "https://agents.enterprise.example/travel-assistant", "iss": "https://as.enterprise.example", "sub_profile": "ai_agent" }, "cnf": { "jkt": "AgentJKT" }, "iat": 1776741600, "exp": 1776832000, "jti": "1d4c4d30-fb6d-4172-b7eb-775b6b9c2b85", "origin_jti": "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 records that the earlier actor hop was bound to AgentJKT when it was created. The sub_iss claim in receipt[1] records that the subject identifier https://idp.enterprise.example/users/alice is interpreted under the enterprise IdP's namespace authority, which is distinct from the receipt's signer (https://as.enterprise.example, the enterprise AS). A.2. Example: Transaction Token Service Rebinding Suppose an internal workload identified as https://wimse.travel- provider.example/payments exchanges the access token above at a TTS, presenting its own workload credential, issued by https://tts.travel- provider.example, as actor_token, and the TTS rebinds the issued Transaction Token to it. The resulting Transaction Token can carry: McGuinness Expires 12 April 2027 [Page 46] Internet-Draft OAuth Actor Receipts October 2026 { "jti": "f0e1d2c3-b4a5-6789-cdef-012345678901", "iss": "https://tts.travel-provider.example", "sub": "https://idp.enterprise.example/users/alice", "act": { "sub": "https://wimse.travel-provider.example/payments", "iss": "https://tts.travel-provider.example", "sub_profile": "service", "act": { "sub": "https://tools.travel-provider.example/booking-tool", "iss": "https://as.travel-provider.example", "sub_profile": "service", "act": { "sub": "https://agents.enterprise.example/travel-assistant", "iss": "https://as.enterprise.example", "sub_profile": "ai_agent" } } }, "cnf": { "jkt": "PaymentsJKT" }, "actor_receipts": [ "", "", "" ], "actor_receipts_complete": true } The new leading receipt created by the TTS is: McGuinness Expires 12 April 2027 [Page 47] Internet-Draft OAuth Actor Receipts October 2026 { "iss": "https://tts.travel-provider.example", "sub": "https://idp.enterprise.example/users/alice", "act": { "sub": "https://wimse.travel-provider.example/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", "origin_jti": "f0e1d2c3-b4a5-6789-cdef-012345678901" } The inherited receipts for the booking tool and the AI agent are carried forward unchanged. A.3. Example: Partial Receipt Coverage When receipt support is rolled out progressively across issuers, downstream tokens can carry coverage for only the outermost hops. Suppose the enterprise AS has not yet deployed receipt support, and the travel-provider AS has. The enterprise AS issues a delegated token introducing the AI agent without a receipt. The travel- provider AS exchanges that token, adds the booking tool as the new outermost actor, and creates a single receipt for that hop. The resulting access token carries: McGuinness Expires 12 April 2027 [Page 48] Internet-Draft OAuth Actor Receipts October 2026 { "jti": "b6d94f2a-3c81-47e5-9a0d-5f6e7a8b9c0d", "iss": "https://as.travel-provider.example", "sub": "https://idp.enterprise.example/users/alice", "act": { "sub": "https://tools.travel-provider.example/booking-tool", "iss": "https://as.travel-provider.example", "sub_profile": "service", "act": { "sub": "https://agents.enterprise.example/travel-assistant", "iss": "https://as.enterprise.example", "sub_profile": "ai_agent" } }, "cnf": { "jkt": "ToolJKT" }, "actor_receipts": [ "" ], "actor_receipts_complete": false } The single receipt covers the outermost hop: { "iss": "https://as.travel-provider.example", "sub": "https://idp.enterprise.example/users/alice", "act": { "sub": "https://tools.travel-provider.example/booking-tool", "iss": "https://as.travel-provider.example", "sub_profile": "service" }, "cnf": { "jkt": "ToolJKT" }, "iat": 1776745200, "exp": 1776832000, "jti": "9b7a4e30-2c1f-4d8a-9b5e-f0e8a3c4b6d2", "origin_jti": "b6d94f2a-3c81-47e5-9a0d-5f6e7a8b9c0d" } McGuinness Expires 12 April 2027 [Page 49] Internet-Draft OAuth Actor Receipts October 2026 The prh claim is omitted because this is a single-element chain. actor_receipts_complete: false signals to recipients that the inner AI-agent hop is uncovered. Resource servers that set actor_receipts_complete_required: true in their Protected Resource Metadata reject this token; resource servers that accept partial coverage validate the receipt-attested outermost hop and treat the inner hop as carried solely by the visible act chain, with no independent receipt-level provenance. A.4. Example: Reissuance Without a New Actor Hop Suppose an introspection endpoint, operated as a trust principal separate from the originating travel-provider AS, introspects the access token from the Two-Hop Delegation Chain example and re-emits it as a JWT for an internal service. Re-emission adds no actor hop, so per Section 6.3 the re-emitting issuer carries the inbound actor_receipts array forward unchanged and creates no new receipt. The re-emitted token carries the following claims: { "jti": "f4a7b9c2-1d3e-4f5a-8b6c-7d8e9f0a1b2c", "iss": "https://introspection.travel-provider.example", "sub": "https://idp.enterprise.example/users/alice", "act": { "sub": "https://tools.travel-provider.example/booking-tool", "iss": "https://as.travel-provider.example", "sub_profile": "service", "act": { "sub": "https://agents.enterprise.example/travel-assistant", "iss": "https://as.enterprise.example", "sub_profile": "ai_agent" } }, "cnf": { "jkt": "ToolJKT" }, "actor_receipts": [ "", "" ], "actor_receipts_complete": true } The receipts are byte-for-byte identical to those in the Two-Hop Delegation Chain example. Two divergences from the originating- issuance pattern, both legitimate under Section 6.3, are visible at the outer-token level: McGuinness Expires 12 April 2027 [Page 50] Internet-Draft OAuth Actor Receipts October 2026 * outer.iss is https://introspection.travel-provider.example, while receipt[0].iss remains https://as.travel-provider.example. * outer.jti is f4a7b9c2-1d3e-4f5a-8b6c-7d8e9f0a1b2c, while receipt[0].origin_jti remains d3a1b2c0-9f4e-4a1d-b8e7-12345678abcd (the original outer token's jti). Under Section 7.1, origin_jti is historical here because the outer issuer and token identifier have changed, and acceptance requires explicit trust in the reissuing issuer (Section 11.4). When an AS refreshes its own token with a new jti, case 3 applies instead: local policy can accept the chain as provenance, but not as instance-bound. Document History [[ To be removed from the final specification ]] -01 * Restructured and tightened the text: each rule has one home, dependencies are cited rather than restated, a table covers the claim-pair convention, scope and related work are in the Introduction, and Security Considerations point to the rules they rely on. * Added Receipt Instance Binding; strict mode rejects only issuer divergence, and a same-issuer chain whose origin_jti differs, as after refresh, is accepted without instance binding. * Named ID-JAG and other assertion-grant redemption without a new hop, and TTS presenter continuation, as different-issuer reissuance. * Defined one lifetime rule for extension, reissuance, and refresh (lower the token's exp, drop the array, or fail), added a floor for receipt exp, and made an expired older receipt invalid. * Refresh no longer starts a new chain, and retained receipts are validated against the issuer's state rather than the previous access token. * An extending issuer takes the inbound receipts from the token carrying the delegation chain, a new receipt's iss equals the issued token's iss, and a reissuer validates a chain before carrying it forward. McGuinness Expires 12 April 2027 [Page 51] Internet-Draft OAuth Actor Receipts October 2026 * A failed receipt chain removes only receipt-based provenance unless policy or metadata requires receipts, and a failed companion rule removes only that companion's evidence unless the companion specifies otherwise. Authorization based on receipts rests on the validated actor_receipts claim, and nested act stays informational, per Section 4.1 of [RFC8693]. * Prohibited aud in receipts. * Aligned error codes with [RFC8693] and [RFC7523]: invalid_request on Token Exchange, invalid_grant on JWT bearer grants and refresh, and actor_unauthorized for actor-authorization failures. * Clarified completeness: an extending issuer sets actor_receipts_complete: true when the receipt count matches, an introspection false makes no completeness attestation, and filtering is limited to introspection servers. * Compared sub_profile values as sets. * Allowed a TTS to include jti for instance binding, and deferred Transaction Token rejection at the resource server to the deployment. * Checked typ and alg before key resolution, rejected a chain with any untrusted receipt issuer, and placed resource-server actor authorization after receipt processing. * Narrowed the threat-model claims about actor-signed proofs, and stated that a compromised issuer can drop the newest receipts it received. * Removed BCP 14 keywords from guidance no other party can observe, named the IETF as change controller, and aligned the examples with the base profile. -00 * Initial version. Author's Address Karl McGuinness Independent Email: public@karlmcguinness.com McGuinness Expires 12 April 2027 [Page 52]