Agent Passport System

signal@aeoess.com https://agent-passport.org

Security Individual Submission AI agent identity delegation capability attenuation governance Ed25519 signed receipts This document specifies the Agent Passport System (APS), a protocol for identifying AI agents, attenuating delegated authority, and producing signed evidence at policy-enforcement boundaries. APS defines Ed25519 agent passports; separately signed principal bindings; delegation chains that cannot widen across scope, spend, depth, time, reputation, values, or reversibility; deterministic action and decision references; and a common envelope for signed action receipts. It also defines bindings for Model Context Protocol tool calls and imported OAuth identity-assertion authorization grants. Verification results keep cryptographic integrity, signer authority, referenced-artifact resolution, policy semantics, and external truth separate. An Implementation Status section identifies the exact coverage and maturity of the available open-source implementations.

Introduction AI agent systems are increasingly deployed in architectures where orchestrators decompose tasks and delegate subtasks to specialist agents. Existing agent communication protocols, including the Model Context Protocol (MCP) and the Agent-to-Agent Protocol (A2A) , address connectivity and tool invocation. Deployments may need additional layers for cryptographic agent identity, delegated authority, and verifiable enforcement evidence. When an orchestrator delegates to a specialist that invokes a tool, the tool-side record may omit the authority path that led to the invocation. APS fills this gap by providing: (1) Ed25519 agent passports and separately signed principal bindings; (2) scoped delegation chains where authority narrows monotonically across seven constraint dimensions; (3) cascade revocation with signed revocation history and cascade-completion evidence; (4) a three-record policy chain binding intent, decision, and observed result; (5) a common signed-receipt envelope for those records; (6) a componentwise composition rule for institutional governance structures specified in companion work; and (7) an enforcement-gateway model that can serve as an external reference monitor. Agentic work raises several distinct attribution questions: under whose authority an action was taken, what sources contributed to a deliverable, on whose behalf the agent acted, and who receives the value the work creates. This document specifies the authority core and the signed receipt layer through which principal resolution is recorded and other attribution axes may be referenced; it does not define contribution-attribution or beneficiary-attribution models. The protocol's formal invariants and design rationale are published in the informative references. This individual submission specifies APS and identifies current implementation coverage and deviations in Appendix A. Its requirement keywords constrain implementations claiming conformance to this revision.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Identity Scheme

Agent Passport An APS Agent Passport is a self-signed cryptographic identity record. The version specified here has record_type "aps.agent-passport" and version "2.0". Its wire object contains exactly the following members: passport_id, agent_id, verification_method, public_key_multibase, issued_at, expires_at, nonce, self_asserted, record_type, version, and signature. The self_asserted object contains a required, UTF-8-byte-sorted unique capabilities array and an optional display_name. A principal or owner identifier is not a passport member; principal authority is carried by the separate record in Section 2.3. The public key is a multibase base58btc encoding of the multicodec Ed25519 public-key prefix 0xed01 followed by the 32-byte public key. issued_at and expires_at use the exact UTC millisecond form YYYY-MM-DDTHH:MM:SS.sssZ, and the validity interval is issued_at <= now < expires_at. nonce is 16 bytes encoded as 32 lowercase hexadecimal characters. The passport identifier and signature are computed as follows, where JCS is RFC 8785 over validated I-JSON, UTF8 converts the resulting string to bytes, and || denotes byte concatenation: A valid self-signature establishes possession of the private key corresponding to public_key_multibase and protects the signed fields. It does not establish that verification_method was authorized for agent_id, or that any self-asserted claim is true. A verifier MUST report proof of possession separately from key authority. For an identifier that is not self-certifying, key authority is verified by resolving verification_method at issued_at under the identifier's own method and trust policy.

Agent Identifiers APS is DID-method-agnostic. agent_id and verification_method use the syntax and resolution rules of the selected DID method . New self-certifying passports SHOULD use an existing generative DID method whose identifier commits to the signing key, such as did:key . Rotation of a self-certifying key changes that identifier. Deployments that require one stable agent identifier across key rotation MUST use an update-capable DID method and resolve the verification method at the artifact's signing time, for example by a method-defined versionId or versionTime. A successor statement between two self-certifying identifiers documents a claimed migration; it does not transfer delegations or establish that the identifiers are equivalent. Earlier APS implementations emitted the experimental identifier did:aps:z<base58btc-multicodec-key>. A compatibility verifier MAY read that exact immutable form. It MUST treat the embedded key as the complete identifier state, MUST reject the earlier raw-hex alias, and MUST treat rotation as a new identifier. Conforming new-write paths in this revision do not emit did:aps identifiers.

Principal Binding A passport does not identify the person or organization on whose behalf an agent acts. That relationship is expressed by a PrincipalBindingV1 record with record_type "aps.principal-binding" and version "1.0". The record contains binding_id, agent_id, principal_id, verification_method, audiences, authority_profiles, status_uri, issued_at, expires_at, nonce, and signature. audiences and authority_profiles are non-empty, UTF-8-byte-sorted unique arrays. The principal signs the record with the key named by verification_method. The record is therefore scoped rather than a global assertion that the agent represents the principal for every purpose. binding_id uses the tag "APS-PRINCIPAL-BINDING-ID-V1" and the same construction as passport_id, with binding_id and signature absent. signature uses the tag "APS-PRINCIPAL-BINDING-SIG-V1" and covers the binding with signature absent. Both tags are followed by one zero byte before the JCS bytes. Claim levels are verifier results, not labels selected by the issuer. A principal string found only in a self-signed or legacy passport is self_asserted. A binding whose principal signature and signing-key authority verify is principal_attested. A verifier reports externally_verified_principal only when its own trust policy has also verified the principal identity. A verifier MUST NOT infer a higher level from the presence of a field. Binding revocation is a separate signed record with record_type "aps.principal-binding-revocation", version "1.0", revocation_id, binding_id, principal_id, verification_method, revoked_at, reason_code, nonce, and signature. Its identifier and signature use the tags "APS-PRINCIPAL-BINDING-REVOCATION-ID-V1" and "APS-PRINCIPAL-BINDING-REVOCATION-SIG-V1", respectively. Revoking a principal binding does not revoke the agent's key or unrelated delegations; an enforcement profile defines which authority records depended on that binding.

Key Rotation and Historical Verification An update-capable identifier MAY rotate its signing key. A retired key is eligible only for artifacts whose signing time falls within the key's method-defined validity interval. A resolver MUST select the key version authorized at the artifact's issued_at; selecting the key that is current at verification time is insufficient. The artifact timestamp is an issuer claim. This document does not define a trusted timestamping service. When key retirement makes the result depend on whether an artifact was signed before a boundary, a profile MUST identify an acceptable timestamp, transparency-log, or equivalent evidence source. Without that evidence the key-authority result is indeterminate, even when the artifact signature is cryptographically valid.

Key Resolution for External and Evidence Signers Sections 2.1, 2.2, and 2.4 govern an agent's own signing key and its historical resolution. 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.

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.

Delegation and Authority Attenuation

Faceted Authority Attenuation AuthorityDelegationV1 is the signed authority record specified by this revision. It has record_type "aps:authority-delegation:v1", version "1.0", delegation_id, parent_delegation_id, issuer, subject, verification_method, issued_at, nonce, authority, and signature. parent_delegation_id is null only for a root selected by verifier trust policy. authority contains exactly seven required facets: scope, spend, depth, time, reputation, values, and reversibility. A missing facet is invalid rather than an implicit unconstrained value. ", "parent_delegation_id": null, "issuer": "did:example:principal", "subject": "did:example:agent", "verification_method": "did:example:principal#key-1", "issued_at": "2026-07-18T22:00:00.000Z", "nonce": "<32-lowercase-hex>", "authority": { "scope": {"profile":"aps-hierarchical-v1", "grants":["commerce:checkout"]}, "spend": {"mode":"bounded","unit":"iso4217:USD:minor", "per_action":"5000","cumulative":"10000"}, "depth": {"remaining":2}, "time": {"not_before":"2026-07-18T22:00:00.000Z", "not_after":"2026-07-19T22:00:00.000Z"}, "reputation": {"profile":"aps-score-0-100-v1","ceiling":80}, "values": {"profile":"aps-values-identifiers-v1", "required":["F-001","F-003"]}, "reversibility": {"profile":"aps-tci-v1", "ceiling":"compensable"} }, "signature": "<128-lowercase-hex>" } ]]> The object schema is closed. All timestamps use exact UTC milliseconds. nonce is 16 random bytes. delegation_id and signature are computed as follows: A verifier resolves verification_method for issuer at issued_at. A valid self-issued root is not trusted automatically; acceptance of a root is verifier policy.

Component Orders Let child be directly delegated from parent. child is no wider than parent only when every comparison below succeeds. Profiles on a facet MUST match; a profile change is unsupported rather than narrower.

Scope

Scope grants use ASCII colon-separated segments. "*" covers all grants; a wildcard is otherwise permitted only as the terminal segment ":*". An exact grant covers itself. A terminal wildcard p:* covers p and every grant beginning p:. Every child grant MUST be covered by a parent grant. Arrays are UTF-8-byte-sorted, unique, and irredundant.

Spend

Spend is either {"mode":"unbounded"} or a bounded object with unit, per_action, and cumulative. Amounts are canonical unsigned decimal integers from 0 through 9223372036854775807; per_action MUST NOT exceed cumulative. A bounded child under a bounded parent uses the same unit and no greater limit. A bounded child under an unbounded parent is narrower. An unbounded child under a bounded parent is invalid. APS performs no unit conversion.

Depth

remaining is an integer from 0 through 255. A parent with zero remaining cannot issue a child. Otherwise child.remaining MUST be no greater than parent.remaining minus one.

Time

The half-open child interval [not_before, not_after) MUST be contained in the parent interval. A child's not_before MUST NOT predate its issued_at, and a child MUST be issued while the parent is valid. Relative durations are converted to absolute instants before signing and do not appear in the wire record.

Reputation

ceiling is an integer from 0 through 100. A child ceiling MUST NOT exceed its parent. Runtime authorization uses the lesser of the resolved subject score and the signed ceiling. Missing, stale, or profile-incompatible reputation evidence yields indeterminate when that evidence is required.

Values

required is a sorted unique array of profile-defined identifiers. A child MUST contain every parent-required identifier and MAY add identifiers. This comparison preserves requirements; it does not establish that the subject complies with them.

Reversibility

The order from narrowest to widest is tentative, compensable, irreversible. A child ceiling MUST NOT move to the right. An unknown or unresolved action classification is treated as irreversible. This ceiling constrains authority; the realized reversibility of an action is determined by its effects and need not compose across a chain.

These comparisons define a componentwise partial order over the seven-facet vector. Scope narrows by coverage, Values narrows by adding requirements, and every other facet follows its rule above. A valid child is less than or equal to its parent in every component. The fuller formalization appears in and .

Chain Verification A verifier processes a root-to-leaf chain in this order: closed schema and canonical values; delegation_id; historical signing-key resolution and signature; duplicate identifiers; root trust; parent_delegation_id; issuer-to-subject continuity; child issuance time; the seven facet comparisons in Section 3.2; current validity; and revocation state for every member. A cycle, repeated identifier, broken parent link, or issuer discontinuity invalidates the chain. Verification returns one of valid, invalid, indeterminate, or unsupported with a stable failure code. An unavailable or stale revocation result is indeterminate. An unsupported facet profile is unsupported. Cryptographic or attenuation failure is invalid. A caller MUST NOT collapse indeterminate or unsupported into valid. Each action selects one root-to-leaf authority chain. A verifier MUST NOT union scopes or budgets from multiple chains. Cross-principal composition requires a separate profile.

Cumulative Spend Across a Delegation Subtree The signed cumulative value is a ceiling for the entire delegation subtree, not an entitlement reserved for each child. Before an action with amount q is dispatched, an enforcement boundary performs one atomic transaction over every bounded delegation in the selected root-to-leaf chain. It verifies the common unit and each per_action limit, verifies committed plus reserved plus q is no greater than each cumulative limit, and reserves q against every bounded ancestor or against none. The reservation is keyed by action_ref. An identical retry is idempotent; conflicting reuse is rejected. Successful settlement moves every ancestor counter atomically from reserved to committed. Cancellation releases a reservation only before dispatch or after trusted evidence that dispatch did not occur. This prevents two siblings from each consuming a parent's complete cumulative budget. A distributed deployment needs one linearizable accounting ledger for the authority tree. Without it, live spend status is indeterminate. Signatures establish static limits; they do not establish the current cumulative total.

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.5.1 has been emitted. Revocation is irreversible. Until that record is available, a verifier treats the cascade as incomplete. The enforcement gateway MUST recheck revocation status at execution time, not only at approval time.

Revocation Evidence Section 3.5 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.6) is required by Section 3.5 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.

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), and INV-8 (Signature Integrity). The cascade-completion record of Section 3.5.1 makes INV-4 verifiable from records. The signed receipt layer in Section 5 elaborates INV-6. INV-7 requires every governed action to identify an acting agent, an authority path, and a receipt context. It does not concern contribution-attribution or beneficiary-attribution, which are outside the scope of this document as described in Section 12. 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.3), 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.

Policy Chain APS defines a three-record policy chain: an action-intent record in which the agent declares the intended action; a policy-decision record in which the policy engine returns permit, deny, or narrow, with narrow carrying the reduced authority and applied constraints; and an action-result record in which the enforcement boundary records the observed 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 each signed record 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.2); 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; live spend is enforcement-boundary state. A cumulative limit applies to the complete delegation subtree, not independently to each descendant. Before dispatch, the boundary MUST atomically reserve the proposed amount against every bounded ancestor in the selected root-to-leaf chain. It MUST dispatch only if the reservation succeeds for all of them. After settlement, the boundary atomically moves the reservation to committed spend for every affected ancestor. This all-or-none operation prevents sibling delegations and concurrent requests from overspending a shared ancestor. Signatures establish the static limits; the accounting ledger establishes the live totals.

Action Reference Computation Each governed action is identified by an action_ref under the profile "aps-action-ref-v2". The reference commits to who is acting, what operation is requested, where it will occur, the exact payload, the authority scopes needed, when the intent was issued, and a replay-resistant nonce. The input object has exactly these members: ", "scope_required": ["commerce:read", "commerce:write"], "issued_at": "2026-04-08T12:00:00.000Z", "nonce": "<32 lowercase hexadecimal characters>" } ]]> profile MUST equal "aps-action-ref-v2". agent_id is the acting agent's identifier. action_type is the operation identifier. target is the exact resource, tool, or endpoint against which the action will be dispatched; a profile MUST define its target string construction. payload_ref is the lowercase hexadecimal SHA-256 digest defined below. scope_required is a duplicate-free array of NFC strings sorted by the lexicographic order of their UTF-8 encodings. issued_at is an RFC 3339 UTC timestamp with exactly three fractional digits and the literal "Z" suffix. nonce is 16 random bytes encoded as 32 lowercase hexadecimal characters. All string fields MUST be non-empty except that a profile MAY permit an empty scope_required array. The payload reference and action reference are computed as: JCS is RFC 8785 and SHA-256 is defined in . The payload is the exact JSON value presented for authorization and dispatch. The input_object includes payload_ref and excludes the payload itself. A verifier MUST reject an object with an unknown or duplicate member, a non-I-JSON value, a non-canonical scope array, an invalid timestamp, or an invalid hexadecimal field. A parser MUST detect duplicate names before conversion to an ordinary map; it MUST NOT accept the last occurrence silently. A string containing an unpaired UTF-16 surrogate has no UTF-8 encoding and MUST be rejected. An implementation MUST NOT substitute U+FFFD, delete the code unit, or otherwise repair the string. Scope normalization occurs when the intent is created; a verifier accepts only the resulting NFC, sorted, duplicate-free form and does not normalize an untrusted wire object before verification. The enforcement boundary MUST recompute payload_ref from the payload it will dispatch and action_ref from the received input object. It MUST reject either mismatch before policy evaluation. It MUST also reject reuse of nonce by the same agent within the deployment's replay window. The nonce prevents two otherwise identical requests from sharing an approval or receipt identity; it does not replace an enforcement-boundary replay ledger.

Legacy 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": where canonicalize is RFC 8785 , 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.

scope

A single scope string.

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. This form predates aps-action-ref-v2 and remains only for correlation with records that already use it. It omits the target, payload digest, and nonce, and therefore MUST NOT identify an APS policy decision, approval, dispatch, spend reservation, or receipt. An implementation MUST label it "action-ref-v1-jcs-sha256" and MUST NOT present its digest as an action_ref under Section 4.1. 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 aps-action-ref-v2 form of Section 4.1 is the only action identity 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.

Two-Phase Execution Section 3.5 requires revocation to be rechecked at execution time, and the action-result record of Section 5.3.3 records the observed outcome after a policy decision is consumed. These requirements place enforcement at two distinct moments; this section names that model. 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, as required by Section 3.5. 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.

Governed Action Records APS represents a governed action as three signed records: an agent's intent, the enforcement boundary's policy decision, and, when dispatch occurs, the boundary's observed execution result. All three use the ReceiptV1 envelope. The common envelope permits one verification algorithm while receipt_type and result state the record's stage and bounded semantics.

ReceiptV1 Envelope A ReceiptV1 is a closed JSON object. The example below is an action-intent record and therefore omits the conditional decision_ref and prev members described after the example: ", "receipt_type": "aps:action-intent:v1", "issuer": "did:key:z6Mk...", "subject_agent": "did:key:z6Mk...", "action_ref": "<64 lowercase hexadecimal characters>", "delegation_ref": "sha256:<64 lowercase hexadecimal characters>", "issued_at": "2026-04-08T12:00:00.000Z", "evidence_refs": [], "result": { "profile": "aps-action-intent-result-v1", "status": "declared" }, "signatures": [{ "signer": "did:key:z6Mk...", "key_id": "did:key:z6Mk...#z6Mk...", "alg": "Ed25519", "value": "<128 lowercase hexadecimal characters>" }] } ]]> profile MUST equal "aps-receipt-v1". receipt_type identifies a stage defined in Section 5.3. issuer is the party responsible for that record. subject_agent is the acting agent. action_ref is the aps-action-ref-v2 digest from Section 4.1. delegation_ref identifies the selected AuthorityDelegationV1 leaf, or the authority basis when no delegation exists. decision_ref is REQUIRED for policy-decision and action-result records and MUST be absent from an action-intent record. issued_at uses exact UTC milliseconds. prev is REQUIRED for policy-decision and action-result records and MUST be absent from an action-intent record. A member that is not applicable is absent, not null. evidence_refs is a duplicate-free array of objects containing exactly artifact_type and sha256. sha256 is the lowercase hexadecimal SHA-256 digest of the artifact bytes defined by artifact_type. References are sorted first by the UTF-8 bytes of artifact_type and then by the ASCII bytes of sha256. result is the closed, typed object defined by receipt_type. signatures is a non-empty array sorted first by the UTF-8 bytes of signer and then by the UTF-8 bytes of key_id. Each signer and key_id pair occurs at most once, alg MUST equal "Ed25519", and one signature MUST be from issuer.

Receipt Identifiers and Signatures The receipt identifier is computed over the validated envelope with receipt_id and signatures absent: Each signature descriptor contains signer, key_id, and alg. Its value is computed over a form that contains the receipt with signatures absent and the descriptor as a separate signer member: The signature form includes receipt_id. It therefore binds the complete content-addressed body and the signer's own identifier, verification method, and algorithm. A verifier MUST recompute receipt_id before signature verification, resolve each key as authorized for signer at issued_at, and verify every required signature. A valid signature establishes that an authorized signing key attested to the canonical receipt body. It does not establish that an external event occurred or that a signed claim is true. A prev reference cryptographically links one receipt body to a claimed predecessor. It does not establish wall-clock ordering, completeness, or absence of omitted receipts without an external log or sequencing mechanism.

Core Receipt Types

Action Intent An action-intent record has receipt_type "aps:action-intent:v1". issuer and subject_agent MUST be the acting agent, prev and decision_ref MUST be absent, and result MUST contain exactly profile "aps-action-intent-result-v1" and status "declared". The agent signature binds the action_ref and selected delegation_ref before policy evaluation. It attests to the declared request; it does not establish that dispatch occurred.

Policy Decision A policy-decision record has receipt_type "aps:policy-decision:v1". issuer is the enforcement boundary, prev is the receipt_id of the action-intent record, and decision_ref is computed as specified in Section 5.4. result is a CoreDecisionOutputV1 object with exactly these members: ", "constraints": [], "valid_until": "2026-04-08T12:00:05.000Z" } ]]> verdict is permit, deny, or narrow. constraints is a duplicate-free array of NFC strings sorted by UTF-8 bytes. effective_authority_ref identifies the exact effective authority admitted by the decision. It is null for deny and a lowercase hexadecimal SHA-256 digest for permit or narrow. valid_until is null for deny and an exact UTC-millisecond timestamp later than issued_at for permit or narrow. A permit or narrow policy-decision record is a bounded, single-use approval for its action_ref. Before dispatch, the enforcement boundary MUST verify that it has not expired, atomically consume its receipt_id, recheck time and revocation state, and complete any spend reservation. An already consumed, expired, or stale approval MUST NOT admit dispatch. A deny record is terminal and MUST NOT be consumed as an approval.

Action Result An action-result record has receipt_type "aps:action-result:v1". issuer is the enforcement boundary, prev is the consumed policy-decision receipt_id, and decision_ref MUST equal that decision's decision_ref. result contains exactly profile, status, effect_ref, and error_code: ", "error_code": null } ]]> status is succeeded, failed, or unknown. For succeeded, effect_ref is REQUIRED and error_code is null. For failed, error_code is a non-empty stable identifier and effect_ref is either a digest of a returned error artifact or null. For unknown, both are null. A non-null effect_ref is computed as lowercase-hex(SHA-256( ASCII("APS-ACTION-EFFECT-V1") || 0x00 || JCS(effect))). An action-result record attests to what the enforcement boundary observed after dispatch. External occurrence or settlement requires separately resolved evidence.

DecisionRefV1 DecisionRefV1 commits the policy decision to the action, evaluated authority state, policy input, decision context, and decision output without requiring those potentially sensitive objects to be embedded in every receipt. Each component reference is computed over the exact JSON value evaluated by the enforcement boundary: The DecisionRefV1 input is a closed object: ", "authority_state_ref": "<64 lowercase hexadecimal characters>", "policy_ref": "<64 lowercase hexadecimal characters>", "context_ref": "<64 lowercase hexadecimal characters>", "decision_output_ref": "<64 lowercase hexadecimal characters>" } ]]> authority_state MUST include the selected authority chain, authority-basis resolution, revocation observations, and the spend state used by the decision. policy_input MUST identify the policy and version actually evaluated and include its decision-relevant input. decision_context contains decision-relevant environmental state. decision_output is the exact CoreDecisionOutputV1 carried in the policy-decision receipt. A deployment MAY keep component values private, but a verifier cannot independently recompute a component whose value is unavailable. Matching decision_ref values establish that the same component digests were named. They do not establish that the policy was correct, the inputs were complete, or the underlying claims were true.

Evidence Resolution An evidence reference is a commitment, not evidence availability. When a verification policy depends on referenced evidence, the verifier resolves the artifact under the rules named by artifact_type, hashes the exact bytes those rules select, and compares the digest. Resolution reports at least resolved, not_found, unreachable, malformed, digest_mismatch, or unsupported. A not_found, digest_mismatch, or malformed result is invalid for a required artifact; unreachable is indeterminate; unsupported is unsupported. A verifier MUST NOT report the containing receipt fully valid for a claim that depends on unresolved evidence. Retrieval code MUST apply scheme allowlists, size limits, redirect limits, timeouts, and private-network restrictions appropriate to its environment. A receipt signature does not make an evidence locator safe to fetch.

Receipt Verification A verifier performs these checks in order: parse bounded I-JSON while preserving duplicate names; enforce the closed ReceiptV1 and type-specific schema; recompute receipt_id; resolve signer authority at issued_at; verify the required signatures; recompute action_ref from the independently supplied action; verify delegation_ref and the selected authority chain; recompute decision_ref where required; validate prev and stage transitions; enforce freshness and single-use state for an approval; and resolve evidence required by the verifier's policy. The result keeps artifact integrity, signer authority, action binding, delegation validity, decision binding, stage continuity, and evidence resolution separate. An invalid cryptographic or structural check is invalid. Missing live state is indeterminate. An unknown required profile is unsupported. A caller MUST NOT collapse indeterminate or unsupported into valid.

Institutional Governance Deployments serving multi-agent organizations often need structures above a single delegation chain: charters that bound organizational authority, offices that hold standing authority, approval policies, succession, and federation across organizations. APS is designed so that such structures can project their authority into the seven-facet vector of Section 3.1 and apply the component orders of Section 3.2 at each layer. Under that model, a charter constrains offices, an office constrains delegations, and a delegation constrains actions. This document does not normatively specify those institutional structures, their wire formats, lifecycle, or semantics. A companion specification must define each projection and containment check before monotonic narrowing can be verified across an institutional structure.

Protocol Bindings

MCP Binding APS specifies a binding to MCP . For this binding, an enforcement gateway mediates the privileged actions selected by deployment policy. A privileged action is any action the policy chain (Section 4) is configured to evaluate, including any action whose required scope is non-empty under the Scope rules of Section 3.2. In an APS-mediated MCP deployment, privileged actions covered by APS policy MUST pass through the gateway, which validates the delegation chain, evaluates the policy chain, and generates signed receipts. In deployments where the gateway is the exclusive holder of the target API credentials, the agent cannot bypass the gateway for those privileged actions; this exclusivity is a deployment precondition of the kind Section 9 describes, not an unconditional property of the binding.

Other Bindings This document does not specify an A2A binding. Section 7.3 specifies a binding for OAuth identity-assertion authorization grants. Other protocol bindings are not specified here.

OAuth Identity-Assertion Grant Binding Deployments in which an agent's authority originates from an enterprise authorization system need the delegation chain to begin from that system's grant rather than from an APS-native passport. This section specifies the binding for an OAuth identity-assertion authorization grant , pinned to an identified draft version of that specification. The binding is verifier-first: the importing party verifies the external grant by that specification's own rules before any APS structure is built, and APS records the verification rather than performing it. The record of verification is a caller-signed attestation, an accountability artifact naming the grant reference and the verification time under the importing party's own key, so that the party on the hook for the verification is identifiable. The binding does not re-verify the grant, and a binding result is never collapsed to a single safe-for-execution boolean; it reports what was projected and under what basis. Two anchors are kept separate and MUST NOT be merged. The source grant reference is a digest over a committed preimage of the grant's provenance fields, its issuer, subject, grant identity, client, and audience, and never covers scope, spend, chain content, or receipt content. The delegation chain root is the canonical content digest over the APS-signed hops built under the imported grant. The first identifies where authority came from; the second identifies what was built under it; conflating them makes chain content unrecomputable from the records. Scope projection from the external grant into the APS Scope dimension is lossy, and the binding preserves the grant's authorization details verbatim alongside the projection rather than pretending the projection is complete. A spend dimension MUST NOT be invented at import: because AuthorityDelegationV1 requires all seven facets, an external grant that carries no spend semantics cannot be projected into a conforming chain root unless an importing profile supplies an explicit spend basis accepted by verifier policy; otherwise the projection is unsupported. The grant's audience is carried in the binding but not enforced by it; the relying party at the point of use MUST reject an audience mismatch.

Related Work Several independent efforts, contemporaneous with this document's revisions, have specified adjacent primitives. This section situates them. None is normative here, and the mappings below are informative. PEDIGREE specifies signed JWT delegation chains for workload and agentic identity, with per-parent mandate narrowing: it requires each hop's scopes to be a subset of the immediate parent's, limits token lifetime to the parent's remaining lifetime, and checks chain depth against the parent chain. This is the same narrowing-only rule as the Core Invariants of ; PEDIGREE applies it to scope, lifetime, and depth, while APS applies it across the seven constraint dimensions of Section 3.1. APS also differs in binding the narrowing evidence into signed receipts at each transfer point and in the gateway two-phase execution model, where admissibility is evaluated and evidenced before dispatch. A family of OAuth drafts specifies multi-hop agent delegation natively in that ecosystem. defines the delegation_chain JWT claim as a companion to the act claim of RFC 8693, on the stated grounds that act carries actor identity but not the authorization constraints applied at each hop and is constructed by the Authorization Server without confirmation from the delegating party. The claim is an ordered array of delegation records, each carrying the Authorization Server's attestation and, where present, delegated policy constraints and the delegator's cryptographic confirmation; the attestation and confirmation signatures are computed over an RFC 8785 canonicalization of a named field set. Delegated scope is required to be a subset of the delegator's, and scope expansion across a domain boundary is not permitted. A companion draft defines an authorization details type under Rich Authorization Requests carrying signed evidence of user confirmation and an audit trail: the evidence object is embedded in JWT access tokens and retrieved by reference when opaque tokens are used, and the draft recommends that Resource Servers log evidence information for audit purposes. These specify delegation lineage and consent evidence as OAuth token content, evaluated by Authorization Servers and Resource Servers; APS specifies standalone signed records evaluated at an enforcement point at the time of the action, and separately signs the pre-dispatch admission decision and the post-dispatch outcome as artifacts distinct from the authorization event. The revocation models differ in mechanism: makes descendants of a revoked root invalid by rule, with Resource Servers required to confirm the root authorization remains valid at the time of use, while APS separates current-state validity from signed revocation history and uses a cascade-completion record to evidence closure of the revoked subtree (Section 3.5.1). The same author set frames these as parts of one flow. An integration framework combines cross-domain identity, policy-based authorization, user-consent evidence, and multi-hop delegation into one authorization framework for agents acting on behalf of users, and supplies its policy layer in Rego. The Rego draft draws the audit boundary in its own terms, distinguishing the behaviors a policy permits from evidence of the behaviors actually performed; it recommends that Resource Servers record the policy identifier, a hash or summary of the evaluated input, the result, and the timestamp. The signed admission and outcome records of this document are one interoperable, independently verifiable form of such a record. A best-practices framework maps deployed standards onto agent interactions: it applies the OAuth 2.0 family and the WIMSE workload identity architecture to agent authentication and authorization, states that it defines no new protocols, and identifies gaps to guide future standardization; its policy model and document format are declared out of scope. APS specifies mechanisms in part of the space that framework surveys: the transfer-time narrowing rule across the seven constraint dimensions of , and the signed admission and outcome records evaluated at an enforcement point. The Delegation Receipt Protocol specifies a user-signed delegation receipt carrying scope, a validity window, a hash of the operator instruction, and a model-state commitment, anchored to an append-only log before the agent acts. For multi-agent delegation chains, DRP enforces a narrowing-only rule under which a sub-agent receipt's scope is a strict subset of its parent's, specifies cascade revocation with signed revocation records anchored to the same log, and includes an instruction provenance check against the operator-instruction hash. The designs differ in anchoring: DRP anchors receipts to an external log before execution, while APS evidences the admission decision and the outcome as separate signed records at the gateway. DRP additionally specifies model-state attestation, which this document does not. An identity and delegation framework specifies self-certifying agent identifiers derived from public keys, discovery through indexed metadata, and jointly signed authorization capabilities: a capability is co-signed by the client-side and service-side providers, carries the permitted actions and operational limits (roles, quotas, budgets, time window, audit requirements), and is recommended to be holder-bound with proof-of-possession and expiry. The framework and APS address adjacent layers: it specifies identity bootstrap and per-mission capability establishment between providers, while APS specifies narrowing-only transfer of authority across the seven constraint dimensions of and signs the admission decision and the outcome as separate records at each action. specifies a deterministic, content-addressed action identifier computed over an agent identifier, action type, scope, and timestamp under RFC 8785 canonicalization, such that any party holding the preimage fields can independently recompute the identifier. This matches the External Correlation Form of in preimage fields, canonicalization, hash, timestamp discipline, and lowercase hexadecimal encoding, so the two computations yield equal values for identical field inputs. Both preimages are limited to action-identifying fields. In APS, decision attributes such as policy identity are bound in the signed record (Section 5) rather than folded into the correlation preimage, which keeps the key recomputable by a party that does not hold decision-time state. An architecture document specifies a human identity root, delegation semantics in which nested delegation may pass only a subset of granted authority, and a provenance structure tracing agent actions to the authorizing human; it states that it defines no protocol, wire format, or credential format. The subset rule is a further independent arrival at narrowing-only delegation, stated at the architecture level rather than as a token or record format, and the human identity root corresponds to the principal that APS keeps visible through its beneficiary-attribution model. The record formats, signature scheme, and enforcement-point evaluation that the architecture leaves open are what this document specifies. Two independent drafts each titled Agent Identity Protocol specify different layers under the same name. defines a decentralized identity, delegation, and authorization framework on W3C Decentralized Identifiers, with capability manifests and constraint overlays validated attenuation-only: an overlay may not expand any constraint, and chain validation applies recursive attenuation semantics so each child manifest is a valid attenuation of its parent; prompt injection prevention is stated out of scope. The attenuation-only rule is narrowing-only delegation applied to capability constraints; APS additionally binds the narrowing evidence into signed receipts at each transfer point and separates current-state validity from signed revocation history. specifies registry-anchored agent identifiers with per-action signing and an enforcement proxy interposed between the client and each tool server, evaluating declarative policy to an allow, deny, or hold decision before the tool is reached. The interposition parallels the APS gateway's position in the action path; the models differ in that APS evaluates admissibility against the delegation chain's narrowed constraints and signs the pre-dispatch admission decision and the post-dispatch outcome as distinct records. A parallel set of individual Internet-Drafts develops the surrounding problem space as requirements and evidence-layer documents. A problem statement enumerates nine requirements for cross-organizational agent delegation, among them recursive attenuation, bounded-staleness revocation, and tamper-evident composable audit; it specifies no solution. A companion set specifies pieces of an evidence layer above individual record formats: a content-addressed graph of references to signed artifacts about one action, with an offline relying-party policy replay that returns a sufficiency verdict ; an acceptance mechanism that resolves an issuer's key as valid at issuance so rotation does not break old evidence ; a host-agnostic binding of named-human authorization evidence into an action record ; and a profile binding per-action authorization and memory provenance into an action capsule . These efforts specify requirements and evidence-composition mechanisms, several with their own implementations; APS records are candidate member artifacts for such composition, and each mechanism retains its own verification, acceptance, and sufficiency rules. The requirements overlap with APS mechanisms in part: recursive attenuation with the narrowing rule of Sections 3.1 and 3.2, revocation history and cascade closure with Section 3.5.1, and tamper-evident audit with the signed records of Section 5. Where these efforts define what a cross-organizational solution must satisfy, this document states, per record class, what each record proves and what it does not.

Security Considerations Protocol properties that depend on mediation hold only when all privileged effects pass through the enforcement gateway described in Section 7.1. When agents use an SDK without an external enforcement boundary, those properties depend on agent cooperation. This section considers four attacker classes: adversarial agent, messaging attacker, runtime attacker, and compromised-but-signing agent. Runtime compromise is outside the protocol guarantees. A compromised-but-signing agent is a hijacked agent that produces cryptographically valid signatures over false claims about its own state. Signature verification can succeed because the signing key remains available to the attacker. Addressing this class requires evidence issued outside the compromised agent's trust domain. This document separates proof of possession from key authority (Section 2.1), defines historical and external signer resolution (Sections 2.4 and 2.5), defines separately signed principal bindings and claim levels (Section 2.3), and keeps attestation provenance separate from verification status (Section 2.6). These distinctions constrain what a verifier may conclude from a signed claim. They do not close the attack class. A single-domain deployment remains exposed, and general operationally independent witnessing of agent state remains future work (Section 13). This epistemic boundary extends to signed receipts. The gap between what a cryptographic governance protocol can prove and what it cannot is analyzed in . A signed receipt attests what the policy chain observed and decided. It does not attest ground truth about the external world. A valid receipt signature proves that the issuer attests the receipt's payload; it does not prove the payload corresponds to external fact. Verifiers MUST treat receipts as evidence of what was attested, not as proof of what is true. Signed governance mutations are exposed to a substitution class when an approval signature binds an identifier and a description rather than the mutated content itself. An approver who signs a proposal identifier can have a different proposal body substituted under the same identifier between approval and application. Approval signatures over any governance mutation SHOULD bind the full proposed content and the version transition it applies to, not a reference to them. The normative preimage for specific governance structures is companion work (Section 6); the consideration applies to any signed mutation of standing authority. Where a deployment issues consumable challenge, token, or approval artifacts carrying an expiry (for example, the approval artifact of Section 4.3, or challenge artifacts in a protocol binding), verifiers MUST enforce the expiry, and issuance against an expired or unparseable challenge MUST fail closed. An expiry that is carried but not enforced is equivalent to no expiry. The external correlation form (Section 4.2) hashes fields as supplied by the correlating ecosystem. A matching external action reference is evidence of correlation between records, not of the authenticity, authority, or integrity of either record, and it MUST NOT be treated as an authority claim; correlation strength is bounded by the external ecosystem's own field discipline. The action references of Sections 4.1 and 4.2 are correlation keys, not integrity seals. A reference stored in the same record as its own preimage fields binds nothing against that record's writer: a party able to edit the fields can recompute the reference in the same act. Recomputation detects accidental corruption, and detects alteration only relative to an independently held copy of the reference or of the record. Tamper evidence against a record's writer comes from a signature over the record (Section 5) or from an independently held copy, not from the reference itself. An imported external chain root (Section 7.3) relocates the root of trust for the chain built under it: APS signature verification begins at the first APS-signed hop, and the standing of everything above that hop rests on the importing party's verification of the external grant. The caller-signed verification attestation exists to make that party identifiable; a verifier that accepts imported roots accepts the importing party as a trust anchor for those chains, and SHOULD treat the attestation as the auditable record of that acceptance. A verifier that has not itself verified the external grant under its native rules holds the imported root at the strength of the importer's claim, and an audience check omitted at the point of use can admit a grant outside its intended audience. Every protocol artifact a decoder or verifier receives is untrusted input. Length, count, or size fields carried inside an artifact MUST NOT drive reads or allocation beyond the input actually received: a declared element count that exceeds the remaining input is a decoding error, and a read past the end of the input MUST fail rather than yield default values. Verification interfaces SHOULD handle a structurally malformed artifact through a defined result, whether a return value or a typed error, rather than an unhandled failure, so that malformed input cannot crash a verifier.

Privacy Considerations APS uses persistent identifiers and signed records to support attribution and audit. These records can expose or correlate an agent's principal, authority path, counterparties, action timing, target systems, and referenced evidence across administrative domains, in the sense described by RFC 6973 . Hashing a value does not make it anonymous when the input space is small or available to the observer. Deployments SHOULD disclose only the fields and evidence references needed for the verifier's decision, SHOULD avoid personal data in identifiers and free-text fields, and SHOULD define access and retention policies for passports, delegations, receipts, and evidence records. A receipt signature protects integrity; it does not authorize secondary use or onward disclosure. Where global correlation is unnecessary, profiles SHOULD use context-specific agent and principal identifiers. Key rotation does not prevent correlation when a stable agent identifier, action reference, or delegation lineage remains visible.

IANA Considerations This document has no IANA actions. DID methods are recorded in the W3C DID Specification Registries rather than through IANA. The versioned strings defined or referenced here include provenance tiers, resolution outcomes, principal claim levels, receipt_type values, profile identifiers, and the external correlation label. They are published with the reference implementation; establishing registries for them is future work.

Attribution Axes and Scope APS distinguishes four attribution axes for agentic work. They are distinct because, in multi-party workflows, they may resolve to different entities.

Authority

The delegation chain under which an action was permitted. This document specifies the authority axis in full (Sections 3 and 4).

Contribution

The sources, such as data, models, tools, or prior work product, that fed into a deliverable. This document does not specify a contribution-attribution model.

Principal

The entity on whose behalf, or under whose account, the agent acted. A verifier determines this axis from the selected authority chain and any applicable PrincipalBindingV1 record. It reports the result as self_asserted, principal_attested, or externally_verified_principal under Section 2.3.

Beneficiary

The entity that receives the value, credit, or downstream benefit the work creates. This document does not specify a beneficiary-attribution model.

The protocol must preserve the distinction between principal and beneficiary. An agent may act on behalf of an authorizing principal, such as a consulting firm, to produce a deliverable whose beneficiary is a third party, such as that firm's client. Collapsing the two axes would make this ordinary case unrepresentable. The mechanisms in this document can resolve the authority and principal axes when the referenced delegation and binding material is available. Contribution and beneficiary remain distinct attribution axes, but their normative mechanics are left to companion specifications. The allocation of credit, benefit, compensation, liability, or ownership across beneficiaries is out of scope for this document and is not implied by the authority chain.

Future Work Future work includes a uniform wire vocabulary for verifier claims and evidence states across APS artifacts. This revision defines principal claim levels (Section 2.3), key and evidence resolution outcomes (Sections 2.5 and 5.5), and separate receipt-verification axes (Section 5.6). Generalizing those results into one normative vocabulary remains future work. Cross-implementation profiles for DecisionRefV1 also remain future work. Section 5.4 defines the digest computation, while authority_state, policy_input, and decision_context contain deployment-defined structures. A profile that requires independent recomputation across implementations must define those component schemas and disclosure rules. The contribution-attribution and beneficiary-attribution layers (Section 12) and the normative specification of institutional governance structures (Section 6) remain companion work. Operationally independent witnessing of agent state remains partially addressed. This revision separates proof of possession from signer authority (Sections 2.1, 2.4, 2.5, and 5.2), defines separately signed principal bindings and claim levels (Section 2.3), and keeps attestation provenance separate from verification status (Section 2.6). These mechanisms constrain what a verifier may conclude from signed claims. They do not provide a general witness for the internal state of a compromised-but-signing agent, which remains open.

References Normative References The Unicode Consortium Informative References W3C Credentials Community Group Model Context Protocol Project A2A Project W3C

Implementation Status This section records AEOESS-maintained open-source implementations as of 18 July 2026. It is informative and does not define APS conformance; these results show consistency among AEOESS-maintained artifacts and do not establish independent implementation or adoption. The TypeScript package "agent-passport-system" 4.1.1 (npm) implements the passport and delegation core, the strict RFC 8785 canonicalization and native action-reference computation of Section 4.1, key resolution, the OAuth identity-assertion grant adapter, a regulated-action verifier, and selected signed evidence records. The passport and delegation records it emits predate the wire formats of Sections 2.1 and 3.1 of this revision. The Python package "agent-passport-system" 2.9.0 (PyPI) and the Go repository at https://github.com/aeoess/agent-passport-go implement subsets of those mechanisms, centered on verification, issuance, and the action-reference computation; they are not complete implementations of this revision. The npm package "agent-passport-system-mcp" 3.3.1 exposes protocol tools and adapter surfaces; the enforcement gateway described in Section 7.1 is a separate deployment component and is not part of the published packages. No A2A binding is specified by this document, and the released A2A adapter code is experimental. Known deviations in the released implementations, as of the versions above: the TypeScript emitters for Revocation-Observation and Evidence-Bundle records compute signatures and member digests over the project's legacy canonicalization rather than the RFC 8785 profile specified in this document, and verifiers of those records validate over the same form. The two canonicalizations differ only in the treatment of null-valued object members, which the legacy form omits; the Revocation-Observation record as emitted carries no null-valued members, so its signed bytes coincide with RFC 8785 for that record, while Evidence-Bundle member payloads are free-form and can differ. A future release is expected to migrate both emitters. The released implementations do not yet emit the common receipt envelope of Section 5.1 as a shared cross-language format, do not publish a decision_ref computation carrying all properties described in Section 5.4, and sign only the scope, spend, depth, and time dimensions in delegation records; Values, Reputation, and Reversibility are enforced as policy inputs rather than signed delegation coordinates in the released versions. The strict RFC 8785 canonicalization core is checked in continuous integration for byte-identical output against independent RFC 8785 implementations. The native action-reference computation has been exercised across the TypeScript, Python, and Go implementations using shared known-answer vectors, and a conformance fixture set is published at https://github.com/aeoess/aps-conformance-suite. Current versions and conformance results are maintained at the project repository: https://github.com/aeoess/agent-passport-system.