OAuth Actor Receipts for Delegation Provenance

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

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

• 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, or a token translator at a domain boundary reissues it. 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.¶

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

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

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

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

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

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

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]:¶

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 <name> plus <name>_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.¶

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 per the bearer-token error model in Section 3.1 of [RFC6750]. 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.¶

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

11.1. Threat Model

11.2. Current Presenter Validation

When the outer token carries a top-level cnf claim ([RFC7800]), the current request is always validated against it, 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.¶

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 any outermost receipts from issuers it controls, but it cannot fabricate, reorder, or selectively drop receipts signed by other trusted issuers.¶

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

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

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

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

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

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

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

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

• Specification Document(s): This document¶

15.1. Normative References

[RFC6749]

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

[RFC6750]

Jones, M. and D. Hardt, "The OAuth 2.0 Authorization Framework: Bearer Token Usage", RFC 6750, DOI 10.17487/RFC6750, October 2012, <https://www.rfc-editor.org/info/rfc6750>.

[RFC6838]

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

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

[RFC7515]

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

[RFC7519]

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

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

[RFC7662]

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

[RFC7800]

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

[RFC8259]

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

[RFC8414]

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

[RFC8693]

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

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

[RFC8725]

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

[RFC9449]

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

[RFC9728]

Jones, M.B., Hunt, P., and A. Parecki, "OAuth 2.0 Protected Resource Metadata", RFC 9728, DOI 10.17487/RFC9728, April 2025, <https://www.rfc-editor.org/info/rfc9728>.

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

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

[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, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-actor-profile-00>.

[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, <https://www.ietf.org/archive/id/draft-mora-oauth-entity-profiles-01.txt>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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

[RFC9700]

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

[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, <https://datatracker.ietf.org/doc/html/draft-mw-oauth-actor-chain-01>.

[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, <https://datatracker.ietf.org/doc/html/draft-liu-oauth-chain-delegation-00>.

[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, <https://datatracker.ietf.org/doc/html/draft-liu-oauth-authorization-evidence-01>.

A.1. Example: Two-Hop Delegation Chain

The following example shows an outer token that carries a two-hop visible actor chain:¶

{
  "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": [
    "<receipt-0>",
    "<receipt-1>"
  ],
  "actor_receipts_complete": true
}

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

{
  "iss": "https://as.travel-provider.example",
  "sub": "https://idp.enterprise.example/users/alice",
  "act": {
    "sub": "https://tools.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:¶

{
  "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 the booking tool exchanges the access token above at a TTS, and the TTS rebinds the issued Transaction Token to an internal workload identified as https://wimse.travel-provider.example/payments.¶

The resulting Transaction Token can carry:¶

{
  "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": [
    "<receipt-tts>",
    "<receipt-0>",
    "<receipt-1>"
  ],
  "actor_receipts_complete": true
}

The new leading receipt created by the TTS is:¶

{
  "iss": "https://tts.travel-provider.example",
  "sub": "https://idp.enterprise.example/users/alice",
  "act": {
    "sub": "https://wimse.travel-provider.example/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:¶

{
  "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": [
    "<receipt-0>"
  ],
  "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"
}

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": [
    "<receipt-0>",
    "<receipt-1>"
  ],
  "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:¶

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