OAuth Actor-Signed Hop Proofs

3.1. Relationship to the Actor Receipts Companion

Proofs and receipts attest the same hops from different signers with different trust anchors: a receipt is signed by the authorization server that added the hop, while a proof is signed by the actor that was added. The two companions are carried independently. A token MAY carry either, both, or neither, and recipients select a validation posture by policy:¶

• Receipts-only: proofs absent or ignored; trust per [I-D.mcguinness-oauth-actor-receipts].¶

• Proofs-only: receipts absent or ignored; trust rests on actor-key resolution and actor signatures.¶

• Belt-and-suspenders: both validated; the token carries independent issuer-side and actor-side evidence for covered hops, and sibling references bind the two chains together (Section 9.6).¶

The choice of posture is per-recipient deployment policy; this document does not standardize it.¶

The two companions remain separate artifacts rather than a single multi-signature artifact because their signers, adoption prerequisites, and threat models differ: receipts require only issuer-side implementation, while proofs additionally require actor signing keys and recipient-side actor-key resolution. A JWS structure carrying both signatures over one payload (JWS JSON Serialization, [RFC7515] Section 7.2) would express the sibling relationship more directly but is poorly supported in common OAuth token processing libraries; two parallel arrays of compact-serialized JWTs compose with existing tooling.¶

The receipts companion's discussion of receipt-based provenance versus token introspection applies equally to proofs; see [I-D.mcguinness-oauth-actor-receipts].¶

3.2. Relationship to Other Actor-Evidence Work

Several contemporaneous efforts add actor-side or issuer-side delegation evidence to OAuth deployments; they differ from this profile chiefly in where evidence lives, who signs it, and who can verify it. This section is informative.¶

[I-D.mw-oauth-actor-chain] also defines actor-signed step proofs, but they are submitted at token exchange and retained by the authorization server; only an issuer-signed cumulative commitment travels in the token, so recipients verify commitment continuity while actor signatures remain an exchange-time and audit-time property gated on issuer retention. Under this profile, proofs are carried in the token and validated by recipients directly, at the cost of per-hop token growth. [I-D.liu-oauth-chain-delegation] carries authorization-server-signed per-hop delegation records inline, optionally countersigned by the delegator; the countersigned fields carry no target binding, and records are re-signed at trust-domain boundaries. [I-D.jiang-oauth-intent-admission] defines a single-hop intent artifact whose signature belongs to the admission authority rather than the acting party.¶

The distinguishing property of this profile relative to each is a recipient-verifiable artifact signed by the actor itself, before issuance, over an explicit target binding. These designs address overlapping needs; convergence is a working-group discussion this document aims to inform rather than preempt.¶

4.1. Deployment Fit

This profile's value is concentrated in deployments where actors hold signing keys: AI agents, workloads, and services with their own credentials. Where actors cannot sign, actor receipts [I-D.mcguinness-oauth-actor-receipts] remain the available provenance layer, and this profile adds nothing. The two companions serve complementary deployment populations and are strongest together.¶

Proofs shift trust configuration from per-issuer enumeration to per-actor key resolution. This is a different burden, not a smaller one: the population of actors is typically larger than the population of issuers, and a recipient must establish a trusted actor-key source for every actor whose proofs it relies on (Section 14.3).¶

The anti-fabrication property of this profile is conditional on recipients requiring proofs. An issuer that fabricates actor participation simply omits proofs; recipients that accept proof-less delegated tokens receive no protection from this profile (Section 14.6).¶

7.1. JOSE Header

The JOSE header of an actor proof:¶

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

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

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

• SHOULD include kid when the actor's key source publishes multiple verification keys;¶

• MAY include crit per [RFC7515]; consumers MUST reject a proof whose crit header lists an extension header the consumer does not understand.¶

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

7.2. Proof Claims

The JWT payload of an actor proof uses the claims defined below, grouped by purpose.¶

7.3. Proof-Chain Linkage

When an actor signs a new proof that extends an inherited proof chain:¶

• if there is an older proof immediately following it in the array, the new proof MUST include prh, and that value MUST be the base64url encoding without padding of the hash of the ASCII octets of the exact compact JWT string of that next proof;¶

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

No JSON [RFC8259] canonicalization is applied. prh hashes the ASCII octets of the exact compact-serialized JWS string of the next older proof as carried in the array, and the hash output is base64url-encoded without padding. Systems that carry, store, or forward actor_proofs arrays MUST preserve each compact JWT string byte-for-byte; any modification, including semantically equivalent re-encoding, invalidates prh for any proof that references it.¶

9.1. Accepting a Proof for a New Actor Hop

When an issuer adds a new outermost actor hop and the token request carries actor_proof, the issuer:¶

1. MUST validate the proof's structure per Section 7: typ value, asymmetric alg, presence and JSON types of the REQUIRED claims iss, sub, act, target (including target.aud), iat, exp, and jti, and the single-hop act rules.¶

2. MUST verify that the proof's (act.iss, act.sub) pair equals the actor identifier pair the issuer will emit as the new outermost visible act object, and that the proof iss equals the proof act.sub.¶

3. MUST verify that the proof sub equals the top-level sub of the token being issued. An issuer that re-expresses the subject at this hop MUST NOT embed the proof; re-expression breaks the alignment between actor_proofs[0].sub and the outer token's top-level sub that consumers verify under Section 10.¶

4. MUST resolve the actor's verification key through an actor-key source trusted under the issuer's local policy and validate the proof's signature (Section 14.3).¶

5. MUST verify that the proof's exp is no earlier than the issued outer token's exp, and that iat is plausible under the issuer's clock-skew policy.¶

6. MUST NOT issue an outer token whose aud, or whose effective resource indicators when the request expresses them, exceed the proof's target binding. Every audience of the issued token MUST be present in target.aud, and every effective resource indicator MUST be within target.resource when that member is present. For Token Exchange requests, an issuer that cannot satisfy the requested target within the proof's target binding SHOULD reject with invalid_target per [RFC8693] Section 2.2.2.¶

7. MUST include the validated proof as actor_proofs[0] of the issued token, subject to the chain rules below.¶

When no inbound actor_proofs are being preserved, the proof starts a new chain and MUST omit prh. When the one-element array covers every visible hop (a visible act chain of depth 1), the issuer SHOULD set actor_proofs_complete: true; when inner visible hops remain uncovered, it SHOULD set actor_proofs_complete: false, per Section 6.¶

If proof validation fails, the issuer MUST NOT embed the proof. When local policy or the deployment's resource requirements require actor-signed evidence for the issuance, the issuer MUST fail the request under the error model of Section 12; otherwise it MAY issue the token without actor_proofs.¶

9.2. Extending an Existing Proof Chain

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

1. MUST validate the inbound proof chain by applying the consumer processing rules in Section 10 before relying on it or carrying it forward.¶

2. MUST verify that each inbound proof's exp is no earlier than the issued outer token's exp. An inbound proof that fails this check is treated as failing validation under step 1. Issuers MAY apply a small clock-skew margin to this comparison, consistent with the consumer-side skew tolerance in Section 10, but MUST NOT broadly accept inbound proofs whose exp precedes the issued outer token's exp by more than a deployment-defined skew bound.¶

3. MUST preserve each inbound proof byte-for-byte unchanged.¶

4. MUST accept exactly one new proof, conveyed per Section 8 and validated per Section 9.1, for the new outermost actor hop.¶

5. MUST verify that the new proof's prh equals the hash of the exact compact serialization of the inbound array's newest proof, computed using the algorithm named by the inherited prh_alg (defaulting to SHA-256 when absent), and MUST verify that the new proof's prh_alg matches the inherited chain's value or is omitted when the chain omits it. An issuer that does not support the inbound prh_alg MUST reject the chain rather than rehash; rehashing would invalidate prior actors' signatures.¶

6. MUST prepend the new proof to the inherited array.¶

7. MUST set the issued outer token's actor_proofs_complete to true when the validated inbound chain carried actor_proofs_complete: true and the new proof covers the new outermost actor hop; downgrading to absent or false in that case would falsely signal a coverage reduction to recipients that test for the literal value true. When the issuer cannot attest complete coverage for the issued chain (for example, the inbound chain was partial or carried no completeness attestation), it MUST NOT set actor_proofs_complete: true and SHOULD set actor_proofs_complete: false, per Section 6.¶

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

Chain linkage requires the signing actor to know the exact compact serialization of the newest inbound proof, because the actor computes and signs prh. When the inbound subject token is a JWT, the actor reads actor_proofs[0] from the token it presents. When the inbound subject token is opaque, the deployment MUST convey the newest inbound proof, or its hash and the chain's prh_alg, to the actor before signing; when it cannot, the issuer MUST NOT accept a prh-less proof as an extension of the inbound chain, and MAY instead start a new chain under Section 9.1 where local policy permits partial coverage (Section 9.4).¶

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

9.3. Reissuance Without a New Actor Hop

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

• MAY carry an inbound actor_proofs array forward unchanged;¶

• MUST NOT accept or embed a new proof;¶

• MUST carry the inbound actor_proofs_complete value forward unchanged when the inbound array is carried forward unchanged; an issuer that cannot continue to attest the inbound coverage value MUST drop the inbound array entirely rather than keep the array and silently downgrade actor_proofs_complete. Proof disclosure is all-or-nothing for a given token: a strict subset of an inherited array cannot validate under Section 10;¶

• MUST NOT continue to carry an inherited actor_proofs array if it cannot preserve the visible hop alignment required by Section 10;¶

• MUST NOT change the outer token's top-level sub while carrying inherited proofs forward; a sub change re-expresses subject identity and breaks the alignment between actor_proofs[0].sub and the outer token's top-level sub that consumers verify under Section 10.¶

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

Reissuance interacts with the target binding. A reissued token whose aud or effective resource indicators exceed actor_proofs[0]'s target binding is rejected by default-posture recipients under step 9 of Section 10. An issuer that retargets the audience beyond the newest proof's target binding MUST drop the inherited actor_proofs array unless the deployment's recipients are configured to accept reissuance divergence under Section 14.4.1; a retargeted token carrying proofs is interoperable only inside such a deployment. Reissuance that narrows or preserves the audience within actor_proofs[0].target does not disturb the proof chain.¶

When an issuer drops an inherited actor_proofs array while carrying an actor_receipts array forward, any proof_jti values in the retained receipts (Section 9.6) name proofs that no longer travel with the token. Those references become informational only; recipients that require bound siblings enforce proof presence through actor_proofs_required or local policy, not through receipt-side references alone.¶

An AS that supports refresh tokens for delegated access tokens carrying proofs:¶

• MUST retain the actor_proofs array 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 each refreshed access token can carry the proofs forward unchanged.¶

• MUST rely on proof exp values set per Section 7.2 to accommodate the bounded maximum delegated-session lifetime. Otherwise downstream issuers reject inbound chains under Section 9.2 as proofs approach expiry, and refresh loses actor-signed evidence.¶

• When that bounded lifetime would be exceeded, MUST either obtain fresh delegation state with fresh proofs or stop emitting actor_proofs, unless local policy permits partial or absent coverage.¶

9.4. Partial Coverage and Full Coverage

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

However:¶

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

• an issuer MUST NOT skip an outer visible hop and carry a proof only for an inner visible hop;¶

• when local policy or resource requirements require full actor-signed evidence, the issuer MUST either emit complete proof coverage or fail the request under the error model of the underlying protocol.¶

Because coverage is a contiguous outermost prefix, partial coverage always omits the innermost (oldest) hops first. In many delegation chains the innermost hop is the original subject-to-actor delegation, the hop with the greatest audit and accountability value. Deployments that value actor-signed evidence for that originating hop SHOULD deploy proof support at the origin issuer and its actors first: once the originating actor's proof starts the chain, every downstream issuer that supports this profile extends it, and coverage is complete by construction. Resource servers that require evidence for the originating hop enforce it through actor_proofs_complete_required (Section 11) or equivalent local policy.¶

When the issuer also filters the visible act chain (see the chain_complete introspection member defined in the core actor profile [I-D.mcguinness-oauth-actor-profile]), actor_proofs covers only the visible filtered chain. In that case actor_proofs_complete describes coverage relative to the visible filtered chain, not the unfiltered delegation chain; recipients that need true-chain completeness MUST evaluate chain_complete separately.¶

9.5. Transaction Token Service Rebinding

A Transaction Token Service that establishes a new presenter and makes that presenter the new outermost actor follows the same proof rules as any other issuer that adds a new outermost actor hop, as defined in Section 9.2 (or Section 9.1 when no inbound actor_proofs exist). The new presenter is the signing actor for the new proof; inherited proofs are carried forward unchanged. This profile does not define additional proof claims specific to Transaction Tokens.¶

9.6. Sibling Receipt Issuance

When a deployment uses both this profile and [I-D.mcguinness-oauth-actor-receipts], the issuer that adds a hop creates the receipt and embeds the proof for that hop in the same issuance operation. The two artifacts are siblings: independent attestations of the same hop by different signers.¶

This document defines the following extension claim for Actor Receipt JWTs, under the extension-claims rule of [I-D.mcguinness-oauth-actor-receipts]:¶

proof_jti:

OPTIONAL. The jti of the proof the receipt issuer validated for the same hop. When the issuer embeds a proof and creates a sibling receipt for one hop, the receipt SHOULD include proof_jti equal to that proof's jti.¶

proof_jti binds in the feasible direction: the issuer signs the receipt after the proof exists, so it can always name the proof, whereas the actor can name the receipt in receipt_jti only when the receipt identifier was provisioned before signing (Section 7.2). Because receipts are preserved byte-for-byte, proof_jti is fixed at receipt creation and travels with the receipt chain; a later substitution of the proof array for a different harvested proof chain is detectable through the mismatch (Section 14.1).¶

Consumer verification of sibling references is defined in step 10 of Section 10.¶

10.1. Subject Re-Expression Across Hops

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

Accordingly:¶

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

• older proof sub values MAY differ;¶

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

Recipients MUST be aware that permitting differing sub values across proofs creates a cross-subject insertion risk: a proof signed by a legitimate actor for an unrelated subject's delegation could satisfy the structural hop-alignment check when the actor identity at that hop matches. An attacker who compromises any single actor signing key can deliberately sign proofs naming any subject and any target, and graft them onto a downstream chain whose re-expressed sub points at a victim subject.¶

This profile provides no in-band mechanism for cross-namespace subject reconciliation.¶

Deployments where subject continuity is a security requirement SHOULD adopt one of the following:¶

• require consistent sub values across all proofs in the chain, rejecting re-expressed chains; or¶

• enforce explicit trusted subject-mapping rules that can positively confirm each distinct sub value refers to the same underlying entity.¶

When neither condition is met, the recipient MUST treat the differing sub values as unverified subject continuity and MUST NOT rely on those older proofs for authorization decisions.¶

10.2. Complete Proof Coverage

A recipient can infer structural complete proof coverage by comparing proof count with visible actor depth. If the number of proofs equals the visible actor depth and all validation rules above succeed, the token has structurally complete proof coverage for the visible chain.¶

When local policy only needs structural completeness, that inferred count match is sufficient. When Protected Resource Metadata declares actor_proofs_complete_required: true, the token or introspection response MUST also carry actor_proofs_complete: true; a count match without that explicit issuer attestation does not satisfy the metadata-declared requirement.¶

If local policy or resource requirements require full actor-signed evidence, the recipient MUST reject tokens that do not satisfy the applicable complete-coverage requirement.¶

10.3. Use by Resource Servers

Resource servers can use validated actor proofs as evidence input for authorization, diagnostics, and audit. However, a valid proof chain:¶

• proves only that the covered actors signed their participation and hop-time target bindings;¶

• does not prove that the represented delegation remains active, authorized, or acceptable under current policy;¶

• does not prove that any authorization server validated the hop; that attestation is the receipts companion's role;¶

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

• does not convey authority, authorization, entitlement, or delegation rights;¶

• is not actor consent to the current request; it is actor consent to the hop-time issuance within the recorded target binding.¶

A resource server that bases an authorization decision on proof content alone, without re-evaluating the current outer token and current policy, mis-uses this profile.¶

10.4. Introspection

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

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

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

The registered introspection response members are defined in Section 11.3; introspection-server failure handling is addressed in Section 12.3.¶

Introspection is the primary delivery mechanism for proofs associated with opaque (non-JWT) outer tokens. Such tokens cannot carry an inline actor_proofs claim; the issuer instead retains the proofs in its token store and surfaces them to authorized resource servers via introspection. The proof format and consumer processing rules above apply unchanged in this case, with the introspection response substituting for the outer token's claim set.¶

An introspection response that includes actor_proofs MUST include the members needed to perform the consumer processing in Section 10: the token's top-level sub, the visible act chain, the token's aud, and the token's iss. When the introspection server maintains a jti for the token, the response SHOULD include it so that recipients can evaluate origin_jti binding; when jti is absent from the response, recipients treat the chain as carrying no instance binding per step 9. If actor_proofs_complete is present, it MUST be a JSON boolean. A resource server that receives both inline proofs in a JWT token and proofs in an introspection response MUST apply local policy to choose the authoritative source; if both sources are consumed together, mismatched actor_proofs or actor_proofs_complete values MUST cause the resource server to reject proof-based provenance for the token.¶

Proof disclosure through introspection is all-or-nothing for a given token: a strict subset of the stored array cannot validate under Section 10, because removing an older proof leaves the next newer proof's prh without a target and removing the newest proof breaks visible-hop alignment. An introspection server that cannot disclose the full stored array for privacy or policy reasons MUST omit actor_proofs from the response entirely. A stored array that itself has partial coverage is returned in full, with actor_proofs_complete: false.¶

When the introspected token is revoked or otherwise inactive, the introspection response follows the core actor profile's suppression rule for delegation claims: an introspection server MUST NOT return actor_proofs or actor_proofs_complete for a token it reports as inactive.¶

The core actor profile's chain_complete introspection member and actor_proofs_complete are distinct signals, exactly as described for receipts in [I-D.mcguinness-oauth-actor-receipts]: when chain_complete: false, proof coverage is complete only for the visible filtered chain, not the full delegation chain.¶

11.1. Authorization Server Metadata

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

actor_proofs_supported:

OPTIONAL. A boolean. When true, the authorization server advertises that it accepts the actor_proof token request parameter, validates proofs against actor keys, and embeds, preserves, or extends proof chains according to this document. This value does not guarantee complete coverage for every visible hop in every resulting token. When false or absent, clients and relying parties MUST NOT assume such support.¶

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

11.2. Protected Resource Metadata

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

actor_proofs_required:

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

Unlike receipt issuance, proof creation involves the actor directly: an actor that can sign proofs MAY use this declaration, together with actor_proofs_supported in Authorization Server Metadata, to decide to include actor_proof in its token requests. The declaration also serves deployment coordination and expresses the enforcement posture under which this profile's anti-fabrication property holds (Section 14.6).¶

actor_proofs_complete_required:

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

11.3. Introspection Response Members

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

actor_proofs:

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

actor_proofs_complete:

OPTIONAL. A boolean. When true, the introspection response indicates that the returned actor_proofs cover every visible hop in the token chain as known to the introspection server. When false, the response indicates that the returned proofs provide only partial coverage of the visible chain.¶

Consumer use of these members is described in Section 10.4; introspection-server failure handling is addressed in Section 12.3.¶

11.4. Out-of-Scope Discovery Signals

This document does not define metadata for actor-key source discovery; recipients establish actor-key sources through explicit trust frameworks (Section 14.3), not through metadata defined here. It also does not define a metadata signal for requiring bound siblings (proof_jti on receipts); deployments that need bound siblings coordinate that requirement through deployment policy.¶

12.1. Authorization Server and Transaction Token Service Errors

When an authorization server or Transaction Token Service rejects a token request because an inbound actor_proofs chain or a newly submitted proof cannot be validated (signature failure, key-resolution failure for an actor outside the trusted key sources, expired proof, unsupported prh_alg, broken prh chain, hop or subject misalignment), it SHOULD return invalid_grant, constructed per [RFC8693] Section 2.2.2 and [RFC6749] Section 5.2, consistent with the core actor profile's error mapping for actor information that fails validation.¶

When the requested token's audience or resources cannot be satisfied within the submitted proof's target binding in a Token Exchange request, the issuer SHOULD return invalid_target per [RFC8693] Section 2.2.2.¶

When the failure reflects an actor-authorization decision rather than a structural validation failure, an issuer MAY use actor_unauthorized as defined in the core actor profile [I-D.mcguinness-oauth-actor-profile] where applicable.¶

12.2. Resource Server Errors

When a resource server rejects a request because actor_proofs validation fails under Section 10, it SHOULD return invalid_token per the bearer-token error model in [RFC6750] Section 3.1.¶

When the failure is specifically that required proofs are absent or coverage is incomplete (per actor_proofs_required or actor_proofs_complete_required), the resource server SHOULD include an error_description value identifying proof-coverage failure so that clients and operators can distinguish it from generic token-validation failures.¶

12.3. Introspection Server Behavior

When an introspection server cannot return proofs that the requesting resource server requires, it returns the introspection response per [RFC7662] with actor_proofs absent or with actor_proofs_complete: false; the resource server then applies its local policy to decide whether to accept the token.¶

The introspection server itself does not return an OAuth error for missing proofs; proof presence is a property of the introspection response, not a precondition for it.¶

12.4. No New Error Codes

This document does not define new OAuth error codes. The mapping above reuses existing codes from [RFC6749], [RFC6750], [RFC8693], and the core actor profile.¶

14.1. Threat Model

This section indexes the adversary classes addressed (and not addressed) by this profile. Detailed mitigations live in Section 14.3, Section 14.4, Section 14.6, and Section 10.1.¶

14.2. Current Presenter Validation

The current request is always validated against the outer token's top-level cnf ([RFC7800]), when present, using the proof mechanism appropriate to the token type and deployment, such as DPoP [RFC9449] or mutual-TLS [RFC8705].¶

An actor proof is never a substitute for that validation:¶

• A recipient MUST NOT treat a proof signature as satisfying a proof-of-possession requirement for the current request, regardless of whether the proof signing key is the same key as a presenter key.¶

• Recipients MUST distinguish proof JWTs (identified by the typ value actor-proof+jwt) from artifacts that carry current-request proof-of-possession semantics under [RFC7800], [RFC9449], or [RFC8705].¶

14.3. Actor Key Resolution and Trust

Proof validation is meaningful only if the recipient resolves actor verification keys through sources it trusts.¶

Trust establishment requirements:¶

• A recipient MUST establish its trusted actor-key sources before relying on actor_proofs. Trust MUST be established through explicit pre-configuration, bilateral agreement, federation policy, or another explicit trust framework.¶

• A recipient MUST NOT treat the presence of a syntactically valid signed proof as sufficient grounds to trust the key that signed it.¶

• A recipient MUST determine that a proof's (act.iss, act.sub) pair is within the scope of a trusted actor-key source before performing any network retrieval keyed by the proof's content, and MUST NOT dereference key references supplied by the proof itself (such as jku or x5u header parameters) outside a pre-established trust framework, per [RFC8725].¶

• Key resolution and trust evaluation use the (act.iss, act.sub) pair. The bare proof iss string MUST NOT be the sole resolution index; actor identifiers are namespaced by act.iss, and identical act.sub strings under different namespace authorities are different actors.¶

This document profiles the following resolution patterns; a deployment may support any subset:¶

• Pre-established keys. The actor's verification keys are registered with the recipient or its trust framework in advance, for example as the JWKS of a registered OAuth client at the authorization server, or as locally configured keys at a resource server. This pattern is self-contained and provides the strongest independence properties. Attestation-based client authentication [I-D.ietf-oauth-attestation-based-client-auth] provides an interoperable way to establish such keys, with an attester vouching for the actor's key binding.¶

• Receipt-attested presenter keys. When the sibling receipt for a hop carries the historical presenter binding cnf defined in [I-D.mcguinness-oauth-actor-receipts], and the deployment binds proof signing keys to presenter keys, the recipient MAY verify the proof signature against the key identified by the aligned receipt's cnf. This pattern requires no separate key registry, but the key attestation derives from the receipt issuer: proofs verified this way provide no independence from that issuer. In particular, at the newest hop, whose receipt is signed by the current outer token issuer in the originating-issuance case, receipt-attested key resolution provides no anti-fabrication protection against that issuer.¶

• Federation and workload identity systems. Deployment-defined resolution through workload identity or federation infrastructure. The trust and freshness properties are those of the underlying system; this document does not profile them. OAuth SPIFFE client authentication [I-D.ietf-oauth-spiffe-client-auth] is an example of workload-identity key establishment that deployments can apply to actor signing keys.¶

The independence requirement follows from the threat model: for the anti-fabrication property against a given issuer to hold at a hop, the recipient MUST resolve the actor's key for that hop through a source independent of that issuer.¶

Actor keys, like receipt-issuer trust, are not transitive: each proof is validated against the recipient's own actor-key sources, independent of the outer token's issuer and of neighboring proofs. If any proof in the presented actor_proofs array is signed by a key the recipient cannot resolve through a trusted source, the recipient MUST reject the proof chain for the purposes of this profile.¶

14.4. Proof-to-Token Binding Limits

A proof is signed before the token that carries it exists. It therefore names the delegation context (subject, actor, target binding, time window, unique jti), not a token instance. Within a proof's validity window, a party holding the proof, including the issuer it was legitimately submitted to, can embed it in a different outer token with the same subject, the same actor chain position, and a target within the proof's binding, and no signature check detects the reuse. The actor's non-repudiation statement is scoped accordingly: the actor authorized this delegation relationship toward this target within this window, not this specific token issuance.¶

Available bindings, strongest first:¶

• Receipts composition. When the token also carries receipts, the receipt chain's origin_jti anchoring and strict-mode rules in [I-D.mcguinness-oauth-actor-receipts] bind the token instance, and proof_jti (Section 9.6) binds the proof chain to that anchored receipt chain. A re-embedded proof would require a matching fabricated receipt, which the receipt trust model prevents for issuers that cannot sign trusted receipts. This is the RECOMMENDED posture for deployments that require instance binding.¶

• Provisioned origin_jti. When the issuance flow provides the prospective outer-token jti to the actor before signing, actor_proofs[0].origin_jti binds the proof to that token instance directly, per step 9 of Section 10.¶

• jti uniqueness monitoring. Recipients and audit pipelines MAY track proof jti values and flag the same proof appearing in more than one outer-token instance. This is stateful and deployment-specific; this document does not define the mechanism.¶

• Short exp. Bounds the re-embedding window unconditionally, at the cost of shorter delegated-session lifetimes (Section 7.2).¶

Inner proofs have no independent binding to the current token; they are bound to their newer neighbor through prh and inherit whatever binding actor_proofs[0] has.¶

14.5. Hash Algorithm Agility

The prh and prh_alg agility rules of [I-D.mcguinness-oauth-actor-receipts] apply to proof chains unchanged: one algorithm per chain, whole-chain migration only, no rehashing of inherited artifacts, and rejection of mixed or unsupported algorithms. The proof chain's algorithm is independent of the receipt chain's algorithm in the same token.¶

14.6. Downgrade by Omission

This profile's anti-fabrication property is conditional on enforcement. A compromised issuer that wants to fabricate actor participation does not submit a forged proof, which would fail signature validation; it omits actor_proofs entirely. A recipient that accepts delegated tokens without proofs has no protection from this profile against that issuer.¶

Accordingly:¶

• Resource servers that rely on actor-signed evidence MUST require proofs, through actor_proofs_required (and actor_proofs_complete_required where inner hops matter) or equivalent local policy, for the delegated tokens they accept.¶

• Recipients SHOULD treat the absence of proofs from an issuer that advertises actor_proofs_supported: true, for a resource that requires them, as a signal warranting scrutiny rather than silent acceptance.¶

Issuers cannot protect recipients that do not ask; the enforcement locus of this profile is the recipient.¶

14.7. Actor Key Compromise

If an actor's signing key is compromised, previously signed proofs and newly forged proofs under that key are indistinguishable. The primary remediation is to remove the compromised key or actor from the recipient's trusted actor-key sources; once removed, consumers will reject all proofs attributed to that actor's key regardless of content.¶

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

14.8. Proof Chain Size

Each proof is a full signed JWT, and the chain grows linearly with delegation depth. A typical signed proof is 400 to 800 bytes after JWS compact serialization and base64url encoding, comparable to a receipt. A token carrying both companions in belt-and-suspenders mode carries roughly twice the per-hop artifact bytes of either companion alone. Deployments SHOULD verify that the outer token plus its companion arrays fits within the header-size budget of every component on the request path; the receipts companion's size guidance applies, and introspection delivery avoids header pressure for bearer-token clients.¶

14.9. Proof Freshness and Replay

Proofs are historical attestations of hop-time consent. They MAY outlive the validity period of the outer token they were originally embedded in, and MAY be carried forward across reissuance and refresh as long as their exp permits.¶

• Proofs attest participation and target consent at signing time; they do not assert that the represented delegation is still active or that the actor would consent today.¶

• Runtime policy evaluation, including current authorization and current revocation state, is separate from proof validation.¶

• Replay of an entire token plus its proofs is governed by the outer token's replay characteristics. Re-embedding of an individual proof into a different token is a distinct threat, bounded as described in Section 14.4.¶

Deployments needing freshness signals beyond proof exp MUST obtain those signals from the authorization server via introspection ([RFC7662]), fresh token issuance, or another mechanism outside the scope of this profile.¶

14.10. Sibling Revocation Independence

A proof does not inherit revocation or trust state from its sibling receipt. When a deployment removes a receipt issuer from its trusted-issuer set under [I-D.mcguinness-oauth-actor-receipts], proofs for the same hops remain valid under their own actor keys, and vice versa. Recipients that require issuer-side revocation semantics for a hop MUST require receipt validation alongside proof validation rather than relying on the proof alone; the sibling references of Section 9.6 identify the receipt whose trust state applies to a hop.¶

15.1. What Proofs Disclose

Proofs can expose, to any party that receives the token or introspection response:¶

• cryptographically transferable evidence of each covered actor's participation, retained and provable beyond token lifetime;¶

• actor key identifiers (kid values and resolved public keys), which are stable correlation handles across proofs, flows, and services;¶

• target bindings (target.aud, target.resource), which may reveal internal audience and resource identifiers a deployment would not otherwise expose to all recipients;¶

• the delegation graph of a workflow, tied together by prh chain hashes;¶

• subject re-expression patterns across namespaces, as with receipts.¶

15.2. Minimization

Deployments SHOULD minimize proof disclosure when actor-signed evidence is not required:¶

• Issuers and introspection servers MAY withhold actor_proofs entirely when policy does not permit disclosure; a strict subset of an existing array cannot validate (Section 10.4), so disclosure of an existing chain is all-or-nothing.¶

• Actors SHOULD omit target.resource when audience-level consent is sufficient, since resource URIs are often the most deployment-revealing values in a proof.¶

• Resource servers SHOULD require actor proofs only when they materially improve authorization, audit, or risk controls.¶

• Deployments SHOULD prefer per-resource-server policy on proof requirements over blanket inclusion in every token.¶

• Deployments SHOULD evaluate actor key lifetimes with correlation in mind: long-lived actor keys make every proof signed under them linkable.¶

15.3. Selective Disclosure

This profile does not define a per-claim selective-disclosure mechanism for proofs: chain integrity requires byte-for-byte preservation of each proof JWT, so selective omission of individual claims within a proof would break the chain. Selective disclosure is coarse-grained, exactly as for receipts: issuance-time partial coverage of outermost hops, or whole-array omission.¶

15.4. Audience Restriction

A proof travels with the outer token to whichever audiences the outer token serves; proofs have no independent audience scoping (Section 7.2). Deployments needing audience-specific disclosure constraints SHOULD partition proof issuance by audience at issuance time rather than relying on proof-level audience restriction, which this profile does not provide.¶

15.5. Detached Provability

Proofs support detached verification by any party that can resolve the actor's public key, including parties the actor and issuer did not anticipate. Unlike receipts, whose evidentiary weight depends on the verifier trusting the receipt issuer, a proof's signature is self-contained evidence of the actor's participation. Deployments SHOULD treat proof-bearing tokens as carrying durable, transferable participation evidence to anywhere the token reaches, and SHOULD scope token distribution and retention accordingly.¶

16.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-proof+jwt¶

• Required parameters: N/A¶

• Optional parameters: N/A¶

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

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

• Interoperability considerations: N/A¶

• Published specification: This document¶

• Applications that use this media type: Applications that create, exchange, or validate OAuth Actor-Signed Hop Proofs.¶

• 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-proof+jwt used by this document is the media type subtype name without the application/ prefix, following common JWT typing practice.¶

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

• Claim Description: Array of actor-signed hop proofs providing delegation participation evidence¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

• Claim Name: actor_proofs_complete¶

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

• Change Controller: IESG¶

• Specification Document(s): This document¶

• Claim Name: target¶

• Claim Description: Target binding (audience and resource constraints) authorized by the signer of an Actor Proof JWT¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

• Claim Name: receipt_jti¶

• Claim Description: jti of the sibling Actor Receipt JWT created for the same delegation hop as an Actor Proof JWT¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

• Claim Name: proof_jti¶

• Claim Description: jti of the sibling Actor Proof JWT validated for the same delegation hop as an Actor Receipt JWT¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

This document reuses the prh, prh_alg, origin_jti, and sub_iss claims registered by [I-D.mcguinness-oauth-actor-receipts], with the semantics defined there, applied to Actor Proof JWTs as profiled in this document. This document requests that IANA add this document to the Specification Document(s) entries for those four registrations, and requests that their Claim Description entries be updated to cover both artifact types:¶

• prh: Base64url-encoded hash of the immediately preceding (older) entry in a chained array of delegation-evidence JWTs (Actor Receipts, Actor Proofs, or companion event artifacts)¶

• prh_alg: Hash algorithm identifier (from the IANA Named Information Hash Algorithm Registry) naming the algorithm used to compute prh in a delegation-evidence JWT¶

• origin_jti: The jti of the outer token associated with the hop at which an Actor Receipt or Actor Proof JWT was created¶

• sub_iss: Issuer or namespace authority for the subject in an Actor Receipt or Actor Proof JWT¶

16.3. OAuth Parameters Registration

This document requests registration of the following parameter in the "OAuth Parameters" registry established by [RFC6749]:¶

• Parameter name: actor_proof¶

• Parameter usage location: token request¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

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

• Metadata Description: Indicates support for accepting, validating, embedding, preserving, and extending actor-signed hop proofs¶

• Change Controller: IESG¶

• Specification Document(s): This document¶

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

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

• Change Controller: IESG¶

• Specification Document(s): This document¶

• Metadata Name: actor_proofs_complete_required¶

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

• Change Controller: IESG¶

• Specification Document(s): This document¶

16.6. OAuth Token Introspection Response Registration

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

• Name: actor_proofs¶

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

• Change Controller: IESG¶

• Specification Document(s): This document¶

• Name: actor_proofs_complete¶

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

• Change Controller: IESG¶

• Specification Document(s): This document¶

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

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

[RFC8707]

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

[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-08, 2 March 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-transaction-tokens-08>.

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

McGuinness, K., "OAuth Actor Profile for Delegation", 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.mcguinness-oauth-actor-receipts]

McGuinness, K., "OAuth Actor Receipts for Delegation Provenance", Work in Progress, Internet-Draft, draft-mcguinness-oauth-actor-receipts-00, 4 July 2026, <https://datatracker.ietf.org/doc/html/draft-mcguinness-oauth-actor-receipts-00>.

[RFC2119]

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

18.2. Informative References

[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.jiang-oauth-intent-admission]

Jiang, Y., Lun, L., Song, Y., and F. Liu, "Intent Admission Assertions for Agentic Systems", Work in Progress, Internet-Draft, draft-jiang-oauth-intent-admission-00, 23 June 2026, <https://datatracker.ietf.org/doc/html/draft-jiang-oauth-intent-admission-00>.

[I-D.ietf-oauth-attestation-based-client-auth]

Looker, T., Bastian, P., and C. Bormann, "OAuth 2.0 Attestation-Based Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-attestation-based-client-auth-09, 25 May 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-attestation-based-client-auth-09>.

[I-D.ietf-oauth-spiffe-client-auth]

Schwenkschuster, A., Kasselman, P., Rose, S., Thorgersen, S., and N. Cam-Winget, "OAuth SPIFFE Client Authentication", Work in Progress, Internet-Draft, draft-ietf-oauth-spiffe-client-auth-02, 15 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-spiffe-client-auth-02>.

A.1. Example: Two-Hop Delegation Chain with Sibling Receipts

The outer token carries both companions:¶

{
  "jti": "e8f4a2d6-3b1c-4d7e-9f5a-0c2b4d6e8f0a",
  "iss": "https://as.travel-provider.example",
  "aud": "https://api.travel-provider.example",
  "sub": "https://idp.enterprise.example/users/alice",
  "act": {
    "sub": "https://tools.example.com/booking-tool",
    "iss": "https://as.travel-provider.example",
    "sub_profile": "service",
    "act": {
      "sub": "https://agents.example.com/travel-assistant",
      "iss": "https://as.enterprise.example",
      "sub_profile": "ai_agent"
    }
  },
  "cnf": {
    "jkt": "ToolJKT"
  },
  "actor_receipts": [
    "<receipt-0>",
    "<receipt-1>"
  ],
  "actor_receipts_complete": true,
  "actor_proofs": [
    "<proof-0>",
    "<proof-1>"
  ],
  "actor_proofs_complete": true
}

actor_proofs[0] was signed by the booking tool when it requested the exchange at the travel-provider AS, before that AS issued the outer token:¶

{
  "iss": "https://tools.example.com/booking-tool",
  "sub": "https://idp.enterprise.example/users/alice",
  "act": {
    "sub": "https://tools.example.com/booking-tool",
    "iss": "https://as.travel-provider.example",
    "sub_profile": "service"
  },
  "target": {
    "aud": ["https://api.travel-provider.example"]
  },
  "prh": "Xm3VqLr8pTzKNdY5W2uEbc4gHf7jAsQ9R6vBnC1oD0k",
  "iat": 1776745180,
  "exp": 1776832000,
  "jti": "5f2e8d91-4a6b-4c3d-8e2f-1a9b8c7d6e5f"
}

actor_proofs[1] was signed earlier by the AI agent when the enterprise AS added it as the first actor hop:¶

{
  "iss": "https://agents.example.com/travel-assistant",
  "sub": "https://idp.enterprise.example/users/alice",
  "sub_iss": "https://idp.enterprise.example",
  "act": {
    "sub": "https://agents.example.com/travel-assistant",
    "iss": "https://as.enterprise.example",
    "sub_profile": "ai_agent"
  },
  "target": {
    "aud": ["https://as.travel-provider.example"]
  },
  "iat": 1776741580,
  "exp": 1776832000,
  "jti": "7a1c9e42-3b5d-4f6a-9c8e-2d4f6a8b0c1e"
}

The sibling receipts follow the same construction as the examples of [I-D.mcguinness-oauth-actor-receipts], with the proof_jti claim defined in Section 9.6 included at receipt creation. Because these receipts carry proof_jti, they are different byte strings from the receipts shown in that document's examples: they carry their own jti values, and the newest receipt's prh differs because it hashes a different older receipt. The newest receipt, signed by the travel-provider AS, carries:¶

{
  "iss": "https://as.travel-provider.example",
  "sub": "https://idp.enterprise.example/users/alice",
  "act": {
    "sub": "https://tools.example.com/booking-tool",
    "iss": "https://as.travel-provider.example",
    "sub_profile": "service"
  },
  "cnf": {
    "jkt": "ToolJKT"
  },
  "proof_jti": "5f2e8d91-4a6b-4c3d-8e2f-1a9b8c7d6e5f",
  "prh": "K9mPvXq2LwTnR7dYcE5uHb8jZa4gFs6iOk1rC3xW0eA",
  "iat": 1776745200,
  "exp": 1776832000,
  "jti": "b7d1f3a5-8c2e-4a6b-9d0f-1e3a5c7b9d1f",
  "origin_jti": "e8f4a2d6-3b1c-4d7e-9f5a-0c2b4d6e8f0a"
}

This example illustrates the properties this profile adds. The outer token's aud is within actor_proofs[0].target.aud, so the current audience is actor-authorized. actor_proofs[1].target.aud names the travel-provider AS, the target the agent authorized for its own hop; per step 9 of Section 10 that historical binding is not evaluated against the current outer token's audience. The receipt's proof_jti binds the proof chain to the receipt chain, whose origin_jti anchors the current token instance; a compromised issuer re-embedding <proof-0> in a different token could not produce a matching trusted receipt. The proofs in this example are signed by the keys whose thumbprints appear as the historical presenter bindings in the sibling receipts (ToolJKT, AgentJKT), illustrating receipt-attested key resolution; per Section 14.3, a recipient relying on that pattern gains no anti-fabrication protection against the receipt issuer itself at that hop.¶

A.2. Example: Proofs-Only Partial Coverage

Suppose the enterprise AS has not yet deployed proof support, so no proof exists for the AI-agent hop, and the travel-provider AS accepts a proof from the booking tool when it adds the tool as the new outermost actor. The resulting access token carries a one-element proof chain and no receipts:¶

{
  "jti": "a4c8e2f6-1b3d-4e5f-9a7c-8d6e4f2a0b1c",
  "iss": "https://as.travel-provider.example",
  "aud": "https://api.travel-provider.example",
  "sub": "https://idp.enterprise.example/users/alice",
  "act": {
    "sub": "https://tools.example.com/booking-tool",
    "iss": "https://as.travel-provider.example",
    "sub_profile": "service",
    "act": {
      "sub": "https://agents.example.com/travel-assistant",
      "iss": "https://as.enterprise.example",
      "sub_profile": "ai_agent"
    }
  },
  "cnf": {
    "jkt": "ToolJKT"
  },
  "actor_proofs": [
    "<proof-0>"
  ],
  "actor_proofs_complete": false
}

The single proof covers the outermost hop:¶

{
  "iss": "https://tools.example.com/booking-tool",
  "sub": "https://idp.enterprise.example/users/alice",
  "act": {
    "sub": "https://tools.example.com/booking-tool",
    "iss": "https://as.travel-provider.example",
    "sub_profile": "service"
  },
  "target": {
    "aud": ["https://api.travel-provider.example"],
    "resource": ["https://api.travel-provider.example/bookings"]
  },
  "iat": 1776745180,
  "exp": 1776832000,
  "jti": "9c3b7f15-6d2e-4a8b-b1f4-e5a7c9d1b3f6"
}

prh is omitted because this is a single-element chain. actor_proofs_complete: false signals to recipients that the inner AI-agent hop carries no actor-signed evidence. Resource servers that set actor_proofs_complete_required: true in their Protected Resource Metadata reject this token; resource servers that accept partial coverage validate the booking tool's signed participation and target consent, and treat the agent hop as carried solely by the visible act chain. Because no receipts are present, the proof chain carries no outer-token instance binding; per Section 14.4, a recipient requiring instance binding would require the receipts companion or a provisioned origin_jti.¶