Agent Passport System (APS): Cryptographic Identity, Faceted Authority Attenuation, and Governance for AI Agent Systems

Internet-Draft	APS	July 2026
Pidlisnyi	Expires 5 January 2027	[Page]

Abstract

This document specifies the Agent Passport System (APS), a protocol for cryptographic identity, faceted authority attenuation, and governance for AI agent systems. APS introduces Ed25519-based agent passports, scoped delegation chains with monotonic narrowing across seven constraint dimensions (scope, spend, depth, time, reputation, values floor, reversibility), cascade revocation, a three-signature policy chain (intent, evaluation, receipt), and signed receipts that record what an agent declared, what a policy engine decided, and what an enforcement boundary observed. Authority is modeled as an element of a product lattice, and delegation is a monotone function on that lattice, ensuring that delegated capabilities can only be attenuated, never amplified. APS also defines key rotation with identity continuity, and recognizes institutional governance primitives (charters, offices, approval policies, federation) that compose with the delegation lattice; their normative specification is companion work. The protocol is intended to complement current AI agent infrastructure, including MCP and A2A, with cryptographic identity, delegated authority, and verifiable enforcement evidence. A protocol binding is specified for MCP. Reference implementations are available in TypeScript and Python under Apache-2.0; see the Implementation Status section.¶

Beyond the authority core, this document also specifies: an external correlation form for cross-ecosystem record matching; key resolution for external and evidence signers; attestation provenance tiers; signed revocation evidence with cascade-completion records; a two-phase execution gate model; supporting signed record classes for boundary decisions, composition checks, and sampled readback; a receipt-profile mechanism illustrated by a trust-domain-gated regulated-action profile; a word-handle digest presentation; and a binding for OAuth identity-assertion authorization grants. The temporal dimension is specified as an absolute expiry bound, spend as denominated, and verification claims are expressed at named levels stating what each proves and what it does not.¶

2. Identity Scheme

2.1. Agent Passport

Each agent in APS possesses an Agent Passport: a signed document binding an Ed25519 public key to an agent identifier, name, owner, and expiry time. The passport is self-signed by the agent's private key, establishing cryptographic identity without a central authority.¶

2.2. DID Scheme

APS defines a DID method "did:aps" using multibase-encoded Ed25519 public keys: did:aps:z<base58btc-encoded-public-key>.¶

2.3. Key Rotation and Identity Continuity

An agent MAY rotate its signing key. Rotation produces a new Ed25519 key pair while preserving the agent's identity: the agent identifier and the passport's binding to an owner persist across the rotation. The agent's DID document records the rotation, so that a verifier resolving the identity can observe the key history.¶

A rotated key carries a retirement time. A retired key remains valid for verifying signatures produced before its retirement time, and MUST NOT be accepted for signatures produced after it. This preserves the verifiability of historical receipts and delegations signed under a key that has since been rotated out.¶

The protocol distinguishes a planned rotation, performed on a schedule or policy, from an emergency rotation, performed in response to suspected key compromise. The two differ in operational urgency and in how aggressively a verifier should treat signatures near the retirement boundary; they do not differ in the cryptographic mechanism.¶

Determining whether a signature was produced before or after a key's retirement time requires a trusted notion of when the signature was made. This document does not define a trusted timestamping service. A verifier evaluates retired-key validity against the signed timestamps carried by the receipt or delegation (for example, issued_at) together with any profile-defined trusted-timestamping or log-inclusion mechanism; absent such a mechanism, a verifier MUST treat signatures near the retirement boundary as it would any other claim that depends on issuer-asserted time.¶

2.4. Key Resolution for External and Evidence Signers

Section 2.3 governs an agent's own keys. A verifier also encounters signatures from parties outside the delegation chain: evidence issuers, counterparty systems, and attesting services. For these external signers this document specifies a resolution model rather than a registry.¶

An external signer identifier MAY be hash-bound to its subject: the identifier carries a digest of the subject identity (for example, a DID whose method-specific identifier is the SHA-256 of a server identity), and the resolver checks the presented subject against that digest before any key material is trusted. A hash-bound identifier is a binding, not a locator: key material located through the subject's own endpoint is accepted only when the subject hashes to the identifier, which closes the class of confusion in which one tenant's key material is resolved under another tenant's identifier. A hash-bound locator presented without the subject it binds MUST be rejected.¶

Published key material MAY carry per-key validity windows. Key selection is gated on the artifact's own signed issuance time, evaluated against each key's window; a verifier MUST NOT select whichever key is current at verification time. A key set in which a key identifier is duplicated is malformed, and the duplication is an authority failure for the set as a whole, not a per-key condition.¶

Resolution outcomes preserve failure structure. At minimum a resolver distinguishes: resolved; subject or key not found; ambiguous (including duplicate key identifiers); structurally malformed key material; transport unreachability; and an unsupported identifier scheme. Resolution is fail-closed by default. A deployment MAY adopt a fail-open policy for transport unreachability only; malformed key material that loads but is wrong is not a transient transport condition and MUST fail closed even under such a policy. A resolution outcome degraded by a fail-open policy MUST NOT be treated as a positive verification, consistent with Section 5.5.¶

2.5. Attestation Provenance and Composition

Identity claims about an agent arrive with different evidentiary weight, and a protocol that flattens them invites over-trust. APS distinguishes four provenance tiers for attested signals: observed (the receiving infrastructure itself recorded the signal, such as transport characteristics at connection termination); infrastructure-attested (a runtime or sandbox gateway signed a claim about the agent's execution environment); provider-attested (a third-party provider confirmed a claim, such as an account or tenant relationship); and self-declared (the agent asserts the claim, unverified).¶

In the reference implementation an attested signal carries: a signal key; a digest of the signal value rather than the raw value; its provenance tier; a verification status distinguishing cryptographically verified, observed without cryptographic proof, declared and unverified, and verification attempted but failed; a stability class indicating how long the signal remains constant; the attesting party; and issuance and expiry times. A signal's provenance tier and its verification status are independent axes: a provider-attested signal whose signature was never checked remains at declared, and a verifier MUST NOT infer verification from tier.¶

Two attestation record shapes are published with the reference implementation. A runtime attestation is a signed claim by an attesting infrastructure party about the agent's execution environment, bound by challenge-response: it carries a nonce supplied by the requesting issuer and a digest of the subject public key, so that the attestation cannot be replayed for a different request or a different key. A provider attestation is a signed or verifiable confirmation by a third-party provider of a subject relationship, carrying a digest of the subject identifier and the verification method used. This section defines the tier and status terminology that profiles import; it does not define a general attested-signal wire format and imposes no verifier behavior beyond the tier-independence rule above. The record shapes are illustrated by the reference implementation. How a deployment weighs, combines, or scores composed attestations is deployment policy and is not specified by this document.¶

3. Delegation and Authority Attenuation

3.1. Faceted Authority Attenuation

Agent authority is modeled as an element of a product lattice A = D_1 x D_2 x ... x D_7, where each D_k is a bounded partially ordered set. The seven dimensions are: Scope (power set, subset ordering), Spend (non-negative reals within a declared unit), Depth (naturals), Time (absolute expiry instant), Reputation (the closed interval from 0 to 100), Values (a values floor, defined below), Reversibility ({Tentative, Compensable, Irreversible}).¶

The Values dimension is modeled as a values floor: a finite set of attested principle identifiers required of the agent by the delegation. Its ordering is by set inclusion, with narrowing in the superset direction. A delegation MUST preserve every principle identifier required by any ancestor and MAY add further required identifiers; it MUST NOT remove an ancestor-required identifier. Formally, if V_parent is the parent's required-principle set and V_child is the child's, a valid delegation requires V_parent is a subset of V_child. A larger values floor is a narrower authority position: more required principles constrain the agent further. The Values dimension orders sets of principle identifiers; it does not order principles against one another, and this document does not define the meaning of any individual principle identifier. The Reputation dimension is likewise carried without interpretation: this document does not define how reputation values are produced, updated, or compared across deployments beyond the interval ordering.¶

The Time dimension is an absolute expiry instant, not a relative duration. A delegation carries an expiry as an RFC 3339 [RFC3339] UTC timestamp; the component ordering is by instant, and an earlier expiry is a narrower authority position. A child delegation's expiry MUST be less than or equal to its parent's expiry. The child's expiry is fixed at issuance as an absolute instant. It MUST NOT be represented in the signed delegation as a duration, and MUST NOT be re-derived from a duration against any later clock reading: two relative durations issued at different times are incomparable without their issuance instants, and re-basing a duration on a later reading can extend a child's effective lifetime beyond its parent's, violating monotone narrowing. An implementation that accepts a duration as input MUST convert it to an absolute expiry at issuance, bounded by the parent's expiry, before signing. A temporal value that cannot be parsed as a valid RFC 3339 instant MUST invalidate the delegation that carries it; an implementation MUST NOT substitute a default in place of an unparseable expiry.¶

Spend amounts are denominated. The Spend component ordering is defined only between amounts in the same unit: amounts in different units are incomparable under the lattice ordering, and this document defines no conversion between units. Once any ancestor in a delegation chain carries a spend dimension, a descendant MUST NOT change the unit at narrowing. A child MAY introduce a spend unit under an ancestor that carries no spend dimension; introducing a constraint where none existed is narrowing, not conversion. The unit in effect for a child, whether declared by the child or inherited from its parent, MUST be resolved at issuance and carried in the signed delegation; an implementation MUST NOT sign a child whose spend limit is silently reinterpreted under a different unit at a later hop.¶

The Reputation dimension is an authority ceiling carried by the delegation: a descendant MAY lower it and MUST NOT raise it. How reputation values are computed or updated is outside this document's scope; the dimension bounds authority, it does not measure conduct.¶

Delegation is a monotone function on this lattice: for any delegation d with parent p, auth(d) <= auth(p) in the product ordering. Authority narrows monotonically along any delegation chain across all seven dimensions simultaneously. The dimensions do not all narrow in the same set-theoretic direction: Scope narrows under subset ordering while the Values floor narrows under superset ordering. Both are valid component orderings, and the monotone-narrowing property holds across the product because the product ordering is componentwise. The componentwise argument above is self-contained; the fuller lattice formalization is developed in [APS-NARROWING] and [APS-FACETED].¶

3.2. Cascade Revocation

Any delegation MAY be revoked by its issuer. Revocation MUST initiate a cascade to all transitive descendants; a cascade is complete only when the cascade-completion record of Section 3.2.1 has been emitted. Revocation is irreversible. A cascade is distinguishable as complete only through the cascade-completion record of Section 3.2.1. The enforcement gateway MUST recheck revocation status at execution time, not only at approval time.¶

3.2.1. Revocation Evidence

Section 3.2 specifies revocation behavior. Behavior alone leaves a verifier dependent on the revoking system's current state; this section specifies the evidence that makes revocation history verifiable from records. The model separates two questions that MUST NOT collapse into one mutable lookup: whether a delegation is currently valid, answerable from state, and whether and why a revocation occurred, verifiable from signed records.¶

A revocation MUST produce a signed revocation record carrying, at minimum: the revoked delegation's identity; the revocation time, inside the signed content; a reference to the revoking authority; and a machine-readable reason code, with optional free-text detail. A revocation derived from a cascade MUST additionally carry a reference to the originating revocation, so that a verifier can reconstruct from the records why a descendant delegation died. A cascade carries a transaction identity shared by every record it produces.¶

Cascade completeness (INV-4, Section 3.3) is asserted by Section 3.2 but is not verifiable from individual revocation records: a partially revoked subtree is indistinguishable, record by record, from a completed one. A cascade therefore concludes with a signed cascade-completion record, carrying the same transaction identity, emitted after the last descendant's revocation is persistent. Its presence lets a verifier distinguish a fully closed subtree from a revocation in progress from the records alone; its absence means in progress, and a verifier MUST NOT read an incomplete record set as a closed subtree.¶

3.3. Core Invariants

The protocol specifies eight invariants: INV-1 (Identity Verifiability), INV-2 (Scope Monotonic Narrowing), INV-3 (Spend Limit Narrowing), INV-4 (Cascade Completeness), INV-5 (Revocation Irreversibility), INV-6 (Intent-Receipt Binding), INV-7 (Authority Attribution Completeness), INV-8 (Signature Integrity). INV-6 is elaborated by the signed receipt layer specified in Section 5. The record-level verifiability of INV-4 is specified in Section 3.2.1. INV-7 (Authority Attribution Completeness) is the requirement that every governed action is attributable to an acting agent, an authority path, and a receipt context; it does not concern contribution-attribution or beneficiary-attribution, which are out of scope for this document (see Attribution Axes and Scope). INV-4 is asserted by Section 3.2 and made verifiable from records by the cascade-completion record of Section 3.2.1.¶

INV-2, INV-3, and INV-8 are enforced at issuance, not only at verification. An issuer minting a child delegation MUST verify the parent delegation's signature and temporal validity before signing the child, and MUST refuse to issue under an expired, not-yet-valid, or revoked parent. Issuance from an expired parent MUST fail at the issuer; it MUST NOT produce a delegation whose invalidity is left for a later verifier to discover. Verification-time checking remains required (Section 3.2), but a conforming issuer does not rely on it as the sole enforcement point: a delegation that was invalid at issuance never becomes valid later.¶

4. Policy Chain

APS defines a three-signature policy chain: ActionIntent (agent declares intended action), PolicyDecision (policy engine evaluates with verdict permit, deny, or narrow, where a narrow verdict grants the action at reduced authority and carries the constraints applied), PolicyReceipt (enforcement gateway records execution result). The policy engine splits into a deterministic gate (scope, signature, revocation, authority path, spend) and an advisory evaluation path (deception, proportionality). The structure and verification of the signed records produced at each stage are specified in Section 5.¶

The spend check in the deterministic gate compares amounts only within a declared unit. When the action's declared unit and the governing delegation's declared unit differ, the gate MUST deny; it MUST NOT compare raw numeric amounts across units, and it MUST NOT apply a conversion. When the action does not declare a unit, the amount is evaluated under the delegation's resolved unit (Section 3.1); this is a defined interpretation rule, not a verifier assumption. Deployments handling monetary spend SHOULD require actions to declare their unit, and a profile MAY require the gate to deny when it is undeclared.¶

A delegation's spend value is a limit fixed at issuance. A signed delegation is immutable and cannot carry mutable state; the cumulative amount spent under a delegation is state held at the enforcement boundary, associated with the delegation, and is not a field whose mutation the signature covers. The enforcement discipline is check-before-effect, record-after-settlement: before permitting an effect, the boundary MUST verify that the proposed amount plus the recorded cumulative total does not exceed the signed limit, and after settlement it records the settled amount. INV-3 (Section 3.3) constrains the signed limits along a chain; cumulative enforcement against those limits is an enforcement-boundary function.¶

4.1. Action Reference Computation

Each action in the policy chain is identified by a deterministic action reference (action_ref) that serves as a cross-engine correlation anchor. The action_ref is computed as:¶

action_ref = SHA-256(canonicalize(input_object))¶

where input_object is a JSON object with exactly four fields:¶

agentId: The DID of the acting agent (e.g., "did:aps:z6Mk..."), in the canonical string form defined by its DID method. For did:aps (Section 2.2) this is the full multibase-encoded form with no abbreviation.¶
actionType: The tool or action identifier string (e.g., "commerce_preflight").¶
scopeRequired: An array of scope strings required for this action (e.g., ["commerce:read", "commerce:write"]). Each scope string MUST be in Unicode Normalization Form C (NFC). Implementations MUST sort the array by Unicode code point before canonicalization. Scope strings are compared and sorted as-is; this document does not define case folding, and scope strings that differ only in case are distinct.¶
timestamp: An RFC 3339 UTC timestamp at exactly second precision, with the literal "Z" zone designator and no fractional-seconds component (e.g., "2026-04-08T12:00:00Z"). Implementations MUST format the timestamp to second precision before canonicalization; a timestamp carrying a fractional-seconds component is non-conforming.¶

The canonicalize function MUST follow RFC 8785 (JSON Canonicalization Scheme) [RFC8785]. The SHA-256 hash is computed over the UTF-8 encoding of the canonicalized JSON string. The action_ref is the lowercase hexadecimal encoding of the digest.¶

The action_ref MUST be deterministic: two input objects that are equal field-by-field, with each field in the canonical form specified above, MUST produce the same hash regardless of implementation language, JSON library, or field insertion order. Cross-engine correlation holds only when both engines reach the computation with byte-equal canonical field values; the field-form rules above exist to make that achievable across independent implementations.¶

Implementations MUST NOT include additional fields in the input object. Implementations MUST NOT apply any transformation to field values beyond the NFC normalization of scopeRequired strings and the code-point sorting of the scopeRequired array specified above.¶

The rules of this section define the native APS action_ref: the correlation anchor used within the APS policy chain and receipt layer. Section 4.2 defines a second, distinct correlation key with a different preimage for correlation at ecosystem boundaries. The prohibitions above apply to the native input object; they do not admit the external form of Section 4.2 as a variant of the native computation, and a value computed under one form MUST NOT be presented as the other.¶

4.2. External Correlation Form

For correlating APS-governed actions with records produced by systems outside an APS deployment, this document defines a second deterministic reference, the external action reference, identified by the label "action-ref-v1-jcs-sha256":¶

external_action_ref =
    lowercase-hex(SHA-256(canonicalize(input_object)))

where canonicalize is RFC 8785 [RFC8785], the hash is computed over the UTF-8 encoding of the canonicalized JSON, and input_object is a JSON object with exactly four fields, named in snake_case:¶

action_type: The action identifier string.¶
agent_id: The acting agent's identifier string, in the form the correlating ecosystem uses. Unlike the native form's agentId, this document does not constrain agent_id to a DID method's canonical form.¶
scope: A single scope string. Unlike the native form's scopeRequired, the external form carries exactly one scope string, not an array.¶
timestamp: An RFC 3339 UTC timestamp at exactly millisecond precision: three fractional-second digits and the literal "Z" designator (e.g., "2026-04-08T12:00:00.000Z"). The timestamp is hashed as the byte sequence supplied. An implementation MUST reject a timestamp that does not match this shape; it MUST NOT coerce, truncate, extend, or renormalize a non-conforming value.¶

Field values in the external form are hashed as supplied. The external form applies none of the native form's field transformations: no Unicode normalization and no array sorting, since the scope field is a single string.¶

The external form exists for cross-ecosystem byte parity: independent implementations outside an APS deployment compute this key from their own records, and agreement with the value carried in or derived from an APS receipt correlates the two without prior coordination. The native form of Section 4.1 remains the correlation anchor within the APS policy chain. The two forms differ in field naming, field forms, scope arity, and timestamp precision, and produce unrelated digest values for the same underlying action.¶

4.3. Two-Phase Execution

Section 3.2 requires revocation to be rechecked at execution time, not only at approval time, and the Completion Receipt (Section 5.3.1) closes an authorize-then-complete pair. Both presuppose a gate model with two distinct enforcement moments; this section names it.¶

In two-phase execution, the enforcement boundary first evaluates the policy chain and, on a permit or narrow verdict, issues an approval bound to the authority the verdict grants: a first-class consumable artifact, bound to the action_ref it approves, single-use, and carrying a bounded lifetime. Execution then presents and consumes the approval. At consumption the boundary MUST re-validate what can have changed since issuance, including revocation status and temporal validity, generalizing the Section 3.2 recheck. An approval that has expired, has already been consumed, or fails re-validation MUST NOT admit execution.¶

For actions carrying a spend dimension, the two phases align with reserve-then-settle: the amount is reserved against the boundary-held cumulative total (Section 4) at approval, and settled at completion. This document specifies the gate model and its obligations; the internal mechanics of an enforcement boundary implementing it are out of scope.¶

5. Signed Receipts

This section defines the signed receipt layer produced by APS policy evaluation. The policy chain of Section 4 produces a signed record at each stage; this section defines the receipt: the artifact that records what an agent declared, what a policy engine decided, and what an enforcement boundary observed. A receipt is the protocol's unit of after-the-fact verifiability.¶

A receipt MUST be a signed object. A receipt MUST be content-addressed. A receipt MUST state the claims it carries in a form that a verifier can check without access to the system that produced it.¶

5.1. Receipt Envelope

All APS receipts share a common envelope. The envelope binds a receipt to an issuer, a point in time, and the action it concerns, independent of the receipt's type-specific payload. The envelope contains:¶

receipt_id: The content address of the receipt (Section 5.2).¶
receipt_type: A value identifying the receipt type. Core receipt types are defined in Section 5.3; implementations MAY define additional types as described in Section 5.3.3.¶
issuer: The DID of the entity signing the receipt.¶
subject_agent: The DID of the agent whose action the receipt concerns. The issuer and the subject_agent MAY differ; for a Bilateral Receipt there are two signing parties.¶
action_ref: The content-addressed request identity defined in Section 4.1, identifying the action this receipt concerns.¶
delegation_ref: A reference to the delegation chain under which the action was taken, or to the authority basis where no delegation applies. A chain root is either APS-native, a passport-signed origination, or an imported external authority: a verified grant from an external authorization system, marked as such (Section 7.3). An imported root records that verification of the external grant was performed by the importing party; APS signature verification begins at the first APS-signed hop.¶
decision_ref: The decision identity binding the action to its evaluated authority and policy context. REQUIRED for receipts at or after the PolicyDecision stage. The concrete computation of decision_ref is deployment-profile-defined unless specified by a future APS profile; this document defines its role and binding semantics (Section 5.4), not a single normative computation.¶
issued_at: An RFC 3339 UTC timestamp.¶
evidence_refs: Zero or more references to artifacts the receipt relies on or records. References, not embedded content.¶
result: The outcome or status the receipt records, in a form determined by receipt_type.¶
prev: OPTIONAL. The content address of the preceding receipt in a chain, or null or absent for a chain origin or an unchained receipt (Section 5.2).¶
sig: A signature over the canonicalized envelope, computed with the sig field absent.¶

The canonicalization of the envelope for both content-addressing and signing MUST follow RFC 8785 [RFC8785]. The signature MUST be computed as specified in Section 5.2.¶

A receipt MUST state what it proves. A receipt MUST NOT be interpreted as proving claims outside the semantics of its receipt_type (Section 5.3).¶

5.2. Content Addressing and Hash Chaining

A receipt's content address is computed as receipt_id = SHA-256(canonicalize(envelope without sig or receipt_id)), where canonicalize is RFC 8785 [RFC8785]. The receipt_id MUST be deterministic: the same envelope content MUST produce the same receipt_id regardless of implementation language or JSON library. This is the same determinism property required of action_ref in Section 4.1, applied to the receipt envelope.¶

Receipts MAY be chained. When chained, each receipt's prev field carries the receipt_id of the preceding receipt. A chain proves ordering between the receipts it links. A chain does not, by itself, prove completeness or prove that no receipt was omitted between two linked entries. A party that emits a chain selects which receipts the chain links; a verifier cannot conclude from the chain alone that no receipt was withheld. Deployments that require completeness or omission-resistance MUST specify an external mechanism that provides it, such as a monotonic sequence committed by the issuer or an append-only log with inclusion proofs. This document does not define such a mechanism.¶

The signature over the envelope MUST be an EdDSA signature as specified in [RFC8032], computed over the RFC 8785 canonicalization of the envelope with the sig field absent.¶

5.2.1. Word-Handle Digest Presentation

A content address is long, and human transcription of digests is a practical failure surface. A deployment MAY present a digest as a word handle: the leading bits of the digest rendered as words from a versioned, pinned lexicon, followed by checksum words derived from the rendered prefix. A handle identifies the lexicon it was rendered under; a decoder MUST reject a word not exactly present in the pinned lexicon rather than correct it, and comparison of decoded prefixes is bit-scoped to the rendered prefix length, never a raw string comparison beyond it.¶

A word handle is a transcription and recognition aid, not a cryptographic proof: it carries only a prefix of the underlying digest. A verifier MUST NOT accept a word handle as identifying a unique receipt, record, delegation, or content object unless it has resolved the handle to the full digest or confirmed that the rendered prefix is unique within its candidate set at the time of resolution. A word handle is public: it MUST NOT be presented as a mnemonic, recovery, or seed phrase, and MUST NOT be used as secret, key, or authorization material. Presentations at common seed-phrase lengths (12, 15, 18, 21, or 24 words) MUST NOT be used.¶

5.3. Receipt Type Categories

APS defines receipt categories at two tiers. The foundational tier covers the receipts every governed action produces. The supporting tier defines optional protocol receipt categories for deployments that need to record accountability events around an action.¶

5.3.1. Foundational Receipts

Action Receipt: Records the occurrence and outcome of a governed action. The PolicyReceipt stage of the policy chain (Section 4) is the point at which an enforcement boundary emits an Action Receipt. Action Receipt is the general category for "this governed action occurred and here is its outcome."¶
Authority-Boundary Receipt: Records the agent's authority position at the moment of an action: the lattice element (Section 3.1) the agent held, and which constraint dimensions bounded the action.¶
Completion Receipt: Records the closure of a previously authorized action, and MUST reference the receipt that authorized it. A Completion Receipt closes an authorize-then-complete pair. Not every Action Receipt is a Completion Receipt: an Action Receipt becomes a Completion Receipt only when it closes a prior authorization in this way.¶

5.3.2. Supporting Receipts

Bilateral Receipt: A receipt over an interaction between two agents, signed by both. A Bilateral Receipt proves that both parties observed the same interaction content; it does not prove either party's intent or honesty beyond that shared observation.¶
Custody Receipt: Records a transfer of governance custody over a data object, tool, or resource from one agent to another. Custody in this sense is the responsibility for an object under the protocol's authority model; it is not ownership, possession, or any commercial-settlement relationship.¶
Contestability Receipt: Records that an action, receipt, or decision can be challenged, or was challenged, under a defined governance process, together with the disposition of that challenge. It is not a payment dispute, an arbitration record, or a transactional-settlement artifact; those are outside the scope of this document.¶

5.3.3. Extension and External Representation

An implementation MAY define additional receipt types. Additional types MUST use the common envelope (Section 5.1) and MUST NOT redefine the semantics of the categories above. Signed record classes that do not use the common envelope are not receipt types; they are specified as supporting signed records (Section 5.3.4) and MUST NOT be presented as envelope receipts.¶

APS receipts MAY be represented in external attestation formats. For example, an Action Receipt MAY be expressed as an in-toto predicate for interoperability with attestation tooling that consumes that format. Such an external envelope is a representation of an APS receipt; it does not define the APS receipt taxonomy, and the categories above remain the normative reference.¶

5.3.4. Supporting Signed Records

The record classes of this section are signed evidence artifacts, not receipt types under the common envelope of Section 5.1. Each carries a top-level signature field; the signature input is the RFC 8785 canonicalization of the record with that field absent, under EdDSA as in Section 5.2. Each carries the action correlation key where applicable, and MAY be referenced from receipts through evidence_refs. Whether a record class is content-addressed is defined per class by its published conformance fixtures; this document does not impose the receipt_id computation of Section 5.2 on these records. The reference implementation's type and module names for these classes predate this document's receipt-and-record boundary and include the word receipt; the boundary of Section 5.3.3, not implementation naming, is normative.¶

Composition-Check Record: A signed record by which an external attestor reports the outcome of named checks over an exact delegation chain, action, and context. Per-hop monotone narrowing (Section 3.1) is evaluated hop by hop; delegations that are individually rule-legal can compose toward a target that no single hop check can see, and Section 3.1 provides no per-hop mechanism to detect that. The composition-check record is the carrier for the result of whole-chain evaluation performed outside the chain. It binds a digest of the exact chain, the action_ref, and a digest of the evaluated context; it names the policy profiles and checks run as opaque versioned identifiers; and it carries one result per check from a fixed vocabulary (pass, fail, indeterminate, not checked). It carries, deliberately, no aggregate safety verdict: a pass is the named attestor's finding for one named check over the bound context, never a claim of global safety. The record declares the attestor's independence class relative to the parties in the chain; a verifier corroborates that class from its own trust context, and MUST NOT accept independence on the record's self-declaration. What the checks evaluate is attestor policy, outside this document's scope.¶
Accountability Record: A signed record of an enforcement-boundary decision, covering denied and halted actions as well as permitted ones. The Action Receipt (Section 5.3.1) records that a governed action occurred; a boundary that refuses or stops an action produces no Action Receipt, and without a record of the refusal the denied path is unauditable. The accountability record carries the boundary's decision from its own vocabulary, allow, deny, or halt, which is distinct from the PolicyDecision verdict vocabulary of Section 4: the verdict (permit, deny, or narrow) is the policy engine's evaluation; the decision (allow, deny, or halt) is what the enforcement boundary did. A permit or narrow verdict admits execution under the authority the verdict grants and resolves to an allow, or to a halt if the boundary stops the admitted action; a deny verdict resolves to a deny decision. The record additionally asserts, as an independent field, whether execution was observed: decision and execution status are recorded separately precisely so that a denied-but-executed event, a boundary violation, is representable rather than structurally impossible to write down. The record identifies the recorder and the recorded agent as distinct parties, carries the action_ref as its correlation key and a detached digest of the recorded action as its per-record commitment (the two are different values with different roles), and MAY carry a recorder-asserted reference to the principal; such a reference is an attribution convenience at the resolved level of Section 5.7 and does not alter that document-wide model.¶
Read-Fidelity Record: A signed commitment to a sampled readback challenge: evidence bearing on whether an executor read the content it claims to have read. A verifier supplies a nonce that is not derivable from the document; a seed is derived, by a stated computation, from the content digest, the presentation digest, the nonce, and a version; spans are sampled deterministically from the seed; and the record commits to the span digests and a scored k-of-n readback result. The raw span texts and responses are not in the record, only their commitments. The nonce binding is the replay defense: reusing commitments under a different nonce, content, or presentation breaks the seed derivation. This document sets no normative passing threshold; the record reports the score and the sampling parameters, and what score suffices is a deployment decision. A read-fidelity record is evidence of readback performance on the sampled spans; it is not proof of comprehension, of complete reading, or of any property of unsampled content.¶

5.4. Binding to action_ref, Delegation, and Policy Decision

A receipt is bound to the action it concerns through three references.¶

action_ref: REQUIRED. Every receipt envelope carries the action_ref of Section 4.1. Two receipts carrying the same action_ref concern the same request. This is the primary correlation anchor: it allows receipts produced by independent engines, or at different stages, to be associated without prior coordination.¶
delegation reference: REQUIRED where the action was taken under a delegation. The receipt MUST identify the delegation chain under which the agent acted. This binds the receipt to the authority path of Section 3: a verifier can follow from the receipt to the delegation to the issuing passport.¶
decision reference: REQUIRED for receipts at or after the PolicyDecision stage. The receipt MUST carry the decision identity of the policy evaluation it records or follows from. The action_ref is the action correlation anchor; the decision identity binds that action reference to the evaluated authority and policy context and to the decision output. It is not a second action identifier. Two receipts carrying the same decision identity claim the same action, authority and policy context, and decision output as encoded in that decision identity. A decision identity SHOULD be content-derived: computed from the fields that constitute the decision, so that the identity is a function of what was decided rather than of where or when the record was stored, and independent parties can recompute it from the same inputs. A content-derived decision identity induces a field taxonomy on decision records: identity fields, which enter the computation and define which decision this is; ordering fields, which sequence records without changing identity; and event-instance fields, which distinguish multiple records of the same decision. Two records agreeing on identity fields are records of the same decision by construction. A reference computation with these properties is published with the reference implementation; a deployment profile MAY adopt it (see Section 11).¶

Through these three references a single receipt is locatable within the protocol: which request (action_ref), under whose authority (delegation), evaluated to what (decision identity).¶

5.5. Replay and Verification Expectations

The receipt signature and the canonical envelope MUST be verifiable offline. A verifier in possession of a receipt and the issuer's public key MUST be able to confirm, without network access and without contact with the issuing system: (1) that the signature is valid over the canonicalized envelope (Section 5.2); (2) that the receipt_id matches the envelope content; (3) that the action_ref is well-formed per Section 4.1; and (4) where a prev reference is present, that it is a well-formed content address.¶

The offline checks above establish signature validity: that the signature verifies under a public key the verifier holds. Signature validity is distinct from signer authority: possession of a key that verifies the signature does not by itself establish that the key was the authorized signing key for the claimed issuer. Where a verification decision depends on the issuer's authority and not only on the artifact's integrity, a verifier performs a further, separately named step: resolve the issuer identifier to its authorized key material through a resolution mechanism the verifier trusts, and confirm that the signing key is authorized for the artifact's own signed timestamp, evaluated against per-key validity windows rather than against whichever key is current at verification time.¶

Signer-authority resolution has more outcomes than valid or invalid, and a verifier's result SHOULD preserve the distinction: the signature may verify under authorized, resolution-confirmed key material; the signature may verify under key material the verifier holds only by binding, with no authority resolution performed; resolution itself may fail; the resolved authority may not match the signing key or a pinned expected signer; or the signature may simply be invalid. A result in which resolution was not performed MUST NOT be reported at the same level as a result in which it succeeded.¶

Resolution failures are fail-closed by default. A deployment MAY adopt a fail-open policy for transport unreachability only; a resolution that returns structurally invalid key material is not a transient transport condition and MUST fail closed even under such a policy. An outcome degraded by a fail-open policy MUST NOT be treated as a positive verification.¶

Any claim that depends on external state, such as revocation status, policy registries, custody context, the resolution of a delegation chain, or referenced evidence artifacts, requires the corresponding referenced material and is therefore not verifiable from the receipt alone. The offline guarantee covers the receipt's own integrity, not the external facts the receipt references.¶

Referenced evidence has the same structure. An evidence reference in a receipt (Section 5.1) carries a claimed content address, and the receipt signature covers the claim, not the artifact. A verifier distinguishes two evidentiary states: signature-only, in which the receipt attests a content address and no referenced artifact was retrieved and checked, and resolved, in which the artifact was retrieved, its content address recomputed, and the recomputation matched the claim. Retrieval failure, a recomputation mismatch, or the absence of a retrieval mechanism leaves the evidence at signature-only; none of these upgrades to resolved, and a mismatch is grounds to treat the reference as unverified regardless of the receipt signature's validity.¶

Two conforming engines evaluating the same action under the same canonical input object, authority state, and policy context MUST produce receipts that agree on action_ref. Cross-engine agreement on decision identity is defined only for conforming engines operating under the same APS profile, where that profile specifies the same canonical decision input object and the same decision_ref computation (Section 5.4). This is the cross-engine replay property: within a shared profile, a second engine can re-evaluate a recorded decision and confirm agreement without coordinating with the first. This document does not define a globally interoperable decision_ref computation; cross-profile decision-identity agreement is therefore outside its scope.¶

A verifier MUST NOT treat a valid receipt signature as evidence of the truth of the receipt's claims about the external world. A receipt signature proves that the issuer attests the payload. It does not prove the payload corresponds to external fact. The distinction between protocol-level validity and external truth is addressed in the Security Considerations.¶

5.6. Relationship to the Policy Chain

The three-signature policy chain of Section 4, ActionIntent, PolicyDecision, PolicyReceipt, and the receipts of this section are the same structure described at two levels. The policy chain names the three signing stages of a governed action. The receipt is the signed object each stage produces and the envelope that makes it verifiable after the fact.¶

Specifically: the ActionIntent is the agent's signed declaration; the PolicyDecision is the policy engine's signed evaluation, carrying the decision identity of Section 5.4; the PolicyReceipt is the enforcement boundary's signed Action Receipt (Section 5.3) recording execution. PolicyReceipt names the policy-chain stage at which an Action Receipt is emitted; it is not a separate receipt_type defined by this document. Invariant INV-6 (Intent-Receipt Binding, Section 3.3) is the requirement that these are cryptographically linked: the receipt at the end of the chain MUST be traceable to the intent at its start. While general receipt chaining is optional (Section 5.2), the receipts of a single policy chain MUST carry sufficient references -- through prev, action_ref, and decision_ref -- for a verifier to trace from the final receipt back to the originating ActionIntent. INV-6 is the statement of that requirement; general chaining of unrelated receipts remains at the emitter's discretion.¶

The policy chain is therefore complete only with the receipt layer. Section 4 specifies when the signatures are produced; this section specifies what they produce and how it is verified. Without receipts, the policy chain defines a decision process but leaves no protocol-level artifact for later verification.¶

5.7. Attribution and Beneficiary References

APS receipts identify the authority, action, and evidence associated with an agent operation. Some deployments also need to attribute the resulting deliverable, or the downstream benefit of an action, to one or more entities, including humans, organizations, agents, data sources, or tool providers.¶

The attribution axes APS distinguishes, and the boundary of what this document specifies, are described in the Attribution Axes and Scope section. Within the receipt layer specifically, this document does not define a contribution-attribution model, a beneficiary-attribution model, or a settlement model. Implementations MAY include, in a receipt's evidence_refs (Section 5.1), references to external attribution or beneficiary records. Such records, and the allocation rules that interpret them, are expected to be specified by companion documents. A reference of this kind does not change the receipt's own semantics: a receipt continues to prove only the claim defined by its receipt_type (Section 5.3).¶

The principal on whose behalf an agent acted is resolvable from the delegation_ref carried by the receipt: the delegation chain root identifies the authorizing principal or authority basis. Principal resolution supports two claim levels, and a resolver MUST NOT conflate them. A lineage is resolved when every hop of the referenced chain looks up successfully against the delegation records available to the resolver and the chain root maps to a known principal. Resolution is a lookup success and makes no cryptographic claim: a supplied chain that happens to match known records can be resolved without being authentic. A lineage is verified when the receipt signature verifies against the executor at the chain tail and every delegation in the traced lineage carries a valid signature by its delegator and is within its validity window. A tampered or forged chain cannot be verified. Verified attests the authenticity and temporal validity of the lineage signatures; it does not by itself attest that the action was within the delegated scope, that scope narrowed between hops, or that no delegation in the lineage was revoked, each of which is a further check against the corresponding material (Section 5.5).¶

Lineage reporting MUST be deterministic: the same receipt and the same delegation records MUST produce the same reported lineage, independent of record ordering, and the reported hop at the chain tail MUST be consistent with the delegation reference the receipt itself carries. Where multiple delegation records match a hop, the authenticity property is evaluated against the set (some valid matching record suffices; no valid matching record breaks it), so that a duplicate or re-issued record can neither manufacture nor destroy verification.¶

This document does not define a separate principal field on receipts. Deployments that need faster lookup MAY denormalize the chain root into a profile-defined field, but such a field is a convenience copy at the resolved level at most; it does not replace verification of the delegation chain. Allocation of work, credit, benefit, compensation, ownership, or liability across beneficiaries or other attribution recipients remains out of scope for this document.¶

5.8. Receipt Profiles

A receipt profile is a named, versioned set of additional constraints over the receipt layer: which fields are required, which external anchors must be present, and what claim vocabulary the result is expressed in. The result classifications a profile defines are its dispositions. A profile strengthens what a receipt can claim without changing the base semantics of Sections 5.1 through 5.7. Profiles are identified by a version-carrying identifier, and a receipt evaluated under a profile names the profile it was evaluated under.¶

One profile with these properties, the regulated-action profile, is published with the reference implementation and illustrates the mechanism. Its core device is trust-domain counting: the profile counts the distinct trust domains, relative to the operator, from which the action's supporting attestations originate, for example an external identity provider asserting the acting identity and the target resource's system of record confirming the effect against a key registered independently of the operator. The profile's strong disposition is gated on attestations from at least two distinct trust domains; below that threshold the result is expressible only in dispositions that name the weaker basis, such as self-attested or authority-bound. An operator-anchored copy of an external assertion does not count as a second domain. Two trust domains are distinct, relative to the operator, when their attesting keys are controlled and published independently of the operator and of each other; the profile's versioned identifier defines the concrete distinctness test. A profile disposition is a profile-scoped result label: it does not replace the receipt's result field, and it is distinct from the verdict vocabulary of Section 4, the boundary-decision vocabulary of Section 5.3.4, and the claim levels of Section 5.7. The profile additionally requires hash-committed intent pre-commitment, with the committed intent temporally ordered before the resource event, and its result always carries an explicit statement that correctness of the agent's judgment is not claimed. The full disposition vocabulary is defined by the profile's versioned identifier, published with the reference implementation, and is not frozen into this document. A verifier evaluating the profile is stateless over supplied inputs; how those inputs are gathered and reconciled is deployment machinery outside this document's scope.¶