Agent Passport System (APS): Verifiable Authority, Lifecycle, Enforcement, and Evidence for AI Agents
draft-pidlisnyi-aps-04
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Tymofii Pidlisnyi | ||
| Last updated | 2026-09-28 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
Additional Web Page |
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-pidlisnyi-aps-04
Individual Submission T. Pidlisnyi
Internet-Draft Agent Passport System
Intended status: Informational 28 September 2026
Expires: 1 April 2027
Agent Passport System (APS): Verifiable Authority, Lifecycle,
Enforcement, and Evidence for AI Agents
draft-pidlisnyi-aps-04
Abstract
This document specifies the Agent Passport System (APS), a protocol
for representing and evaluating authority exercised by AI agents.
APS separates agent identity, represented principal, delegated
authority, policy approval, admission to dispatch, observed results,
and external effects. It defines cryptographic identity and
principal records, monotonic delegation, revocation and authority-
lifecycle semantics, deterministic action and decision references,
signed governed-action records, verifier outcomes, evidence
resolution, profiles, and protocol bindings.
APS defines how an enforcement boundary rechecks current authority
before admitting an action to dispatch, and how a verifier
distinguishes what a signed record establishes from claims that
remain unresolved or external to the protocol. Requirements are
split into APS Core, which every conforming implementation carries,
and Candidate features, which an implementation opts into by naming
them in its claim, and most of the lifecycle and decision-to-effect
material in this document is Candidate rather than Core. Candidate
features specify additional lifecycle and decision-to-effect behavior
without making those features requirements of APS Core conformance.
Implementation and conformance sections identify which requirements
have exact conformance-vector coverage and which are implemented by
the reference implementations. APS does not treat a valid signature,
receipt, or delegation chain as proof of external truth or of the
absence of an out-of-band execution path.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Pidlisnyi Expires 1 April 2027 [Page 1]
Internet-Draft APS September 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 1 April 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 8
2. Authority and Verification Model . . . . . . . . . . . . . . 8
2.1. Actors . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2. Seven Distinctions . . . . . . . . . . . . . . . . . . . 10
2.3. Admissibility . . . . . . . . . . . . . . . . . . . . . . 12
2.4. Evidence . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5. The Mediation Assumption . . . . . . . . . . . . . . . . 17
2.6. Transition Contract . . . . . . . . . . . . . . . . . . . 18
3. Identity Scheme . . . . . . . . . . . . . . . . . . . . . . . 27
3.1. Agent Passport . . . . . . . . . . . . . . . . . . . . . 27
3.2. Agent Identifiers . . . . . . . . . . . . . . . . . . . . 28
3.3. Principal Binding . . . . . . . . . . . . . . . . . . . . 28
3.4. Key Rotation and Historical Verification . . . . . . . . 29
3.5. Key Resolution for External and Evidence Signers . . . . 30
3.6. Attestation Provenance and Composition . . . . . . . . . 31
4. Delegation and Authority Attenuation . . . . . . . . . . . . 32
4.1. Faceted Authority Attenuation . . . . . . . . . . . . . . 32
4.2. Component Orders . . . . . . . . . . . . . . . . . . . . 33
4.3. Chain Verification . . . . . . . . . . . . . . . . . . . 34
4.4. Cumulative Spend Across a Delegation Subtree . . . . . . 36
4.5. Revocation and Cascade . . . . . . . . . . . . . . . . . 36
4.5.1. Revocation Evidence . . . . . . . . . . . . . . . . . 37
4.5.2. Revocation Record Format . . . . . . . . . . . . . . 38
4.6. Core Invariants . . . . . . . . . . . . . . . . . . . . . 42
Pidlisnyi Expires 1 April 2027 [Page 2]
Internet-Draft APS September 2026
5. Policy Chain . . . . . . . . . . . . . . . . . . . . . . . . 42
5.1. Action Reference Computation . . . . . . . . . . . . . . 44
5.2. Legacy External Correlation Form . . . . . . . . . . . . 45
5.3. Two-Phase Execution . . . . . . . . . . . . . . . . . . . 47
6. Profile Model . . . . . . . . . . . . . . . . . . . . . . . . 47
6.1. What a Profile Identifies . . . . . . . . . . . . . . . . 48
6.2. Profiles at the Extension Points . . . . . . . . . . . . 50
7. Governed Action Records . . . . . . . . . . . . . . . . . . . 54
7.1. ReceiptV1 Envelope . . . . . . . . . . . . . . . . . . . 54
7.2. Receipt Identifiers and Signatures . . . . . . . . . . . 55
7.3. Core Receipt Types . . . . . . . . . . . . . . . . . . . 56
7.3.1. Action Intent . . . . . . . . . . . . . . . . . . . . 57
7.3.2. Policy Decision . . . . . . . . . . . . . . . . . . . 57
7.3.3. Action Result . . . . . . . . . . . . . . . . . . . . 58
7.4. DecisionRefV1 . . . . . . . . . . . . . . . . . . . . . . 59
7.5. Evidence Resolution . . . . . . . . . . . . . . . . . . . 60
7.6. Receipt Verification . . . . . . . . . . . . . . . . . . 60
8. Authority Lifecycle . . . . . . . . . . . . . . . . . . . . . 62
8.1. Concepts . . . . . . . . . . . . . . . . . . . . . . . . 64
8.2. Authority Continuity Rules . . . . . . . . . . . . . . . 68
8.2.1. L1. Revoking an Ancestor Invalidates the Authority
That Depends on It . . . . . . . . . . . . . . . . . 69
8.2.2. L2. Identity Continuity Does Not Imply Authority
Continuity . . . . . . . . . . . . . . . . . . . . . 69
8.2.3. L3. Reauthorization Creates New Authority . . . . . 70
8.2.4. L4. A Successor Does Not Inherit the Predecessor's
Delegation Tree . . . . . . . . . . . . . . . . . . . 72
8.2.5. L5. Independent Chains Are Not Combined . . . . . . 72
8.2.6. L6. An Earlier Approval Is Not Current Authority . . 73
8.2.7. L7. Unknown Revocation State Is Not Active . . . . . 74
8.2.8. L8. Suspension Is Not Revocation . . . . . . . . . . 75
8.2.9. L9. Key Rotation Is Not Delegation Revocation . . . 76
8.2.10. L10. Expiry Is Not Revocation . . . . . . . . . . . 77
8.2.11. L11. No Silent Authority Resurrection . . . . . . . 78
8.2.12. L12. Completeness Is a Separate and Stronger
Claim . . . . . . . . . . . . . . . . . . . . . . . . 78
8.3. Lifecycle Mechanisms . . . . . . . . . . . . . . . . . . 79
8.3.1. Activation Conditions . . . . . . . . . . . . . . . . 79
8.3.2. Purpose Bounds and Exhaustion . . . . . . . . . . . . 83
8.3.3. Capability Binding and Policy Version . . . . . . . . 85
8.3.4. Authority Epoch and Fencing . . . . . . . . . . . . . 89
8.3.5. Suspension, Cause Sets and Release . . . . . . . . . 92
8.3.6. Status Sources, Freshness and Coverage . . . . . . . 95
8.3.7. Succession, Handover and Reauthorization . . . . . . 98
8.3.8. Principals, Identities and What Changes When a Person
Leaves . . . . . . . . . . . . . . . . . . . . . . . 101
8.4. Candidate Lifecycle Extensions . . . . . . . . . . . . . 103
Pidlisnyi Expires 1 April 2027 [Page 3]
Internet-Draft APS September 2026
8.4.1. CAND-01: An External Event Is Authority-Changing Only
When Established . . . . . . . . . . . . . . . . . . 104
8.4.2. CAND-02: Later Evidence Does Not Rewrite Earlier
Evidence . . . . . . . . . . . . . . . . . . . . . . 105
8.4.3. CAND-03: Issuance Validity, Later Attached Effects and
Current Validity Are Three Separate Findings . . . . 105
8.4.4. CAND-06: Collective Authority Must Satisfy Its Declared
Composition . . . . . . . . . . . . . . . . . . . . . 106
8.4.5. CAND-09: Chain Validity Is Not Permission to
Execute . . . . . . . . . . . . . . . . . . . . . . . 107
8.4.6. CAND-11: A Valid Grant Can Be Unexecutable . . . . . 107
8.4.7. CAND-12: Ending Authority Bounds Future Effects and
Does Not Undo Past Ones . . . . . . . . . . . . . . . 108
8.4.8. BROAD-L6: Every Authorization Boundary the Operation
Requires . . . . . . . . . . . . . . . . . . . . . . 108
9. Decision to Effect . . . . . . . . . . . . . . . . . . . . . 109
9.1. Relations Between a Decision and an Effect . . . . . . . 110
9.2. The Exact Call . . . . . . . . . . . . . . . . . . . . . 112
9.3. Bypass and the Mediation Assumption . . . . . . . . . . . 113
9.4. Effect Verification . . . . . . . . . . . . . . . . . . . 114
9.5. When the Evidence Is Not Enough . . . . . . . . . . . . . 115
9.6. Execution States That Are Not Synonyms . . . . . . . . . 116
9.7. An Indeterminate Result After Dispatch . . . . . . . . . 118
9.8. The Reservation and Retry Contract . . . . . . . . . . . 119
9.9. Chain Validity Is Not Permission to Execute . . . . . . . 120
9.10. A Valid Grant Can Be Unexecutable . . . . . . . . . . . . 121
9.11. Worked Examples . . . . . . . . . . . . . . . . . . . . . 122
9.11.1. A Purchasing Grant Narrowed by a Subagent . . . . . 122
9.11.2. An Employee Leaves with In-Flight Descendant Work . 126
9.11.3. Two Independent Holds and One Clears . . . . . . . . 130
9.11.4. A Cross-Org Action Needing Separate Human Approval and
One-Time Admission . . . . . . . . . . . . . . . . . 134
9.11.5. A Post-Dispatch Unknown That Cannot Be Retried . . . 137
10. Institutional Governance as an Authority-Source Model . . . . 140
10.1. Charter, Office, Holder, Root Authority Basis, Delegation,
Action . . . . . . . . . . . . . . . . . . . . . . . . . 140
10.2. Monotonic Projection . . . . . . . . . . . . . . . . . . 141
10.3. Departure and Succession . . . . . . . . . . . . . . . . 142
10.4. Handover . . . . . . . . . . . . . . . . . . . . . . . . 142
10.5. Break-Glass . . . . . . . . . . . . . . . . . . . . . . 143
10.6. Re-Rooting . . . . . . . . . . . . . . . . . . . . . . . 144
10.7. What This Section Does Not Establish . . . . . . . . . . 144
11. Protocol Bindings . . . . . . . . . . . . . . . . . . . . . . 144
11.1. MCP Binding . . . . . . . . . . . . . . . . . . . . . . 144
11.2. Other Bindings . . . . . . . . . . . . . . . . . . . . . 145
11.3. OAuth Identity-Assertion Grant Binding . . . . . . . . . 145
11.4. Adapter Contracts . . . . . . . . . . . . . . . . . . . 146
Pidlisnyi Expires 1 April 2027 [Page 4]
Internet-Draft APS September 2026
11.4.1. What an Adapter Must Do With a Dimension It Cannot
Carry . . . . . . . . . . . . . . . . . . . . . . . . 147
11.4.2. Model Context Protocol . . . . . . . . . . . . . . . 148
11.4.3. Agent2Agent . . . . . . . . . . . . . . . . . . . . 149
11.4.4. OAuth Identity-Assertion Authorization Grant . . . . 149
11.4.5. Authorization API . . . . . . . . . . . . . . . . . 151
11.4.6. Workload and Agent Identity Credentials . . . . . . 152
11.4.7. Transparency Service Carriage . . . . . . . . . . . 153
11.5. A2A Agent Card Signing . . . . . . . . . . . . . . . . . 153
11.5.1. What Was Observed . . . . . . . . . . . . . . . . . 154
11.5.2. What the APS Canonical-Bytes Vectors Cover . . . . . 155
11.6. Gateway Extension Processors . . . . . . . . . . . . . . 155
12. Enforcement Gateway Reference Architecture . . . . . . . . . 157
12.1. Judge and Executor . . . . . . . . . . . . . . . . . . . 157
12.2. Admission, Consumption, Reservation and Settlement . . . 158
12.3. Evidence the Boundary Produces . . . . . . . . . . . . . 159
12.4. Ancestor Revocation at the Boundary . . . . . . . . . . 160
12.5. What the Gateway Does Not Do . . . . . . . . . . . . . . 160
13. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 161
13.1. Conformance Classes . . . . . . . . . . . . . . . . . . 161
13.2. Requirement Identifiers . . . . . . . . . . . . . . . . 165
13.3. Core and Candidate . . . . . . . . . . . . . . . . . . . 166
13.4. Conformance Claims . . . . . . . . . . . . . . . . . . . 168
13.5. Per-Vector Results . . . . . . . . . . . . . . . . . . . 169
13.6. What a Passing Run Does Not Establish . . . . . . . . . 171
14. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 172
14.1. Capability Map . . . . . . . . . . . . . . . . . . . . . 179
15. Security Considerations . . . . . . . . . . . . . . . . . . . 184
15.1. Corpus Failure Classes and the Assumptions They
Defeat . . . . . . . . . . . . . . . . . . . . . . . . . 186
16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 189
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 190
18. Attribution Axes and Scope . . . . . . . . . . . . . . . . . 190
19. Limits and Open Questions . . . . . . . . . . . . . . . . . . 191
19.1. Known Protocol Limits . . . . . . . . . . . . . . . . . 191
19.2. Open Design Questions . . . . . . . . . . . . . . . . . 192
19.2.1. Teardown Completeness . . . . . . . . . . . . . . . 193
19.2.2. Work in Flight . . . . . . . . . . . . . . . . . . . 194
19.2.3. Release from Suspension . . . . . . . . . . . . . . 195
19.2.4. Critical Revocation . . . . . . . . . . . . . . . . 196
19.2.5. Office Vacancy and Succession . . . . . . . . . . . 197
19.2.6. Grants Signed Just Before a Departure . . . . . . . 198
19.2.7. Authority Rollback . . . . . . . . . . . . . . . . . 199
19.2.8. Semantic Drift . . . . . . . . . . . . . . . . . . . 200
19.2.9. Notice and Relying Parties . . . . . . . . . . . . . 201
19.2.10. Associating a Principal with an Accepted
Authority . . . . . . . . . . . . . . . . . . . . . . 202
19.2.11. A Durable Record of Admission . . . . . . . . . . . 203
Pidlisnyi Expires 1 April 2027 [Page 5]
Internet-Draft APS September 2026
19.2.12. Recovery Across Consumption, Reservation and
Dispatch . . . . . . . . . . . . . . . . . . . . . . 204
19.2.13. Whether Holding a Scope Establishes Authority to
Confer It . . . . . . . . . . . . . . . . . . . . . . 205
19.2.14. When a Recorded Lifecycle Change Becomes
Effective . . . . . . . . . . . . . . . . . . . . . . 205
19.2.15. Ending Authority Without Issuer Standing . . . . . . 206
19.2.16. Two Items Held Out of This Revision . . . . . . . . 207
19.2.17. Four Designs Under Consideration . . . . . . . . . . 208
20. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 209
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 210
21.1. Normative References . . . . . . . . . . . . . . . . . . 210
21.2. Informative References . . . . . . . . . . . . . . . . . 211
Appendix A. Implementation Status . . . . . . . . . . . . . . . 218
A.1. Implemented and Exercised . . . . . . . . . . . . . . . . 219
A.2. Specified but Not Implemented . . . . . . . . . . . . . . 220
A.3. Implementation-Specific Behavior . . . . . . . . . . . . 222
A.4. Known Deviations . . . . . . . . . . . . . . . . . . . . 223
Appendix B. Changes from -03 . . . . . . . . . . . . . . . . . . 224
B.1. New Sections . . . . . . . . . . . . . . . . . . . . . . 224
B.2. Changes Carried From -03 . . . . . . . . . . . . . . . . 225
B.3. Conventions Introduced by This Revision . . . . . . . . . 228
Appendix C. Case and Rule Provenance Index . . . . . . . . . . . 228
C.1. Rule and Case Provenance Index . . . . . . . . . . . . . 229
C.2. Eighteen Cases in Full . . . . . . . . . . . . . . . . . 232
C.3. Boundary Cases . . . . . . . . . . . . . . . . . . . . . 251
Appendix D. Requirement Matrix . . . . . . . . . . . . . . . . . 252
D.1. Requirements of This Revision . . . . . . . . . . . . . . 253
D.2. Map From the Suite Requirement Identifiers . . . . . . . 265
D.3. Families Named in Status Blocks . . . . . . . . . . . . . 268
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 271
1. Introduction
This document specifies the Agent Passport System (APS), a protocol
for identifying AI agents, narrowing delegated authority at each
transfer point, deciding and admitting individual actions at an
enforcement boundary, and recording signed evidence of what was
decided and what was observed.
APS defines an authority and verification model that keeps identity,
authority, approval, admission, execution and external effect apart.
It defines Ed25519 agent passports and separately signed principal
bindings. It defines delegation chains that a verifier rejects when
authority widens across scope, spend, depth, time, reputation,
values, or reversibility. It defines the lifecycle states an
authority artifact can hold and the verdicts a verifier may report
about them. It defines deterministic action and decision references,
Pidlisnyi Expires 1 April 2027 [Page 6]
Internet-Draft APS September 2026
a common envelope for the signed records of a governed action, and
bindings for Model Context Protocol tool calls and imported OAuth
identity-assertion authorization grants.
A verification result keeps cryptographic integrity, signer
authority, referenced-artifact resolution, policy semantics, and
external truth on separate axes. Sections labelled Candidate are
specified in this document rather than against a prior published
rule. Their status blocks name related fixture families, and
Appendix D is the sole authority for which requirements an exact
vector exercises. An Implementation Status section states the
coverage of the available open-source implementations.
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) revocation that invalidates every chain depending on
a revoked delegation, with revocation records, where produced, and
optional cascade evidence carried as evidence of processing rather
than as the cause of that invalidity, (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.
Pidlisnyi Expires 1 April 2027 [Page 7]
Internet-Draft APS September 2026
The protocol's formal invariants and design rationale are published
in the informative references. At the time of writing no IETF
working group is chartered for AI agent identity or agentic
authorization: WIMSE is chartered for workload identity, where a
workload is a running instance of software executing for a specific
purpose [IETF-WIMSE-CHARTER], and carries one agent-specific document
[AIMS], the proposed DAWN charter places identity management of AI
agents, tools and skills out of scope [IETF-DAWN-CHARTER], and the
proposed agentproto charter commits its reference architecture to
reusing existing identity, authentication and authorization building
blocks rather than defining new ones [IETF-AGENTPROTO-CHARTER]. 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.
1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Authority and Verification Model
This section names the parties this document talks about, the
distinctions the rest of the document enforces, and what a verifier
is allowed to say. It is placed before any wire format because every
later section is written against it.
Two labels appear throughout. *Core* marks a requirement of APS Core
conformance. It is mandatory for an implementation claiming the
conformance class to which the requirement applies, and Section 13.1
maps each identifier area to its classes. *Candidate* marks an opt-in
feature. A Candidate requirement is normative for an implementation
that claims the feature and is not a requirement of APS Core
conformance. A conformance claim names the classes it claims and the
Candidate features it claims, in the form "APS Core in the named
classes, plus named features", as Section 13.4 states. A Candidate
label is not a claim that any deployment uses the rule.
Normative requirements introduced outside the closed core carry
stable semantic identifiers of the form APS-AREA-NAME, listed with
each subsection and mapped in Appendix D. An identifier never
changes because a section moves and is never reused.
Pidlisnyi Expires 1 April 2027 [Page 8]
Internet-Draft APS September 2026
2.1. Actors
Nine roles appear in this document. A deployment can put several of
them in one component or split one across several.
Principal The person, office, or organization on whose behalf
authority exists. A principal binding record names the principal
an agent acts for, signed by the principal and scoped to named
audiences and authority profiles rather than asserted for every
purpose (Section 3.3).
Authority issuer The party that signs a delegation, creating or
narrowing authority for the party below it. In a chain each
issuer holds the parent grant (Section 4.3). The issuer and the
principal can be different parties.
Acting agent The agent that declares an intended action and, once
admitted, executes it. It is identified by an Agent Passport
(Section 3.1) and named as subject_agent on the records of a
governed action (Section 7.1).
Delegate An agent holding authority received from another agent
rather than from the principal directly. What a delegate can hold
is bounded facet by facet by the grant above it (Section 4.1).
Policy decision point The component that evaluates one action
against the selected authority chain and the applicable policy and
returns permit, deny, or narrow. In this document it is the
deterministic gate plus the advisory evaluation path (Section 5).
It may be a separate component from the enforcement boundary.
Enforcement boundary The component that issues the policy-decision
record (Section 7.3.2) and the action-result record
(Section 7.3.3), consumes the approval at the next authorization
boundary, applies the state current at that moment, and completes
any spend reservation (Section 5.3). Only the enforcement
boundary admits an action to dispatch. A policy decision point
may compute the decision, and the boundary is the issuer of the
record that carries it. Approval consumption, reservation,
dispatch and the external effect are not one atomic transaction in
this revision, and Section 19.2.11 records what that leaves open.
Target system The system the action operates on. It appears in the
action input object hashed into action_ref (Section 5.1). This
document specifies no interface to it and no obligation on it.
Evidence issuer A party outside the delegation chain that signs an
Pidlisnyi Expires 1 April 2027 [Page 9]
Internet-Draft APS September 2026
artifact a verifier may resolve, for example an attesting service
or a counterparty system. Keys for such signers resolve under a
model separate from an agent's own key (Section 3.5), and what
resolution reports is its own axis (Section 7.5).
Verifier Any party that reads these artifacts and reports what it
can establish from them. Its obligations are stated for chains in
Section 4.3 and for records in Section 7.6.
This subsection defines terms and states no requirement, so it
carries no status block. It does not establish that any deployment
has all nine roles, does not require any two of them to be distinct
components, and does not say which party operates which.
2.2. Seven Distinctions
Each distinction below is enforced by the section named with it.
This subsection adds no requirement of its own. It exists because
the seven collapses it names are the ones that make a verifier report
more than it established.
*Identity is not authority.* An Agent Passport is a self-signed
record, and checking its signature establishes that the holder
controlled the key at signing time. What the agent may do comes from
somewhere else: a delegation chain whose facets narrow at every hop
(Section 4.1) and a principal binding scoped to named audiences and
authority profiles (Section 3.3). A passport that resolves and a
signature that checks leave the authority question untouched. This
does not establish that an agent holding no APS chain has no
authority under some other system, only that this document gives it
none.
*Cryptographic validity is not signer authority.* A valid signature
establishes that an authorized signing key attested to the canonical
record body. It does not establish that an external event occurred
or that a signed claim is true (Section 7.2). Whether the signer
held authority is resolved separately, at the artifact's own issuance
time, and for parties outside the chain under a separate model
(Section 3.5). A record can be internally consistent and correctly
signed while the decision it names is not the decision a verifier is
holding. The receipt-decision-relation family makes that gap
executable as a rejection with a named reason rather than leaving it
to inference.
*Authority is not approval.* Authority is standing held over an
interval. An approval is one decision about one action, bound to the
action_ref it approves, single use, and time bounded (Section 7.3.2).
A valid chain does not carry an approval and an approval does not
Pidlisnyi Expires 1 April 2027 [Page 10]
Internet-Draft APS September 2026
extend a chain. This does not establish an ordering between the two:
a chain can be valid with no approval ever issued, and an approval
can be stale while the chain under it still stands.
*Approval is not admission.* A permit or narrow policy-decision
record exists from the moment the boundary issues it and admits
nothing until the next authorization boundary consumes it. At that
boundary the enforcement boundary rechecks temporal validity and
revocation state, consumes the approval identity atomically, and
completes any spend reservation (Section 5.3). An approval that has
expired, has already been consumed, or fails the recheck admits
nothing. Whether a given approval was in fact consumed is boundary
state keyed by its identity and is not content of any record, so a
verifier without access to that state reports the approval-state axis
as not established (Section 7.6).
*Admission is not execution.* Admission is the boundary's act.
Execution is what the target system then does. They are separate
states, and in this revision admission is enforcement-boundary state
with no durable record, per Section 9 and Section 19.2.11. The
action-result record carries its own issued_at, which can fall after
the consumed decision's validity window closes, because execution and
observation take time (Section 7.3.3). A decision record held on its
own says nothing about whether the action ran. The accountability-
record family carries the boundary decision and the executed flag as
independent fields and keeps a vector in which the decision is deny
and the action executed anyway.
*Observed outcome is not external effect.* An action-result record
attests to what the enforcement boundary observed after dispatch, and
external occurrence or settlement requires separately resolved
evidence (Section 7.3.3). A status of unknown is a real outcome
rather than a missing one. Agreement between an APS record and a
record produced outside the deployment is evidence of correlation
between records, not of the authenticity, authority, or integrity of
either record (Section 5.2).
*Evidence of a claim is not its truth.* An evidence reference is a
commitment, not evidence availability (Section 7.5). Resolving it
establishes that the bytes the artifact's own rules select hash to
the committed digest. Whether the artifact's content is true is
outside what resolution reports, and a verifier does not report a
record fully valid for a claim that depends on evidence it never
resolved. The read-fidelity-receipt family is the plainest case in
the corpus: the record commits to sampled readback at a stated n,
carries no pass threshold, and leaves the consumer to judge k of n.
Pidlisnyi Expires 1 April 2027 [Page 11]
Internet-Draft APS September 2026
What this subsection does not establish. It states no requirement,
adds nothing to the sections it points at, and does not establish
that the seven are exhaustive. It is a reading guide over text that
is normative elsewhere.
2.3. Admissibility
A record defined in this document describes what a verifier may
conclude from the artifacts it holds. It does not describe what
happened. Two verifiers holding different artifacts about one action
can reach different conclusions without either being wrong, and
neither conclusion is a statement about the world.
An artifact verdict is what a verifier says about one authority
artifact at one moment. The set is closed and has six members.
valid The verifier establishes that the artifact currently confers
the authority claimed.
invalid The verifier establishes that it does not, or no longer
does. Revoked, expired, exhausted, void from issuance, and
dependent on an invalid ancestor all land here, separated by
reason code.
not established The verifier cannot reach a conclusion. This is
ignorance. It is never a finding about the world and never the
negation of the claim.
not yet effective The verifier establishes that the artifact was
validly issued and that an enabling condition has not occurred
yet. The remedy is to wait, not to find a better source. The
activation conditions of Section 8.3.1 are the only route to this
verdict in this revision. A wait carried by the time facet
instead returns invalid with a not-yet-valid reason from
Section 4.3, and that subsection records the two verdicts side by
side rather than resolving them.
suspended Use is paused by one or more live causes, each separately
releasable.
restricted Authority continues in reduced form under a live
constraint that does not pause it.
A verifier MUST report a verdict from that set and MUST NOT report a
verdict outside it. Every verdict MUST carry a reason code. Two
findings that share a verdict name and differ in substance MUST carry
different reason codes, because a result that reports only verdict
names cannot be read.
Pidlisnyi Expires 1 April 2027 [Page 12]
Internet-Draft APS September 2026
A verifier MUST NOT report not established for a conclusion it has
reached. Where the conclusion is negative, the shape of the negative
decides the output. An enabling condition established not to have
occurred yet is the verdict not yet effective, reason code
ENABLING_CONDITION_NOT_YET_OCCURRED. A composition rule established
not to be satisfied denies the action at the boundary, reason code
COMPOSITION_NOT_SATISFIED. A pinned referent established to have
changed denies the action at the boundary, reason code
PINNED_REFERENT_MISMATCH. Neither of the last two makes any artifact
invalid.
Unexecutable is not a seventh verdict. An artifact whose target,
executor, or named capability no longer exists keeps its verdict and
fails at execution, with the unresolvable referent recorded.
The rest of this subsection is informative. What an enforcement
point decides about one action at one authorization boundary is a
boundary outcome, a different subject with its own three values:
authorized, denied with a stated reason, or not established. No
conformance family in the Agent Authority Conformance suite decides
an outcome by these names, so this document states them as vocabulary
and places no requirement on them.
A third axis is the chain-verification result of Section 4.3, whose
closed set is valid, invalid, indeterminate and unsupported. It is a
finding about one selected root-to-leaf chain rather than about one
artifact or one action, and the three axes are never mixed. A chain
result of valid supports the artifact verdict valid for the artifacts
on that chain and supports no boundary outcome on its own. A chain
result of invalid supports the artifact verdict invalid. A chain
result of indeterminate is carried as indeterminate on its own axis.
Where a verifier also reports an artifact verdict for the artifacts
on such a chain, that verdict is not established, naming the source
limb where no accepted answer was available and the freshness limb
where the answer was past its declared bound. Neither value is
collapsed into valid, and the chain result is not replaced by the
artifact verdict. A chain result of unsupported is carried as
unsupported and is neither erased nor folded into any other value on
any axis.
Also informative: a not established verdict is unreadable unless it
says which limb was missing. Three limbs are proposed. Source means
no source the authority model accepts produced a usable answer, or
the answer came from a source the model does not accept for that
state, or two accepted sources are in unresolved conflict. Freshness
means an answer existed but was older than the bound the model
declares for its source. Coverage means the claim does not state
that it covers what the verdict needed. The verdict set of this
Pidlisnyi Expires 1 April 2027 [Page 13]
Internet-Draft APS September 2026
subsection places no requirement on the limbs. The Candidate
features that name limbs do place one on an implementation claiming
them, at Section 8.1, Section 8.3.3 and Section 8.2.12. No
conformance family names a limb on a verdict. The reference SDK
modules enforce the rule at construction, which is an implementation
choice and not a conformance obligation.
What this subsection does not establish. The verdict set says what a
verifier may report, not what is true of the authority. A valid
verdict means the verifier establishes that the artifact currently
confers the authority claimed, against the checks that verifier ran,
and which checks those were is a separate question this subsection
does not answer. Two of the six members, suspended and not yet
effective, are not decided by any family cited in this section. The
distinction between a finding that something is false and a finding
that it is not established is carried by the verdict name and by
nothing else here.
Requirements. APS-EVID-VERDICT-SET-CLOSED, a verifier reports a
verdict from the closed six-member set and reports none outside it,
exercised. APS-EVID-REASON-CODE-REQUIRED, every verdict carries a
reason code and two findings sharing a verdict name carry different
codes, specified, not exercised. APS-EVID-NOT-ESTABLISHED, a
verifier does not report not established for a conclusion it has
reached, and an established negative takes the shape its own subject
gives it, specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: lifecycle-evidence-and-record, whose runners fail
any vector returning a verdict outside the closed set, across its 12
cases. revocation-resolution-forward-compat, 14 cases. Exercised
requirements: APS-EVID-VERDICT-SET-CLOSED. Implemented requirements:
APS-EVID-VERDICT-SET-CLOSED, APS-EVID-REASON-CODE-REQUIRED, APS-EVID-
NOT-ESTABLISHED. Related implementation surfaces: lifecycle-state
module in agent-passport-system 7.2.0 (npm) and agent-passport-system
4.2.0 (PyPI), experimental and opt-in.
2.4. Evidence
Linkage and correlation each establish one narrow thing. A prev
reference cryptographically links one record body to a claimed
predecessor. It does not establish wall-clock ordering,
completeness, or the absence of omitted records without an external
log or sequencing mechanism (Section 7.2). A matching external
action reference is evidence of correlation between records, not of
the authenticity, authority, or integrity of either record, and
correlation strength is bounded by the external ecosystem's own field
Pidlisnyi Expires 1 April 2027 [Page 14]
Internet-Draft APS September 2026
discipline (Section 5.2). An action reference is a correlation key
rather than an integrity seal, and tamper evidence against a record's
writer comes from a signature over the record or from an
independently held copy.
Later findings do not rewrite earlier records. A record of a
decision states what its issuer decided on the record available at
that instant. A verifier MUST NOT change what such a record states
because of anything learned afterwards, including a finding that an
ancestor of the chain was never validly issued. Whether the
authority stands now is a separate question with its own answer,
reported as its own finding.
A digest mismatch has two subjects and two results. Where a record's
bytes do not match the digest under which it was recorded, the
presented bytes do not establish the evidence claim, and a verifier
MUST NOT read their content as a finding. The containing record's
required-evidence axis is invalid, because the commitment that record
carries mismatched, as Section 7.5 states.
Evidence strength is a verifier appraisal. This document defines no
assurance level, no strength score, and no threshold at which
evidence becomes sufficient. The read-fidelity-receipt family is
built that way on purpose: the record carries the sampled result and
no pass threshold, and the consumer judges it.
An evidence attestor is whoever produced or signed a piece of
evidence, and in what role. A boundary attesting an execution makes
a different claim from an issuer signing a grant, and the attestor's
key has its own lifecycle, resolved outside the record (Section 3.5).
In the accountability-record family a record carries the signer's
identifier and not a key, and the signature says nothing until a
resolver binds that identifier to a key.
Three further requirements on what a verdict record carries are
proposed in the authority lifecycle work and are stated here as
informative prose, because no conformance family exercises any of
them.
* Verdict coverage. Where the authority model publishes a class
list of authority-changing events, a verdict would record, for
each class on that list, whether it was checked and against which
source. Where the model publishes no such list, the verdict would
record that no event-class coverage was claimed. Tested by
nothing.
Pidlisnyi Expires 1 April 2027 [Page 15]
Internet-Draft APS September 2026
* Chain validity against relying party knowledge. Whether a chain
is currently valid and whether a particular party had notice of a
change are separate findings, and a verdict record would carry a
notice finding with its own timestamp or record that it has none.
Tested by nothing.
* Declared scope against the enforcing boundary. A declared scope
is only as effective as the boundary that enforces it. A verifier
that cannot establish that the enforcement boundary implements a
grant's declared scope would not report the narrower scope as
established, because documented scope and reachable scope are
separate facts needing separate evidence. Tested by nothing. The
accountability-record family records the matching limitation on
itself as a non-goal: it does not check that an action's scope is
covered by the delegation it names.
What this subsection does not establish. It does not establish that
available evidence is complete, and showing that individual records
are authentic is weaker than establishing that every relevant event
was observed. It does not establish that an attestor's claim is
true, only which party made it and under which key. It places no
requirement on the three proposed carriage rules above, and it does
not establish that a record's silence on a claim is a denial of that
claim.
Requirements. APS-EVID-NO-RETROACTIVE-REWRITE, a verifier does not
change what a decision record states because of anything learned
afterwards, exercised by lifecycle-evidence-and-record LC-G-006-b,
LC-G-006-c, LC-G-006-d and LC-G-006-e. APS-EVID-DIGEST-MISMATCH-NOT-
ESTABLISHED, bytes that do not match the digest under which they were
recorded do not establish the evidence claim and their content is not
read as a finding, while the containing record's required-evidence
axis is invalid per Section 7.5, exercised by lifecycle-evidence-and-
record LC-G-006-f.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: lifecycle-evidence-and-record, accountability-
record, read-fidelity-receipt, receipt-decision-relation. Exercised
requirements: APS-EVID-NO-RETROACTIVE-REWRITE, APS-EVID-DIGEST-
MISMATCH-NOT-ESTABLISHED. Implemented requirements: none. Related
implementation surfaces: lifecycle-state module in agent-passport-
system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI),
experimental and opt-in, for the verdict vocabulary these findings
are reported in. No released package implements the later-finding
rule as a check.
Pidlisnyi Expires 1 April 2027 [Page 16]
Internet-Draft APS September 2026
2.5. The Mediation Assumption
Everything this document specifies rests on one assumption about the
deployment around it. APS establishes that a governed path was
valid. It does not establish that no ambient credential reached the
target system outside that path.
The assumption is load bearing and it is not self-checking. Where
the target system accepts a credential that never passes the
enforcement boundary, the records defined here describe the governed
path and are silent about the rest. Silence is not a denial.
A verifier MUST NOT read the absence of a record of an ungoverned
path as evidence that no ungoverned path was used. The
accountability-record family holds the format to that: the boundary
decision and the executed flag are independent fields, a record in
which the decision is deny and the action executed anyway is a well-
formed record of a boundary violation, and the family states that
absence of a claim in the record is not a denial of that claim.
An observation scope is itself a finding with its own limits. Where
a verifier has watched a named scope and seen no alternate use, it
has established something about that scope and nothing about paths
outside it. One observed bypass settles the question. The absence
of an observed bypass leaves it not established rather than settled
negative.
The corresponding deployment obligations are in the security
considerations, and the reference architecture for a boundary that
can carry them is informative.
What this subsection does not establish. It does not establish that
the target system is reachable only through the boundary. It does
not establish that a credential issued outside APS was unused. It
does not establish that any observation scope covered every path, and
it does not turn an unobserved path into an absent one.
Requirement. APS-ENF-NO-ABSENCE-INFERENCE, a verifier does not read
the absence of a record of an ungoverned path as evidence that no
ungoverned path was used, exercised by accountability-record vector
9, positive-deny-executed, a well-formed record in which the boundary
decision is deny and the executed flag is true.
Pidlisnyi Expires 1 April 2027 [Page 17]
Internet-Draft APS September 2026
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: accountability-record, 12 vectors. Exercised
requirements: APS-ENF-NO-ABSENCE-INFERENCE. Implemented
requirements: none. Related implementation surfaces: no released
package.
2.6. Transition Contract
This subsection is informative. It is the spine the rest of this
document describes. Each row names one transition in the life of an
authority and separates three questions about it: where its semantics
are specified, what a verifier can establish about it in this
revision, and which durable artifact it leaves behind. The three
answers differ for several rows, which is why they are three columns
rather than one.
The table is the set of protocol-stage and major lifecycle
transitions selected for this revision. It is not exhaustive. Three
rows are the open transition and evidence gaps this revision carries,
the principal-to-authority association, admission to dispatch, and
dispatch attempted, and each is carried in Section 19 rather than
left silent. Other rows record no dedicated durable artifact without
being open questions: expiry leaves none because the bound is inside
the signed record, and key compromise, approval withdrawal before
consumption and renunciation by the agent have no transition of their
own in this revision.
+===============+=============+=============+=======================+
|Transition |Specified in |What a | Durable artifact |
| | |verifier can | |
| | |establish | |
| | |now | |
+===============+=============+=============+=======================+
|Principal |Section 3.3 |the binding | PrincipalBindingV1 |
|relationship | |exists and | |
| | |verifies | |
+---------------+-------------+-------------+-----------------------+
|Principal |Section 3.3 |the | signed principal- |
|relationship | |revocation | binding-revocation |
|ended | |verifies | record |
+---------------+-------------+-------------+-----------------------+
|Principal-to- |no section of|not | none |
|authority |this |established | |
|association |revision, |in this | |
| |recorded at |revision | |
| |Section | | |
| |19.2.10 | | |
Pidlisnyi Expires 1 April 2027 [Page 18]
Internet-Draft APS September 2026
+---------------+-------------+-------------+-----------------------+
|Root authority |Section 4.3, |that the | root delegation plus |
|basis accepted |Section 11.3 |verifier's | trust policy, or an |
| | |own trust | importing profile's |
| | |policy | evidence |
| | |accepts the | |
| | |root, and | |
| | |not which | |
| | |principal it | |
| | |represents | |
+---------------+-------------+-------------+-----------------------+
|Activation |Section 8.3.1|valid, not | condition and |
| | |yet | attestation records, |
| | |effective, | in the proposed: |
| | |or not | namespace |
| | |established | |
+---------------+-------------+-------------+-----------------------+
|Delegation |Section 4.1, |the child is | AuthorityDelegationV1 |
| |Section 4.2 |no wider | |
| | |than the | |
| | |parent under | |
| | |every | |
| | |component | |
| | |order | |
+---------------+-------------+-------------+-----------------------+
|Revocation |Section 4.5, |every chain | revocation record, |
| |with |containing | status observation |
| |Section 4.5.2|the revoked | |
| |as one record|delegation | |
| |format |is invalid | |
| | |once the | |
| | |verifier | |
| | |establishes | |
| | |the | |
| | |revocation | |
+---------------+-------------+-------------+-----------------------+
|Suspension and |Section 8.3.5|suspended or | suspension and |
|release | |restricted, | release records |
| | |naming the | |
| | |causes that | |
| | |remain | |
+---------------+-------------+-------------+-----------------------+
|Restriction |Section |restricted, | none in this revision |
|imposed or |8.3.3, and |or a denial | |
|released |Section 9.9 |at the | |
| |informatively|boundary, | |
| | |with the | |
| | |chain | |
Pidlisnyi Expires 1 April 2027 [Page 19]
Internet-Draft APS September 2026
| | |unchanged | |
+---------------+-------------+-------------+-----------------------+
|Pinned-referent|Section 8.3.3|a denial | none in this revision |
|mismatch | |under a | |
| | |mismatch | |
| | |reason, or | |
| | |continuity | |
| | |not | |
| | |established | |
+---------------+-------------+-------------+-----------------------+
|Purpose |Section 8.3.2|exhausted, | an exhaustion record, |
|exhaustion | |which is an | which MAY be recorded |
| | |ending of | |
| | |the expiry | |
| | |kind | |
+---------------+-------------+-------------+-----------------------+
|Expiry |Section |authority | none, the bound is in |
| |8.2.10 |ceased at | the signed record |
| | |its signed | |
| | |bound | |
+---------------+-------------+-------------+-----------------------+
|Key rotation |Section 3.4, |the key | published key |
| |Section 8.2.9|authorized | material with windows |
| | |at the | |
| | |artifact's | |
| | |issued_at, | |
| | |or an | |
| | |ambiguous | |
| | |signing | |
| | |instant | |
+---------------+-------------+-------------+-----------------------+
|Key compromise |no dedicated |nothing of | none |
| |transition, |its own | |
| |see | | |
| |Section 3.4 | | |
| |and | | |
| |Section 15 | | |
+---------------+-------------+-------------+-----------------------+
|Approval |no dedicated |nothing of | none |
|withdrawal |transition, |its own, and | |
|before |named at |no record | |
|consumption |Section 8.1 |defines it | |
+---------------+-------------+-------------+-----------------------+
|Renunciation by|no dedicated |nothing of | none |
|the agent |transition, |its own | |
| |see | | |
| |Section 8.3.8| | |
+---------------+-------------+-------------+-----------------------+
Pidlisnyi Expires 1 April 2027 [Page 20]
Internet-Draft APS September 2026
|Succession and |Section 8.3.7|new | new root or |
|reauthorization| |authority | delegation records |
| | |exists and | |
| | |the | |
| | |predecessor | |
| | |tree is | |
| | |neither | |
| | |revived nor | |
| | |inherited | |
+---------------+-------------+-------------+-----------------------+
|Status source |Section 8.3.6|knowledge | status observation |
|report | |inside the | with time and |
| | |source's | coverage |
| | |declared | |
| | |coverage | |
+---------------+-------------+-------------+-----------------------+
|Intent |Section 7.3.1|the | action-intent receipt |
| | |declaration | |
| | |verifies, | |
| | |and nothing | |
| | |about | |
| | |authority | |
+---------------+-------------+-------------+-----------------------+
|Decision |Section 7.3.2|an approval | policy-decision |
| | |exists, or a | receipt issued by the |
| | |denial is | enforcement boundary |
| | |recorded | |
+---------------+-------------+-------------+-----------------------+
|Admission to |Section 5.3, |the | none, open in |
|dispatch |Section 7.3.2|approval- | Section 19.2.11 |
| | |state axis | |
| | |is not | |
| | |established | |
| | |without | |
| | |boundary | |
| | |state | |
+---------------+-------------+-------------+-----------------------+
|Dispatch |Section 9.6 |nothing | none |
|attempted | |until a | |
| | |result | |
+---------------+-------------+-------------+-----------------------+
|Result observed|Section 7.3.3|succeeded, | action-result receipt |
| | |failed or | |
| | |unknown, as | |
| | |the boundary | |
| | |observed it | |
+---------------+-------------+-------------+-----------------------+
|Settlement or |Section 4.4 |reserved | boundary ledger |
Pidlisnyi Expires 1 April 2027 [Page 21]
Internet-Draft APS September 2026
|cancellation | |moved to | state, settlement |
| | |committed, | evidence where a |
| | |or released | profile requires it |
+---------------+-------------+-------------+-----------------------+
|External effect|Section 7.5, |established | separately resolved |
|established |Section 9.4 |only for the | evidence |
| | |claim the | |
| | |resolved | |
| | |evidence | |
| | |supports | |
+---------------+-------------+-------------+-----------------------+
|Compensation |Section 9.7 |a new action | a new intent, |
| | |chain that | decision and result |
| | |refers to | |
| | |the prior | |
| | |action | |
+---------------+-------------+-------------+-----------------------+
Table 1: Transitions, where each is specified, what a verifier
can establish now, and the durable artifact each leaves
Each row is stated in full below. The closing sentence of each entry
is what the establishing section does not establish.
Principal relationship
The principal signs and the agent is the subject. The authority
needed is the principal's own signing authority. What changes is
that a binding exists. A failure confers no authority. A binding
is not a grant, and the binding alone does not establish that the
agent holds any authority for that principal.
Principal relationship ended
A principal-binding revocation under Section 3.3 is signed by the
key its verification_method names. The authority needed is that
key's signing authority over the binding, which the reference
implementation constrains to the principal's own identifier. What
changes is that the binding is revoked. The agent's key and
unrelated delegations are not revoked by it, and an enforcement
profile defines which authority records depended on that binding.
The artifact is the signed principal-binding-revocation record.
Where the revocation does not verify, the binding stands and
nothing about the agent's other authority is established either
way.
Principal-to-authority association
A verifier associates the principal axis with the accepted
authority lineage, using the applicable authority source and the
principal evidence, under whatever standing the applicable profile
Pidlisnyi Expires 1 April 2027 [Page 22]
Internet-Draft APS September 2026
or trust policy requires. This revision defines no dedicated
artifact for it. The association is profile and trust-policy
dependent over the binding, the accepted root basis and the
authority-state material. Where it cannot be made, the
association is not established, and it is not inferred from agent
identity or from root selection alone. Section 19.2.10 carries
what this document requires until the arrow is settled, and states
the requirement there in the keyword form this subsection does not
use. No section of this revision establishes the arrow.
Root authority basis accepted
An issuer acts and the verifier's trust policy decides. The basis
is one of three forms: an APS root delegation with a null parent,
imported external authority under the importing profile's missing-
facet basis and audience check, or a trust anchor the verifier
accepts. What changes is that a root is selected for this action.
A failure is invalid where the failure is established, unsupported
for a reference to a non-delegation authority basis, and
indeterminate otherwise. It is never valid. Acceptance does not
establish which principal the authority represents.
Activation
Either time acts, for a date condition, or an attestor with a role
the condition accepts acts, for a recorded-event condition.
Already issued authority becomes exercisable. The verdict is
valid, not yet effective, or not established, and an unmet
condition does not make the grant invalid. The records are the
condition and attestation records of Section 8.3.1, which stay in
the proposed: namespace. The establishing subsection does not
settle which clock governs an instant comparison, and a boundary
that does not claim the feature does not apply the gate at all.
Delegation
An issuer holding a valid parent acts. The issuer equals the
parent's subject, the parent is valid at issuance, depth remains,
and the child is no wider than the parent under every component
order. What changes is that a new leaf exists. On failure a
conforming issuer refuses to mint. A minted invalid child is
rejected by verification, and the sections that establish this
arrow do not establish that such a child was never minted.
Revocation
The delegation's issuer acts, holding issuer standing over that
delegation. Every chain containing the revoked delegation becomes
invalid once the revocation is established, irreversibly.
Section 4.5 establishes the transition and Section 4.5.2 specifies
one format for the record. Evidence is a revocation record, which
is a SHOULD in a format the applicable profile defines, and a
Pidlisnyi Expires 1 April 2027 [Page 23]
Internet-Draft APS September 2026
status observation. On failure, unknown is not active and the
chain is indeterminate. The evidence cascade state never feeds
the authority result, and neither the presence nor the absence of
a revocation record is an input to it.
Suspension and release
A party with standing over a suspension cause acts. Authority is
inactive while any cause remains and is active again only when
every cause is released. Release creates no new authority. An
unreleased cause keeps authority inactive, and an unknown cause
state is indeterminate. The establishing section defines no
precedence order among causes and does not establish that a
release restores the shape authority had before the cause was
imposed.
Restriction imposed or released
A party outside the grant chain acts, or a policy the deployment
holds tightens. The artifact stays in force and some of what it
covers is blocked, which is the verdict restricted, or the action
is denied at the boundary. Nothing in the chain changes and no
revocation occurs. No record defined here carries the
restriction, and Section 9.9, which is informative, states that
block and release are not always symmetric.
Pinned-referent mismatch
Nobody acts inside the delegation graph. What the grant pinned
and what a verifier observes have come apart. An established
mismatch denies the action under a mismatch reason, and a mismatch
the verifier cannot establish either way leaves continuity not
established with a missing limb named. Neither outcome makes the
delegation invalid, and no record defined here carries the
observation.
Purpose exhaustion
The enforcement boundary finds, from the evidence it names, that a
declared non-time bound was reached. Authority ends, which is an
ending of the expiry kind and not a revocation. An exhaustion
record MAY be recorded, in the proposed: namespace. It attests
what the boundary found and not that the purpose was met in the
world, and a verifier with no access to the boundary's ledger
reaches no exhaustion verdict for a use_count or budget bound from
signed records alone.
Expiry
Time acts and no party does. Authority ceases at its signed
temporal bound and no revocation event occurred. Issuance under
an expired parent fails at the issuer. The establishing rule does
not establish that a replacement grant is owed.
Pidlisnyi Expires 1 April 2027 [Page 24]
Internet-Draft APS September 2026
Key rotation
The identifier's controller acts, holding control of the
identifier. The acceptable signing-key state changes and
delegated authority does not. A signing time relative to a
boundary the verifier cannot establish is ambiguous and is never a
signature failure. The establishing sections do not establish
which evidence fixes the signing instant.
Key compromise
This revision defines no transition for it. The identifier's
controller rotates the key under Section 3.4, and a party with
standing revokes the records that depended on the compromised key.
Neither step reaches artifacts already signed under that key, and
Section 15 states that a model needing that reach has no rule
here. Section 8.2.9 records the same gap.
Succession and reauthorization
A currently authorized principal or authority issuer acts, holding
current standing to grant. New authority exists and the
predecessor tree is neither revived nor inherited. The old chain
stays invalid and there is no silent resurrection. The
establishing section does not establish what happens while an
office is vacant.
Status source report
A status source acts, holding accepted standing to report rather
than authority to mutate a grant. Verifier knowledge changes
within the source's coverage. Conflicting or uncovered sources
leave the state not established. A coverage block does not
establish that the declared source set was every source that
mattered.
Intent
The acting agent signs as itself and holds no permission to
execute. Nothing about authority changes. Intent is not
admission and the action-intent receipt does not establish that
any decision followed.
Decision
A policy decision point or the boundary evaluates, and the
boundary issues the record. A permit or narrow needs a valid
selected chain and the applicable policy. A denial is evaluated
and recorded regardless. What changes is that an approval exists
or a denial is recorded, and spend is reserved at approval. A
deny record is terminal and is never consumed. The record does
not establish that the approval was consumed.
Pidlisnyi Expires 1 April 2027 [Page 25]
Internet-Draft APS September 2026
Admission to dispatch
Only the enforcement boundary acts. The approval must be
unexpired and unconsumed, authority must still be valid at this
moment, and the reservation must complete. Section 5.3 and
Section 7.3.2 state those consumption semantics. No durable
record of this transition exists in this revision, which is open
at Section 19.2.11, so a verifier without access to boundary state
reports the approval-state axis as not established. Evaluation
alone never consumes. A refusal before admission leaves the
approval unconsumed. Failure after a boundary-local commit but
before dispatch is durably established has no portable recovery
semantics in this revision.
Dispatch attempted
The enforcement boundary acts under an admission. The effect
adapter is handed the exact bound input. Holding the input does
not establish that dispatch was attempted, and no evidence exists
until a result. Missing result evidence is not evidence that no
record exists elsewhere.
Result observed
The enforcement boundary acts under an admission. Reservation or
settlement state changes only so far as the observed result and
any required settlement evidence justify. The action-result
receipt carries succeeded, failed or unknown, and its prev is the
consumed decision. Unknown does not establish failure, does not
establish absence of effect, does not by itself permit release of
a reservation, and does not by itself authorize a retry.
Settlement or cancellation
The enforcement boundary acts under an admission. Release
requires trusted evidence that dispatch did not occur, or a pre-
dispatch cancellation. Reserved moves to committed, or is
released. An unjustified release is a conformance failure. The
ledger state is boundary state and a signature over a delegation
does not establish the current cumulative total.
External effect established
An evidence issuer acts and verifier policy decides. Separately
resolved evidence moves the external-effect axis, and only for the
claim that evidence supports. Where it does not resolve, the
effect is not established, and it is never inferred from the
result record.
Compensation
A party with its own authority for the compensating action acts,
under its own chain, decision and admission. A new action chain
exists that refers to the prior action, carried by a new intent,
Pidlisnyi Expires 1 April 2027 [Page 26]
Internet-Draft APS September 2026
decision and result rather than by a rewrite of the original.
Where compensation fails the original result stands, and the
compensation is not established.
What this subsection does not establish. It does not establish that
the transitions listed are every transition an authority passes
through, that a deployment performs them in this order, or that a
verifier can observe any of them without the artifact or state named.
Three transitions leave no artifact a verifier can read in this
revision, and naming them here is not a claim that this revision
covers them.
3. Identity Scheme
3.1. 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; the principal relationship is carried by the
separate record in Section 3.3.
The public key is a multibase base58btc encoding of the multicodec
Ed25519 [RFC8032] 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, where SS is 00 through 59, 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 [RFC8785] over validated I-JSON, UTF8 converts the
resulting string to bytes, and || denotes byte concatenation:
passport_id = lowercase-hex(SHA-256(
ASCII("APS-PASSPORT-ID-V2") || 0x00 ||
UTF8(JCS(passport without passport_id and signature))))
signature = Ed25519-Sign(agent_private_key,
ASCII("APS-PASSPORT-SIG-V2") || 0x00 ||
UTF8(JCS(passport without signature)))
Pidlisnyi Expires 1 April 2027 [Page 27]
Internet-Draft APS September 2026
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.
3.2. Agent Identifiers
APS is DID-method-agnostic. agent_id and verification_method use the
syntax and resolution rules of the selected DID method [DID-CORE].
New self-certifying passports SHOULD use an existing generative DID
method whose identifier commits to the signing key, such as did:key
[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.
3.3. 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.
Pidlisnyi Expires 1 April 2027 [Page 28]
Internet-Draft APS September 2026
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.
3.4. 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. This requirement extends to any historical
key-selection boundary, including a relying party's trust-policy pin
used as a key-selection input. Without acceptable evidence that the
artifact was signed on one side of such a boundary, the pin result is
the ambiguous outcome of Section 3.5.
A verifier MUST report that indeterminate result through the
ambiguous resolution outcome of Section 3.5, whose outcome name is
KEY_AMBIGUOUS, and MUST NOT report it as a key that was not found, as
structurally malformed key material, or as a signature failure. An
Pidlisnyi Expires 1 April 2027 [Page 29]
Internet-Draft APS September 2026
issuer's unverified issued_at claim MUST NOT on its own satisfy the
evidence requirement above. This document defines no outcome
specific to a signing time that cannot be established. A profile
that needs that distinction carries it alongside the ambiguous
outcome, not instead of it.
3.5. Key Resolution for External and Evidence Signers
Section 3.1, Section 3.2 and Section 3.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 excludes the case 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. The duplication makes the
set unusable as a whole rather than key by key, and is reported as
the ambiguous outcome. A relying party's trust-policy pin, where it
is used as a key-selection input, is evaluated at the artifact's
issued_at under the same rule. A verification-time cutoff a
deployment applies for its own reasons is reported on its own axis
and MUST NOT be folded into the key-selection result.
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 7.5.
Pidlisnyi Expires 1 April 2027 [Page 30]
Internet-Draft APS September 2026
Each failure outcome carries a stable outcome name. The five failure
outcomes above are named KEY_NOT_FOUND, KEY_AMBIGUOUS,
KEY_MATERIAL_MALFORMED, KEY_UNREACHABLE and KEY_SCHEME_UNSUPPORTED.
The resolved outcome carries no failure name. This document defines
no further key-resolution outcome. Outcomes map to verification
states as follows. An unsupported identifier scheme is unsupported.
Subject or key not found, ambiguous, structurally malformed key
material, and transport unreachability are each indeterminate, and a
verifier MUST report them under distinct outcome names rather than
collapse them into one. Structurally malformed key material MUST NOT
be reported as a signature failure, because no signature check ran.
The key-authority case of Section 3.4, in which the artifact's
signing time relative to a key-validity boundary cannot be
established from acceptable evidence, is reported as ambiguous.
3.6. 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
Pidlisnyi Expires 1 April 2027 [Page 31]
Internet-Draft APS September 2026
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.
4. Delegation and Authority Attenuation
4.1. 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.
{
"record_type": "aps:authority-delegation:v1",
"version": "1.0",
"delegation_id": "sha256:<64-lowercase-hex>",
"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>"
}
Pidlisnyi Expires 1 April 2027 [Page 32]
Internet-Draft APS September 2026
The spend unit in that example is one deployment's choice. A unit is
an opaque string compared by its UTF-8 bytes, as Section 5 states,
and the iso4217:USD:minor form carries no meaning this document
defines.
The object schema is closed. All timestamps use exact UTC
milliseconds with a second value from 00 through 59. nonce is 16
random bytes. delegation_id and signature are computed as follows:
delegation_id = "sha256:" || lowercase-hex(SHA-256(
ASCII("APS-AUTHORITY-DELEGATION-ID-V1") || 0x00 ||
UTF8(JCS(delegation without delegation_id and signature))))
signature = Ed25519-Sign(issuer_private_key,
ASCII("APS-AUTHORITY-DELEGATION-SIGNATURE-V1") || 0x00 ||
UTF8(JCS(delegation without signature)))
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.
4.2. 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
Pidlisnyi Expires 1 April 2027 [Page 33]
Internet-Draft APS September 2026
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 [APS-NARROWING] and
[APS-FACETED].
4.3. 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 4.2; current validity;
and revocation state for every member. A cycle, repeated identifier,
broken parent link, or issuer discontinuity invalidates the chain.
That order is phase-major over the whole root-to-leaf chain. A
verifier applies each listed phase to every member before it applies
the next phase. The first phase in which any member fails determines
the returned state and failure reason, and within that phase the
lowest member index determines which failure is reported. Where two
faults fall inside one phase, this document states no order between
them and a verifier MAY report either. Inside the closed schema and
Pidlisnyi Expires 1 April 2027 [Page 34]
Internet-Draft APS September 2026
canonical values phase, recognition of record_type and version
precedes evaluation against the v1 schema, and a record whose
record_type or version is not recognized is unsupported and is not
additionally judged against that schema. A root member's null
parent_delegation_id is checked in the parent_delegation_id phase and
not earlier.
Verification returns one of valid, invalid, indeterminate, or
unsupported with a failure reason the verifier reports. This
document defines no failure-code vocabulary for chain verification.
An unavailable or stale revocation result is indeterminate. An
unsupported facet profile is unsupported. Cryptographic or
attenuation failure is invalid. A root the verifier's trust policy
does not accept is invalid, with a root-trust reason at the root's
index, and a trust policy that is unavailable or cannot decide is
indeterminate under the same rule as an unavailable revocation
result. A caller MUST NOT collapse indeterminate or unsupported into
valid.
A revocation-resolution outcome that a verifier does not recognize
MUST NOT be treated as active. The revocation state is not
established, and the chain result is indeterminate under the same
rule as an unavailable or stale result. This applies to any answer
outside the set a verifier recognizes, including a value a later
revision of this document may define, and to a resolver that does not
answer at all.
Two phase-scope rules follow from the phases above. In the closed
schema and canonical values phase, a timestamp MUST carry a second
value from 00 through 59. A verifier MUST reject the second value 60
wherever it appears, and MUST NOT consult a leap-second table. This
is narrower than [RFC3339], which admits the second value 60 at the
end of a month in which a leap second occurs. In the child issuance
time phase, the rule that a record's not_before MUST NOT predate its
issued_at applies only to a member whose parent_delegation_id is not
null. A root MAY take effect before its own issued_at, and a
verifier MUST NOT report a schema or attenuation failure on that
basis alone.
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.
Pidlisnyi Expires 1 April 2027 [Page 35]
Internet-Draft APS September 2026
4.4. 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. A request whose footprint
matches an unsettled and uncancelled reservation is an idempotent
retry. A request under the same action_ref whose unit, amount or
bounded ancestor set differs is conflicting reuse and MUST be
rejected. Section 5 states the same rule in full. 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.
4.5. Revocation and Cascade
Any delegation MAY be revoked by its issuer. Revocation is
irreversible. The enforcement gateway MUST recheck revocation status
at the moment the approval is consumed to admit dispatch, not only at
the moment the policy decision is issued. Section 5.3, Section 7.3.2
and Section 7.3.3 use the same phrase for that moment.
A revocation takes effect for a verifier at the point that verifier
establishes it under the revocation and freshness rules of
Section 4.3. From that point the verifier MUST NOT accept as valid
any chain that contains the revoked delegation. This holds whether
or not any further record exists for a descendant of the revoked
delegation, and whether or not that descendant was ever enumerated.
A descendant delegation does not remain valid pending descendant-
specific cascade evidence. This document does not state that a
revocation takes effect for every verifier at the same instant.
Until a verifier has established the revocation, its result follows
the freshness and staleness rules of Section 4.3.
Pidlisnyi Expires 1 April 2027 [Page 36]
Internet-Draft APS September 2026
A revoking party MAY additionally produce the cascade evidence
described in Section 4.5.1. That evidence records how a revocation
was processed. It is not what makes a descendant chain invalid, and
its absence MUST NOT be read as leaving a descendant chain valid.
An implementation reports two results, and MUST NOT collapse them
into one field. The authority result for a chain is valid, invalid,
indeterminate, or unsupported, as specified in Section 4.3. The
evidence cascade state for a revocation is complete, incomplete, or
indeterminate, as specified in Section 4.5.1. An evidence cascade
state MUST NOT be reported as an authority result.
4.5.1. Revocation Evidence
Section 4.5 specifies revocation behavior. Behavior alone leaves a
verifier dependent on the revoking system's current state. This
section specifies the evidence through which revocation history is
verifiable from records where a profile defines that evidence. 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.
The records defined in this section are evidence about how a
revocation was recorded and processed. A verifier MUST NOT treat the
presence or the absence of a record defined in this section as an
input to the authority result of Section 4.3.
A revocation SHOULD be evidenced by a signed revocation record, in a
format defined by the applicable profile, 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. This document
defines no wire encoding, identifier construction, signature
construction, reason-code vocabulary or signer rule for that record.
Where no such record is available, current revocation state remains
governed by the resolution and freshness rules of Section 4.3.
Pidlisnyi Expires 1 April 2027 [Page 37]
Internet-Draft APS September 2026
A record derived from a cascade is evidence about a descendant
delegation. It carries no authority, it is not a revocation of that
descendant, and it MUST NOT change an authority result. Where such a
record is produced, it MUST carry a reference to the originating
revocation and the cascade transaction identity of that originating
revocation. A cascade-derived record is produced only where the
originating revocation record exists. That transaction identity is
bound to the content of the originating revocation and is shared by
every record the cascade produces. This document does not define a
wire format for a cascade-derived record and does not state who signs
one.
A verifier that holds the originating revocation record and a profile
for its format establishes why a descendant chain is invalid from
that record and the signed chain. It does not need a record naming
the descendant, and the absence of one is not a defect in the chain.
A verifier that does not hold both the originating revocation record
and a profile for its format reports the evidence cascade state of
Section 4.5 as indeterminate, which does not change the authority
result.
Cascade completeness (INV-4, Section 4.6) is a claim about evidence
processing. It is not verifiable from individual revocation records,
because a partially processed subtree is indistinguishable, record by
record, from a completely processed one. A cascade-completion
record, where a profile defines one, carries the cascade transaction
identity of the originating revocation and states that every
descendant in a defined set was processed.
A party MUST NOT emit a cascade-completion record unless it can state
the basis on which that set was complete when the originating
revocation took effect, and what prevented a further descendant from
entering that set afterwards. This document does not define such a
basis. A party without one reports the evidence cascade state of
Section 4.5 as incomplete or indeterminate, which does not weaken the
verifier obligation in Section 4.5.
A verifier MUST NOT read an incomplete record set as a completely
processed subtree. An incomplete or indeterminate evidence cascade
state does not make any chain valid.
4.5.2. Revocation Record Format
Section 4.5.1 states what a revocation record carries at minimum and
defines no wire encoding, identifier construction, signature
construction, reason-code vocabulary or signer rule for it. This
section specifies one format that carries those members. A profile
MAY define others.
Pidlisnyi Expires 1 April 2027 [Page 38]
Internet-Draft APS September 2026
The record type is "aps:authority-revocation:v1" at version "1.0".
The schema is closed. The members below are all a record carries,
and detail is the only OPTIONAL one.
This name is in the aps: namespace rather than the proposed:
namespace other features of this revision use, because its semantics
are fixed for this record_type and version, its wire shape is
specified below, a fixture family exercises it against distinct
negative cases, and both reference implementations map to it. The
record type is inside the signed content, so the name is part of
every preimage in this subsection. Wire compatibility: the released
packages emit and verify records under this exact record_type and
version, so a record minted by either of them is a record under this
subsection.
{
"record_type": "aps:authority-revocation:v1",
"version": "1.0",
"revocation_id": "sha256:<64-lowercase-hex>",
"delegation_id": "sha256:<64-lowercase-hex>",
"revoker": "did:example:principal",
"verification_method": "did:example:principal#key-1",
"revoked_at": "2026-03-15T12:00:00.000Z",
"reason_code": "issuer-key-compromise",
"detail": "Issuer key retired after hardware replacement.",
"cascade_transaction_id": "sha256:<64-lowercase-hex>",
"nonce": "<32-lowercase-hex>",
"signature": "<128-lowercase-hex>"
}
delegation_id names the revoked delegation. revoker is that
delegation's issuer, and Section 4.5 names no other party for a
direct revocation, so this format covers issuer revocation and no
other. A record whose revoker member differs from the named
delegation's issuer is invalid under a revoker-not-issuer reason
code, and a conforming issuer does not issue one. Both reference
implementations decide such a record invalid under that reason code
and both refuse to issue one, which is the behavior Appendix A
records. verification_method names the key that signed. All
timestamps use exact UTC milliseconds with a second value from 00
through 59. nonce is 16 random bytes. A record carrying a
record_type other than "aps:authority-revocation:v1", or a version
other than "1.0", is unsupported rather than invalid.
A record under this format MUST carry revoked_at. revoked_at is a
member, so the revocation time is inside every preimage below, and
the closed schema leaves no member that could carry a revocation time
outside the signed content.
Pidlisnyi Expires 1 April 2027 [Page 39]
Internet-Draft APS September 2026
The three identifiers and the signature are constructed as follows,
following the pattern of Section 4.1. Each domain tag is followed by
one zero byte.
cascade_transaction_id = "sha256:" || lowercase-hex(SHA-256(
ASCII("APS-AUTHORITY-REVOCATION-CASCADE-TRANSACTION-ID-V1")
|| 0x00 ||
UTF8(JCS(revocation without revocation_id, signature and
cascade_transaction_id))))
revocation_id = "sha256:" || lowercase-hex(SHA-256(
ASCII("APS-AUTHORITY-REVOCATION-ID-V1") || 0x00 ||
UTF8(JCS(revocation without revocation_id and signature))))
signature = Ed25519-Sign(revoker_private_key,
ASCII("APS-AUTHORITY-REVOCATION-SIGNATURE-V1") || 0x00 ||
UTF8(JCS(revocation without signature)))
revocation_id is inside the signature preimage, so the identifier is
signed rather than carried as a label beside the signature. A
verifier MUST recompute cascade_transaction_id and revocation_id from
the record's own content before it checks the signature. A verifier
resolves verification_method for the revoked delegation's issuer at
revoked_at, not for the revoker member the record carries, so no
field inside a revocation selects the key that authorizes it.
revoked_at is the signing instant for key selection, so the key
version that has to be authorized is the one authorized at revoked_at
and not the one current at verification time, which is the historical
selection rule of Section 3.4.
cascade_transaction_id is derived from the record's own originating
content rather than chosen by the party that issues it, so a verifier
recomputes it instead of accepting the value written there. It is
the transaction identity that Section 4.5.1 says every record one
cascade produces shares. This section defines the direct revocation
only. It defines no cascade-derived record and no cascade-completion
record.
A revocation evidenced by a record under this format satisfies the
SHOULD in Section 4.5.1.
Revocation is irreversible (INV-5, Section 4.6). A party that
records one of these MUST NOT replace a record it already holds for
the same delegation_id. A later valid record naming that delegation
leaves the earlier one in place.
Pidlisnyi Expires 1 April 2027 [Page 40]
Internet-Draft APS September 2026
reason_code is a non-empty string. This document defines no
vocabulary for its value and no rule relating a value to an authority
result. No family named in the status block below varies a reason-
code value, so nothing here is a statement about which values an
implementation uses.
This section does not establish that this is the format Section 4.5.1
requires, and does not establish that a record under this format is
an input to the authority result of Section 4.3. The record is
evidence in the sense of Section 4.5.1, and the prohibition stated
there applies to it unchanged: neither the presence nor the absence
of the record is an input to that result. It does not establish that
a cascade was processed, that a subtree was completely processed, or
that any descendant chain is invalid, which follows instead from
Section 4.5 and the signed chain. It does not establish that a
recorded record is persistent, and it states nothing about how a
party keeps the first-wins property above under concurrent writers.
It states nothing about the recheck at the next authorization
boundary required by Section 4.5.
Requirements. APS-REC-REVOCATION-TIME-SIGNED, a record carries
revoked_at, exercised by ARR-04. APS-REC-REVOCATION-UNKNOWN-TYPE-
UNSUPPORTED, a record_type or version other than the ones named is
unsupported rather than invalid, exercised by ARR-05. APS-REC-
REVOCATION-RECOMPUTE-IDS, a verifier recomputes
cascade_transaction_id and revocation_id from the record's own
content before checking the signature, exercised by ARR-02 and ARR-
06, with ARR-03 covering the signature preimage. APS-REC-REVOCATION-
FIRST-WINS, a party does not replace a record it already holds for
the same delegation_id, exercised by ARR-07 and ARR-08. APS-REC-
REVOCATION-REVOKER-IS-ISSUER, a record whose revoker member differs
from the named delegation's issuer is invalid under a revoker-not-
issuer reason code and a conforming issuer does not issue one,
specified, not exercised: no vector in the family presents a revoker
other than the issuer.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: authority-revocation-record, 8 vectors, 6 under
record verification and 2 under store first-wins. Both reference
runners reported 8 pass, 0 fail, 0 not_supported, asserting the
state, the valid flag and the full failure list including message
strings: TypeScript against agent-passport-system 7.2.0 from npm, and
Python against agent-passport-system 4.2.0 from PyPI. The family is
merged into the conformance suite at commit
5829e2ff00d75f49ce21e9d87e756658deb1ef33. This subsection is a
Candidate feature because the format is one format under the SHOULD
of the previous subsection, and supporting it is not a requirement of
Pidlisnyi Expires 1 April 2027 [Page 41]
Internet-Draft APS September 2026
APS Core. Exercised requirements: APS-REC-REVOCATION-TIME-SIGNED,
APS-REC-REVOCATION-UNKNOWN-TYPE-UNSUPPORTED, APS-REC-REVOCATION-
RECOMPUTE-IDS, APS-REC-REVOCATION-FIRST-WINS. Implemented
requirements: APS-REC-REVOCATION-TIME-SIGNED, APS-REC-REVOCATION-
UNKNOWN-TYPE-UNSUPPORTED, APS-REC-REVOCATION-RECOMPUTE-IDS, APS-REC-
REVOCATION-FIRST-WINS, APS-REC-REVOCATION-REVOKER-IS-ISSUER. Related
implementation surfaces: agent-passport-system 7.2.0 (npm), agent-
passport-system 4.2.0 (PyPI).
4.6. 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). INV-4 is
a claim about evidence processing, reported as the evidence cascade
state of Section 4.5, and is not an input to the authority result.
It is verifiable only from a completion record whose basis
Section 4.5.1 leaves undefined. The signed receipt layer in
Section 7 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 18.
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 4.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.
5. 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
Pidlisnyi Expires 1 April 2027 [Page 42]
Internet-Draft APS September 2026
Section 7.
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 4.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 unit is an opaque non-empty string. This document defines no
grammar for unit values. Two units are the same unit when their
UTF-8 byte sequences are equal, and are different units otherwise.
An implementation MUST NOT reject a unit for failing a grammar this
document does not state, and MUST NOT treat two unequal unit strings
as one unit because they appear related.
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.
A reservation is keyed by action_ref. Its footprint is the
action_ref, the unit, the amount, and the set of bounded ancestor
delegation_id values in the selected chain. Unbounded ancestors do
not contribute to that footprint. A request presenting a footprint
already reserved and not yet settled or cancelled is a retry of the
same reservation, and the boundary MUST NOT reserve a second amount
for it. A request under the same action_ref whose unit, amount or
bounded ancestor set differs is conflicting reuse, and the boundary
MUST reject it. After a reservation is cancelled, a later request
carrying the same footprint MUST reserve again.
Pidlisnyi Expires 1 April 2027 [Page 43]
Internet-Draft APS September 2026
5.1. 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:
{
"profile": "aps-action-ref-v2",
"agent_id": "did:key:z6Mk...",
"action_type": "commerce_preflight",
"target": "https://api.example/payments",
"payload_ref": "<64 lowercase hexadecimal characters>",
"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 [UAX15] strings sorted by the lexicographic order of their UTF-8
encodings. issued_at is an RFC 3339 [RFC3339] UTC timestamp with
exactly three fractional digits, a second value from 00 through 59,
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.
Each scope_required value is a scope string under Section 4.2. This
document states no grammar for it beyond what that section states,
and an implementation MUST NOT reject a scope value against a pattern
this document does not state.
Because profile is fixed to "aps-action-ref-v2", the input object
cannot name the profile that permits an empty scope_required array.
The permission is therefore supplied to the implementation as profile
context, alongside the object and outside it, by the caller that
holds the applicable profile. An implementation given no such
context MUST reject an empty scope_required array. An implementation
MUST NOT infer the permission from any member of the object.
The payload reference and action reference are computed as:
Pidlisnyi Expires 1 April 2027 [Page 44]
Internet-Draft APS September 2026
payload_ref = lowercase-hex(
SHA-256("APS-ACTION-PAYLOAD-V1" || 0x00 || JCS(payload)))
action_ref = lowercase-hex(
SHA-256("APS-ACTION-REF-V2" || 0x00 || JCS(input_object)))
JCS is RFC 8785 [RFC8785] and SHA-256 is defined in [RFC6234]. 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 number MAY appear in any spelling I-JSON admits. JCS serializes a
number to one canonical form, so two admissible spellings of the same
value produce the same digest, and an implementation MUST NOT reject
a value on the ground that its spelling is not the canonical one.
This governs spelling only. A value I-JSON does not admit is
rejected as before.
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.
5.2. 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":
external_action_ref =
lowercase-hex(SHA-256(canonicalize(input_object)))
Pidlisnyi Expires 1 April 2027 [Page 45]
Internet-Draft APS September 2026
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.
scope A single scope string.
timestamp An RFC 3339 UTC timestamp at exactly millisecond
precision, with three fractional-second digits, a second value
from 00 through 59, 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 5.1. A digest
produced by any construction other than the one specified in this
section MUST NOT carry that label.
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 5.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.
Pidlisnyi Expires 1 April 2027 [Page 46]
Internet-Draft APS September 2026
5.3. Two-Phase Execution
Section 4.5 requires revocation to be rechecked at the moment the
approval is consumed to admit dispatch, and the action-result record
of Section 7.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. The permit or narrow policy-decision
record of Section 7.3.2 is that artifact. Its receipt_id is the
consumable identity, its action_ref is the binding, and its
valid_until is the bounded lifetime. Execution then presents and
consumes the approval. At the moment the approval is consumed to
admit dispatch, the boundary MUST re-validate what can have changed
since issuance, including revocation status and temporal validity, as
required by Section 4.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 5) 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.
6. Profile Model
This document leaves several constructions to a profile. A profile
is a separate document that fixes those constructions for a
deployment or for a community of deployments, under a name that
records can carry. This document does not register profiles, does
not define a profile document format, and does not name any profile
other than the facet, action-reference and receipt profile
identifiers it already fixes.
Two things a profile is not. It is not a policy. Policy decides
whether a particular action is allowed under authority that is
already established, and is carried in the policy chain. A profile
decides how the records are constructed and read before any policy
runs. It is also not an extension point for new authority. The
dimensions a verifier compares are the ones the delegation section
fixes, and a profile supplies the construction inside a dimension
rather than adding one.
Pidlisnyi Expires 1 April 2027 [Page 47]
Internet-Draft APS September 2026
6.1. What a Profile Identifies
The requirements in this subsection bind a profile document. They
are requirements on what a profile has to say, not runtime checks a
verifier performs on a record, so no fixture exists for them. This
is the only normative content of Section 6, and it is marked as such
because the rest of this section reports behavior that fixture
families do exercise.
A profile MUST identify all of the following.
Identifier. The exact string that appears in records claiming the
profile, in the member that names a profile at the extension point
the profile serves.
Version. A version distinct from the identifier, or a statement that
the identifier carries the version. Two profiles that differ in
any requirement below MUST NOT share an identifier and version.
Canonicalization. The canonical byte form of every structure the
profile defines, and whether it is the RFC 8785 [RFC8785] form
this document uses or another form. A profile that defines a
signed structure and does not fix its canonical bytes has defined
nothing verifiable.
Authority dimensions and their orders. For each dimension the
profile constructs, the set of values, the order relation over
them, and which direction of that order is narrowing. A verifier
compares a child against its parent under that order, so a profile
that states the values and omits the order leaves the comparison
undefined.
Target construction. The target string construction that the action-
reference computation of the policy chain section requires a
profile to define, including how the string is derived from the
resource, tool or endpoint the action will reach, and which
differences in that resource produce different strings.
Required decision context. The members a decision under the profile
commits to beyond those the DecisionRefV1 construction of
Section 7.4 already names, and whether a verifier that cannot
resolve one of them reports the decision as not established or
proceeds without it.
Evidence types and resolution rules. Each evidence type the profile
accepts, how a verifier resolves it, what a resolved value
establishes, and what the verifier reports when resolution fails
or returns an answer the profile does not recognize. Where the
Pidlisnyi Expires 1 April 2027 [Page 48]
Internet-Draft APS September 2026
profile supplies evidence this document requires but does not
define, such as the acceptable timestamp or transparency-log
evidence at a historical key-selection boundary, the profile MUST
state the acceptance rule and not only the record shape.
Freshness policy. For each answer the profile reads from live state
rather than from a signed record, the age past which the answer is
no longer usable, and what a verifier reports past that age. An
answer with no stated freshness bound is unbounded, and a profile
MUST say so explicitly rather than leave it unstated.
Unknown-profile behavior. What an implementation that does not hold
this profile reports when it meets a record naming it. A profile
MUST NOT require that such an implementation treat the record as
valid.
Admission requirements. What the next authorization boundary checks
again before the action takes effect, and what it consumes or
reserves when it admits. A profile that adds a construction which
a boundary has to re-evaluate MUST say so, because a construction
checked only at issuance is not an admission control.
Semantic preservation. For each semantic this document defines that
the profile touches, which of six values applies to it: preserved
exactly, transformed with equivalent semantics, narrowed, omitted
and irrelevant to the operation, not representable, or externally
resolved. This is the loss model Section 11.4 states, and a
profile fills it for its own constructions rather than only for
external protocols. A profile MUST state the verifier result for
a semantic it cannot represent that an operation under the profile
requires, and that result MUST NOT be valid.
External protocol mapping. For each external protocol the profile
carries APS concepts over, the concept-by-concept mapping, and,
for every concept that does not survive the mapping, whether the
result is unsupported or not established. A profile MUST NOT map
a concept onto a weaker external construct without recording the
loss.
A profile MUST NOT widen authority. A profile defines constructions,
and a construction that admits a grant, an action or an effect which
the same records would not admit without the profile is a widening.
This constraint is on the profile document, in the same way as the
requirements above, and this document states no runtime test by which
a verifier detects a widening construction.
Pidlisnyi Expires 1 April 2027 [Page 49]
Internet-Draft APS September 2026
The following is informative. Where an implementation does recognize
such a construction, reporting the record unsupported rather than
valid is the disposition consistent with the rest of this document.
What recognizing a widening construction consists of is not defined
here, so this disposition is not stated as a requirement.
What this subsection does not establish. It does not establish that
any profile exists, that a profile satisfying this list produces
interoperability with another profile that also satisfies it, or that
a verifier can tell a conforming profile from a widening one by
inspecting records. It states what a profile document has to contain
and stops there.
Requirements. APS-PROF-REQUIRED-CONTENT, a profile identifies every
item in the list above. APS-PROF-SEMANTIC-PRESERVATION, a profile
states which of the six loss values applies to each APS semantic it
touches and states the verifier result for a semantic it cannot
represent, which is never valid. APS-PROF-NO-WIDENING, a profile
does not widen authority. APS-PROF-UNKNOWN-NOT-VALID, a profile does
not require an implementation that does not hold it to treat a record
naming it as valid. All four are specified, not exercised, and no
fixture exists for a requirement on a profile document.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: none. Implemented requirements: none. Related
implementation surfaces: no released package.
6.2. Profiles at the Extension Points
This subsection is informative. It collects every point at which
this document defers a construction to a profile, states what an
implementation that does not hold the profile reports there, and
names the fixture families that exercise the point. The obligations
themselves are stated in the sections listed, not here.
Facet profiles in the delegation record.
The scope, reputation, values and reversibility facets of
Section 4.1 each carry a profile identifier. The component orders
subsection requires the profiles on a facet to match between
parent and child, and states that a profile change is unsupported
rather than narrower. Chain verification returns unsupported for
an unsupported facet profile. Both reference SDKs report this as
UNSUPPORTED_PROFILE and return the chain state unsupported rather
than invalid. No fixture family changes a facet profile between
parent and child. The requirement inventory records this as not
exercised, and the behavior described here is read from the SDK
sources rather than from a vector.
Pidlisnyi Expires 1 April 2027 [Page 50]
Internet-Draft APS September 2026
Cross-principal composition.
The chain verification subsection requires one root-to-leaf chain
per action, forbids a verifier from taking the union of scopes or
budgets across chains, and leaves cross-principal composition to a
separate profile. No such profile exists. Without one, a record
set carrying several chains over one leaf supports the grants of
whichever single chain is selected and nothing more. Related
fixture families: chain-selection-no-union and single-chain-
selection, both of which state in their own READMEs that they
neither define nor approximate that profile.
Historical key-selection evidence.
The key rotation subsection requires a profile to identify an
acceptable timestamp, transparency-log or equivalent evidence
source wherever key retirement makes the result depend on which
side of a boundary an artifact was signed. Without that evidence
the key-authority result is indeterminate even when the signature
is cryptographically valid, and it is reported through the
ambiguous resolution outcome KEY_AMBIGUOUS rather than as a key
that was not found, as malformed key material, or as a signature
failure. Related fixture families: key-rotation-historical, which
supplies its own test evidence record and records that the record
is a fixture stand-in and not a proposal.
Target string construction.
The action-reference computation requires a profile to define how
the target string is built. The implementation status appendix
records this as a construction the released packages leave to a
profile. Exercised indirectly by capability-binding-drift, which
shows that a target naming a tool or endpoint does not distinguish
two revisions of that tool, and which returns not established
rather than invalid when the grant carries no construction that
would.
Empty scope_required.
The action-reference object fixes its own profile member, so the
object cannot name the profile that permits an empty
scope_required array. That permission reaches the implementation
as profile context supplied alongside the object by the caller
holding the profile. An implementation given no such context
rejects an empty array and does not infer the permission from any
member of the object. This is the one extension point at which
the absence of a profile is a rejection rather than an unsupported
result. No family supplies or withholds profile context.
Revocation record format and cascade completion.
The revocation evidence subsection leaves the wire format of the
signed revocation record, and of any cascade-completion record, to
Pidlisnyi Expires 1 April 2027 [Page 51]
Internet-Draft APS September 2026
the applicable profile. A verifier that holds the originating
revocation record and a profile for its format establishes why a
descendant chain is invalid from the records. A verifier holding
one and not the other reports the evidence cascade state as
indeterminate, which does not change the authority result.
Related fixture families: ancestor-revocation-chain, for the per-
member revocation path. The record format itself is exercised by
no family in this corpus at this commit.
Undeclared spend unit.
The policy chain section lets a profile require the gate to deny
when an action does not declare its unit, and otherwise evaluates
the amount under the delegation's resolved unit. No family
presents an action and a delegation whose units differ, and none
omits the unit.
Receipt envelope and stage result profiles.
A receipt whose envelope profile is not aps-receipt-v1 is
unsupported and is not judged against the aps-receipt-v1 schema,
which is not its schema. A result object whose profile is not the
one its named stage defines is invalid rather than unsupported,
because those objects are closed. Both reference SDKs implement
the envelope case as UNSUPPORTED_PROFILE returning unsupported.
Exercised for the positive envelope profile by the receipts
families under cross-stack and by accountability-record. No
family presents an unknown envelope profile.
Signatures the profile requires.
The receipt verification subsection (Section 7.6) makes the
required signature set the issuer signature plus any signature the
applicable profile or the verifier's own input requires. Failure
or non-resolution of a signature outside that set does not change
the record's aggregate state and is reported on its own axis.
Related fixture families: receipts-aeoess, in its two-signature
vectors.
Imported grants.
The OAuth identity-assertion grant binding states that an external
grant carrying no spend semantics cannot be projected into a
conforming chain root unless an importing profile supplies an
explicit spend basis that verifier policy accepts, and that the
projection is otherwise unsupported. No family presents such a
projection.
Pidlisnyi Expires 1 April 2027 [Page 52]
Internet-Draft APS September 2026
Principal binding revocation.
Revoking a principal binding does not revoke the agent's key or
unrelated delegations, and an enforcement profile defines which
authority records depended on that binding. No family carries a
principal-binding revocation.
Attestation tiers.
The attestation provenance subsection defines the tier and status
terminology that profiles import, defines no general attested-
signal wire format, and imposes no verifier behavior beyond
keeping tier and verification status independent. Exercised in
part by instruction-provenance, whose tier mutation is rejected
under that document's own tier lock rather than under the
independence rule.
Identifier scope.
The privacy considerations recommend that profiles use context-
specific agent and principal identifiers where global correlation
is unnecessary. Every family reuses stable identifiers across its
vectors, so nothing exercises this.
External protocol carriage.
A profile that carries APS concepts over another protocol states
the mapping and the losses. Related fixture families: arap-
binding, which models one external approval profile against a
pinned source, and by the cross-stack families, which carry
artifacts produced by other systems.
Across the points above, the pattern this document holds to is that
an unknown or unheld profile yields unsupported or not established,
and never valid and never a narrower reading. The text states that
outcome directly at the facet, receipt-envelope, imported-grant and
cascade-evidence points. At the empty scope_required point the
outcome is rejection instead, for the reason given above. The
nearest exercised evidence for the general pattern is revocation-
resolution-forward-compat, which shows both reference SDKs failing
closed on a revocation answer they do not recognize rather than
reading it as active. That family is about a resolver answer and not
about a profile, so it supports the pattern by analogy and does not
establish it.
What this subsection does not establish. It does not establish that
the extension points listed are the complete set for future
revisions, that any implementation behaves as described at a point no
family covers, or that the SDK behavior read from source at the
facet-profile point would survive a vector. Where a point has no
family, that is recorded above rather than argued past.
Pidlisnyi Expires 1 April 2027 [Page 53]
Internet-Draft APS September 2026
This subsection states no requirement of its own and carries no
requirement identifier. The obligations are in the sections it
names.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: chain-selection-no-union, single-chain-selection,
key-rotation-historical, capability-binding-drift, ancestor-
revocation-chain, revocation-resolution-forward-compat, instruction-
provenance, arap-binding. Implemented requirements: none. Related
implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-
passport-system 4.2.0 (PyPI) for the UNSUPPORTED_PROFILE and
KEY_AMBIGUOUS outcomes only. No released package implements a
profile document, a profile registry, or profile-context passing.
7. 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.
7.1. 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:
Pidlisnyi Expires 1 April 2027 [Page 54]
Internet-Draft APS September 2026
{
"profile": "aps-receipt-v1",
"receipt_id": "<64 lowercase hexadecimal characters>",
"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 7.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 5.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 with a second value
from 00 through 59. 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.
7.2. Receipt Identifiers and Signatures
The receipt identifier is computed over the validated envelope with
receipt_id and signatures absent:
Pidlisnyi Expires 1 April 2027 [Page 55]
Internet-Draft APS September 2026
receipt_id = lowercase-hex(SHA-256(
ASCII("APS-RECEIPT-ID-V1") || 0x00 ||
UTF8(JCS(receipt without receipt_id and signatures))))
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:
signature_form = {
"receipt": receipt without signatures,
"signer": {
"signer": signer,
"key_id": key_id,
"alg": "Ed25519"
}
}
value = lowercase-hex(Ed25519-Sign(signing_key,
ASCII("APS-RECEIPT-SIG-V1") || 0x00 ||
UTF8(JCS(signature_form))))
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.
7.3. Core Receipt Types
This section defines three stages and their receipt_type values:
"aps:action-intent:v1", "aps:policy-decision:v1", and "aps:action-
result:v1". A verifier selects the rules to apply from the
receipt_type the record carries, never from the stage a caller
expects. A record whose receipt_type names no stage defined here is
unsupported. A verifier MUST NOT report such a record valid, and
MUST NOT judge its result object against a stage schema the record
does not name. Each result object defined below is closed, so a
result whose profile is not the one its named stage defines is
invalid.
Pidlisnyi Expires 1 April 2027 [Page 56]
Internet-Draft APS September 2026
These rules bind the issuer as well as the verifier. A conforming
issuer MUST NOT emit a receipt whose receipt_type names a stage
defined here and whose content breaks that stage's rules. This is
the obligation Section 4.6 states for delegations, applied to
receipts. It does not require a general-purpose record-building
function to apply the stage rules itself, but a record that breaks
them is not a conforming receipt whatever produced it.
Where a stage below names the enforcement boundary as issuer, the
expected boundary identity is a trust input the verifier supplies. A
verifier given an expected identity MUST report a record whose issuer
differs from it as invalid on that axis. A verifier given none MUST
report that axis as not established, which is indeterminate and is
never valid. This document states no rule that issuer differs from
subject_agent at those stages, and no separate rule that an action-
result issuer equals the issuer of the policy decision it follows.
The latter follows only where both are checked against the same
supplied boundary identity.
7.3.1. 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.
7.3.2. 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 7.4. result is a CoreDecisionOutputV1 object with exactly
these members:
{
"profile": "aps-core-decision-output-v1",
"verdict": "permit",
"effective_authority_ref":
"<64 lowercase hexadecimal characters>",
"constraints": [],
"valid_until": "2026-04-08T12:00:05.000Z"
}
Pidlisnyi Expires 1 April 2027 [Page 57]
Internet-Draft APS September 2026
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.
valid_until and issued_at are compared as instants, not as strings.
The issuer puts constraints into that canonical form when it builds
the decision output, before the output is hashed for Section 7.4, so
that two byte-different encodings of one decision cannot produce
different decision_ref values. A verifier takes the array as
received. It MUST NOT normalize, deduplicate or sort a received
array before evaluating it, and a received array that is not already
duplicate-free, in NFC and sorted by UTF-8 bytes makes the record
invalid. This is the rule Section 5.1 states for the other canonical
array in this document.
A permit or narrow policy-decision record is a bounded, single-use
approval for its action_ref. At the moment the approval is consumed
to admit 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.
7.3.3. 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:
{
"profile": "aps-action-result-v1",
"status": "succeeded",
"effect_ref": "<64 lowercase hexadecimal characters>",
"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
failure the boundary cannot characterize is reported unknown, because
failed carries a stable failure identifier the boundary does not hold
in that case. A non-null effect_ref is computed as lowercase-
Pidlisnyi Expires 1 April 2027 [Page 58]
Internet-Draft APS September 2026
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.
The validity window belongs to the policy decision. valid_until
bounds the moment at which that decision may be consumed to admit
dispatch, as Section 7.3.2 requires. It does not bound the issued_at
of the action-result record that follows, because execution and
observation can complete after the decision is consumed. A verifier
MUST NOT treat an action-result record as invalid on the sole ground
that its issued_at is later than the consumed decision's valid_until,
and MUST NOT report a temporal relation between the two that it did
not check.
7.4. 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:
authority_state_ref = H("APS-DECISION-AUTHORITY-V1",
authority_state)
policy_ref = H("APS-DECISION-POLICY-V1",
policy_input)
context_ref = H("APS-DECISION-CONTEXT-V1",
decision_context)
decision_output_ref = H("APS-DECISION-OUTPUT-V1",
decision_output)
where H(tag, value) =
lowercase-hex(SHA-256(ASCII(tag) || 0x00 || UTF8(JCS(value))))
The DecisionRefV1 input is a closed object:
{
"profile": "aps-decision-ref-v1",
"action_ref": "<64 lowercase hexadecimal characters>",
"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>"
}
Pidlisnyi Expires 1 April 2027 [Page 59]
Internet-Draft APS September 2026
decision_ref = lowercase-hex(SHA-256(
ASCII("APS-DECISION-REF-V1") || 0x00 ||
UTF8(JCS(decision_ref_input))))
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.
7.5. 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.
A verifier that does not resolve evidence at all reports the
evidence-resolution axis as not_attempted, which is indeterminate.
Declining to resolve evidence is a permitted verifier scope.
Omitting the axis, or reporting a receipt valid for a claim that
depends on evidence the verifier never resolved, is not.
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.
7.6. Receipt Verification
A verifier performs these checks in order:
1. parse bounded I-JSON while preserving duplicate names
Pidlisnyi Expires 1 April 2027 [Page 60]
Internet-Draft APS September 2026
2. enforce the closed ReceiptV1 envelope schema and the schema of
the stage named by receipt_type
3. recompute receipt_id
4. resolve signer authority at issued_at, and, for a stage that
names the enforcement boundary as issuer, compare issuer with
the expected boundary identity where one is supplied
5. verify the required signatures
6. recompute action_ref from the independently supplied action
input object, and compare that object's agent_id with the
record's subject_agent
7. verify delegation_ref against the selected authority chain, and
verify that chain
8. recompute decision_ref where required, over the decision output
in the canonical form of Section 7.3.2, using the construction
of Section 7.4
9. validate prev and stage transitions
10. enforce freshness and single-use state for an approval
11. resolve evidence required by the verifier's policy
On step 5, the required signature set is the signature from issuer
that Section 7.1 requires, plus any signature the applicable profile
or the verifier's own input explicitly requires. Failure or non-
resolution of a signature outside that set MUST NOT change the
record's aggregate state and is reported on its own axis. A
structurally malformed signature descriptor still makes the envelope
invalid, because the envelope schema is closed and the descriptor is
part of it.
On step 6, the action binding is established only against an
independently supplied action input object. Where the verifier holds
none, the action-binding axis is not established, which is
indeterminate. Where it holds one, the object's agent_id of
Section 5.1 and the record's subject_agent of Section 7.1 MUST be
equal, and a verifier MUST report a mismatch as invalid on that axis.
The two name the acting agent from the two sides of one action, and a
record binding an action declared by one agent to a different
subject_agent is not a conforming receipt.
Pidlisnyi Expires 1 April 2027 [Page 61]
Internet-Draft APS September 2026
On step 7, where an authority chain is supplied, delegation_ref MUST
equal the delegation_id of the selected leaf byte for byte, and a
verifier MUST report a mismatch as invalid. Where no chain is
supplied, a verifier checks the form of delegation_ref only and MUST
NOT report the delegation-validity axis as valid. Where
delegation_ref names an authority basis rather than a delegation
leaf, this document defines no encoding for that basis, and a
verifier MUST report that axis as unsupported.
On step 10, the policy-decision record identifies the approval.
Whether that approval has been consumed is enforcement-boundary state
keyed by its receipt_id and is not content of the record. A verifier
without access to that state reports the approval-state axis as not
established, which is indeterminate.
The result keeps artifact integrity, signer authority, action
binding, delegation validity, decision binding, stage continuity,
enforcement-boundary identity, approval state, and evidence
resolution separate. An invalid cryptographic or structural check is
invalid. Missing live state is indeterminate. An unknown required
profile is unsupported, as is a receipt_type that names no stage of
Section 7.3. A result object whose profile is not the one its named
stage defines is invalid, because those objects are closed. A caller
MUST NOT collapse indeterminate or unsupported into valid, and a
verifier MUST NOT let an axis it did not establish contribute to a
valid result.
A ceiling an implementation reaches while parsing or verifying, such
as a nesting depth, a wire size, or a chain length limit, is a
property of that verifier and not of the record: the same bytes
verify under a verifier with a higher ceiling. A verifier that
reaches such a ceiling MUST report indeterminate with a reason naming
the limit, and MUST NOT report the record invalid on that ground. A
parse failure, a duplicate member, or any other schema violation
remains invalid. Where a bounded parser both reaches a ceiling and
observes a syntax violation, a ceiling reached before any syntax
violation is observed is indeterminate, and a syntax violation
observed first is invalid.
8. Authority Lifecycle
An agent can outlive the session that started it, the person who
sponsored it, the key it first signed with, the approval that let it
act, and the workflow it was built for. This section states what
happens to its authority across those changes: what stays continuous,
what must stop, what may be transferred, who can establish
replacement authority, when current authority is checked again, and
what evidence supports each transition.
Pidlisnyi Expires 1 April 2027 [Page 62]
Internet-Draft APS September 2026
This section has four parts. Concepts names the findings the rest of
it keeps apart. Authority Continuity Rules states what authority
means across change, as twelve rules L1 to L12. Lifecycle Mechanisms
specifies the machinery a deployment uses to make those rules
checkable: activation, purpose exhaustion, capability and policy
binding, authority epoch, suspension cause sets, status sources,
succession and handover, and what changes when a person leaves.
Candidate Lifecycle Extensions lists statements written against this
text that no requirement here depends on.
Lifecycle Core is an enumerated set of propositions, not a reading of
this section, and it is an informative grouping name rather than a
claimable base. A proposition is in it only where it restates a
requirement the closed core of this document already states, which is
the only ground on which anything in this section is Core. Six of
the twelve continuity rules contribute to it, one requirement
identifier each. L1 is in it whole, restating the per-member
revocation check of Section 4.3 applied to a dependent chain. From
L3, that revocation is irreversible for the authority object it
names, which Section 4.6 states as INV-5. From L5, that an action is
decided against one root-to-leaf chain with no union across chains,
per Section 4.3. From L6, that the boundary rechecks revocation
state and temporal validity at the moment the approval is consumed to
admit dispatch, per Section 4.5, Section 5.3 and Section 7.3.2. From
L7, that an unknown revocation state is not active. From L9,
historical key selection at the artifact's issued_at together with
the issuer-claim timestamp and the indeterminate result where the
signing instant is not established, all three per Section 3.4. Every
other rule, every remaining part of L3, L5, L6, L7 and L9, and every
mechanism in this section is a Candidate feature, normative for an
implementation claiming it and not a requirement of APS Core
conformance.
Every normative subsection here ends with its requirement identifiers
and a status block naming the fixture families that exercise it and
the released packages that implement it. A requirement is marked
exercised only where a named vector carries an assertion that fails
when the requirement is violated. Everything else is marked
specified, not exercised.
Record types this section names are in the proposed: namespace. They
are the names the reference packages ship. No fixture family in the
conformance suite mints a record under any of them, so none of them
graduates to the aps: namespace in this revision, and none of them is
a frozen wire name.
Pidlisnyi Expires 1 April 2027 [Page 63]
Internet-Draft APS September 2026
8.1. Concepts
Authority is the bounded set of actions an agent may perform on
behalf of a principal under currently valid grants and constraints.
It is not one record and not one status flag. It depends on parties,
on authority artifacts, on lifecycle state, on action state, and on
what a verifier can establish about each of them. These change
independently. A transition in one does not imply a transition in
another unless the authority model in force binds them.
Not every concept named below is a separate protocol object. The
names exist so that two findings a deployment tends to run together
can be reported apart.
Parties and standing:
Agent identity Which agent is acting. Identity continuity does not
establish authority continuity.
Principal The person, office, organization or other body on whose
behalf authority exists.
Issuer Whoever issues or signs an authority artifact. The issuer
and the principal can be different parties.
Issuer standing Why the issuer was allowed to create, narrow,
suspend, revoke or replace authority for the principal at the
moment of issuance.
Lifecycle standing Who may suspend, revoke, replace or reaffirm an
authority artifact now. This is not always the issuer. An
organization, a quorum, a successor or a security function can
hold standing over authority it never issued. In this revision a
party with lifecycle standing that is not the delegation's issuer
ends dependent authority by revoking its own ancestor grant, or
through a suspension cause under Section 8.3.5, because
Section 4.5 names only the issuer for a direct revocation. Direct
revocation by a party other than the issuer is open at
Section 19.2.15.
Principal binding Which principal an agent acts for. It can exist
before any grant and outlive one.
Sponsor Who is responsible for an agent's continued operation, where
a deployment has that role. Changing a sponsor does not on its
own transfer or replace existing authority.
Pidlisnyi Expires 1 April 2027 [Page 64]
Internet-Draft APS September 2026
A signature that verifies establishes which key signed, and, where an
identifier-to-key binding is established, which party signed. A
verifier MUST NOT read it as establishing that the signer held
standing to make the statement the record carries. Standing MUST be
resolved from a source the authority model accepts for that
statement, and MUST NOT be read from the record asserting it. A
record's own claim about the role its signer holds is the signer's
claim about itself, and where that claim conflicts with the accepted
source the conflict MUST be reported under its own reason code rather
than folded into a plain role mismatch.
A standing answer has three values, not two: the party holds the
role, the party does not hold the role, and the source cannot say.
Where the source cannot say, the verifier MUST report the state as
not established and MUST NOT report it as a finding that the party
lacks standing.
Issuer standing and lifecycle standing are separate findings. Issuer
standing is about the issuer at the moment of issuance and does not
change with later events. Lifecycle standing is about who may change
the artifact now. A verifier MUST NOT derive one from the other.
Whether an artifact was validly issued and whether it still confers
authority are likewise two findings, established separately. A grant
can be validly issued and stay dependent on an authority path that
later ends.
Authority and dependencies:
Delegated authority That a subject may take an action because a
principal granted it, under which constraints, for which targets,
for what period, through a specific chain.
Authority path and current dependency Which other authority a grant
depends on now. Historical provenance and current dependency are
two findings.
Presented credential or session A session or derived token used to
exercise authority in one request. Ending a grant does not on its
own invalidate every session or derived token already issued, and
ending a session does not on its own end the grant.
Activation condition When already issued authority becomes
exercisable. A grant can be validly issued and still wait on a
date or a recorded event. See Section 8.3.1.
Target binding Which resource, counterparty or object the authority
applies to. Continuity of a name does not on its own establish
continuity of the thing named.
Pidlisnyi Expires 1 April 2027 [Page 65]
Internet-Draft APS September 2026
Capability binding Which operation, implementation or declared
schema a grant refers to, where that distinction matters. See
Section 8.3.3.
Lifecycle state:
Issuance The event that creates an authority artifact.
Suspension Pauses or narrows the use of authority without
permanently ending it.
Expiry or exhaustion Ends authority because a declared time, use
count, budget, purpose or other bound has been reached.
Revocation Permanently ends a named authority artifact.
External restriction A block from outside the grant chain. It can
stop some effects while the grant itself stays valid.
Authority epoch Separates current authority from stale authority
surviving in sessions, queues, replicas, snapshots or restored
state. See Section 8.3.4.
Decisions and effects:
Approval A principal or approver allows a proposed action. It is an
input to authorization, with its own scope, expiry and use count,
and it can be withdrawn before the next authorization boundary
consumes it.
Policy version Which policy an approval or decision was evaluated
against. The same action can be allowed under one version and
denied under the next.
Authorization decision The record an enforcement point makes that an
action was allowed or denied, against the authority, policy and
inputs it evaluated. The signed form is the policy-decision
record of Section 7.3.
Invocation and execution The exact action submitted for execution,
and the attempt to carry it out.
Effect The externally observable result, if any.
In-flight state Where an action sits between authorization and a
known outcome. Authority can change inside that interval.
Pidlisnyi Expires 1 April 2027 [Page 66]
Internet-Draft APS September 2026
This section is written against three enumerations, and they are
never mixed. An artifact verdict is what a verifier says about an
authority artifact at a moment: valid, invalid, not established, not
yet effective, suspended, or restricted. A boundary outcome is what
an enforcement point decides about one action at one authorization
boundary: authorized, denied with a stated reason, or not
established. A chain-verification result is what Section 4.3 returns
for one selected root-to-leaf chain: valid, invalid, indeterminate,
or unsupported. Two findings that share a name across the artifact-
verdict and boundary-outcome enumerations MUST carry different reason
codes.
The chain-verification result relates to the other two without being
converted into either. A chain result of valid supports the artifact
verdict valid for the artifacts on that chain and supports no
boundary outcome on its own. A chain result of invalid supports the
artifact verdict invalid. A chain result of indeterminate is carried
as indeterminate on its own axis, and where a verifier also reports
an artifact verdict for the artifacts on that chain, that verdict is
not established with the source or freshness limb named, as
Section 2.3 states. The chain result is not replaced by the artifact
verdict. A chain result of unsupported is carried as unsupported and
is neither erased nor folded into another value, as Section 4.3
already requires of a caller.
Not established keeps one meaning, which is the evidential one. The
verifier cannot reach a conclusion because a source is missing,
unrecognized, stale past its declared bound, silent, self-attested
with nothing to check it against, or in unresolved conflict with
another accepted source. It is ignorance and it is not the negation
of the claim. Where a verifier has reached a conclusion and the
conclusion is negative, the finding MUST be reported under the shape
it has. An enabling condition established not to have occurred yet
is the artifact verdict not yet effective. A composition rule
established not to be satisfied denies the action at that boundary.
A pinned referent established to have changed denies the action at
that boundary. A verdict of not established MUST name at least one
missing limb from source, freshness and coverage.
Pidlisnyi Expires 1 April 2027 [Page 67]
Internet-Draft APS September 2026
What this subsection does not establish. It does not say which party
holds any of these roles in a deployment, and it does not define a
registry or a protocol for resolving standing. It does not give an
authority epoch, an activation condition or a non-time bound a place
inside a signed delegation, because the authority vector of
Section 4.1 is closed at seven facets and a missing facet is invalid
rather than an implicit unconstrained value. Human agency law draws
related distinctions between actual authority, notice and apparent
authority. Those doctrines are a source of cases for this work.
This document does not assume that any of them applies to AI agents.
Requirements. APS-LC-STANDING-NOT-FROM-RECORD, standing is resolved
from a source the authority model accepts and is not read from the
record asserting it. APS-LC-STANDING-THREE-VALUED, a source that
cannot say gives not established rather than a finding that the party
lacks standing. APS-LC-ISSUER-VS-LIFECYCLE-STANDING, a verifier
derives neither issuer standing nor lifecycle standing from the
other. APS-LC-VERDICT-ENUMERATIONS-DISTINCT, artifact verdicts and
boundary outcomes are two enumerations and two findings sharing a
name across them carry different reason codes. APS-LC-NOT-
ESTABLISHED-LIMB, a verdict of not established names at least one
missing limb from source, freshness and coverage. All five are
specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: activation-not-established, lifecycle-purpose-
exhaustion, authority-epoch-rollback, sponsor-handover, conflicting-
status-sources. Implemented requirements: APS-LC-STANDING-NOT-FROM-
RECORD, APS-LC-STANDING-THREE-VALUED, APS-LC-VERDICT-ENUMERATIONS-
DISTINCT, APS-LC-NOT-ESTABLISHED-LIMB. Related implementation
surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system
4.2.0 (PyPI), experimental lifecycle-state module.
8.2. Authority Continuity Rules
Twelve rules, L1 through L12, about what authority means when the
records stay the same and the surroundings move. They are separate
from the eight protocol invariants of Section 4.6 and do not extend
that numbering. Each subsection states the rule, states what the
rule does not claim, and carries its own identifiers and status
block. Six of the twelve are Lifecycle Core. The rest are
Candidate.
Pidlisnyi Expires 1 April 2027 [Page 68]
Internet-Draft APS September 2026
8.2.1. L1. Revoking an Ancestor Invalidates the Authority That Depends
on It
Once a verifier establishes, under the status and freshness rules its
authority model declares, that a delegation is revoked, every chain
that depends on that delegation is invalid. This holds where the
dependent delegation carries no revocation record of its own and
appears on no enumeration of descendants. Enumerating descendants is
a cleanup and reporting mechanism. It MUST NOT be what makes a
chain-verifiable descendant invalid.
What it does not claim. It does not claim a teardown report is
useless. It does not reach a credential that carries no chain a
verifier can check, such as an opaque bearer token, where an issuer-
side revocation mechanism is still needed. It does not claim a
verifier can always establish the revocation: an unavailable or stale
answer is governed by Section 8.2.7, not by this invariant.
Requirement. APS-LC-ANCESTOR-REVOCATION-REACHES-DEPENDENTS, an
established revocation invalidates every chain that depends on the
revoked delegation, and enumeration of descendants is not what makes
a chain-verifiable descendant invalid. Specified, not exercised: no
vector in either family named below carries an assertion that fails
when enumeration is treated as the operative mechanism.
Status: Lifecycle Core. This rule restates the per-member revocation
check of Section 4.3 applied to a dependent chain, which is a
requirement of the closed core. Related fixture families: ancestor-
revocation-chain (4 vectors), authority-epoch-rollback (12 vectors).
Implemented requirements: APS-LC-ANCESTOR-REVOCATION-REACHES-
DEPENDENTS. Related implementation surfaces: agent-passport-system
7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI).
8.2.2. L2. Identity Continuity Does Not Imply Authority Continuity
The same agent identity MAY appear as the subject of a revoked chain
and of an independent replacement chain. A verifier MUST decide each
chain on its own members and MUST NOT carry a result from one chain
to the other. Revoking the first chain's ancestor invalidates the
first chain and says nothing about the second.
What it does not claim. It does not claim the agent must stop
running. It does not claim the replacement chain is narrower or
wider than the one it replaces. It does not state when replacement
authority must exist, and it does not decide whether a handover
accepts an overlap or accepts a gap.
Pidlisnyi Expires 1 April 2027 [Page 69]
Internet-Draft APS September 2026
Requirement. APS-LC-IDENTITY-NOT-AUTHORITY, a verifier decides each
chain on its own members and carries no result from one chain to
another. Specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: sponsor-handover (6 vectors). Implemented
requirements: APS-LC-IDENTITY-NOT-AUTHORITY. Related implementation
surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system
4.2.0 (PyPI).
8.2.3. L3. Reauthorization Creates New Authority
Continuity after revocation is a new grant from a principal that
currently holds the authority being granted. A verifier MUST NOT
treat a revocation as reversed and MUST NOT re-parent a revoked chain
under a new ancestor. A record stating that a revocation was
published in error is a new record that references the revocation.
It does not remove the revocation, the revocation still verifies, and
the record does not on its own change any chain result.
Recording that a revocation was made in error is permitted only as an
explicit, attributable record from a source with lifecycle standing.
Such a record is a new record and not a reversal of the old one.
Revocation is irreversible, as Section 4.6 states, and a record
withdrawing a recorded revocation does not remove it. A
proposed:revocation-withdrawal:v0 record references the revocation by
identifier, carries the delegation that revocation named, the party
stating the withdrawal, the instant, a machine-readable reason code
and optional free-text detail. After an accepted withdrawal the
revocation is still held, still verifies byte for byte, and the chain
result does not change. The resulting position is not that the
revocation never happened. It is that the revocation was withdrawn
by a named record, which is this document's rule that a later finding
is a new record rather than an edit of an earlier one.
Pidlisnyi Expires 1 April 2027 [Page 70]
Internet-Draft APS September 2026
Whether a party may withdraw a revocation is a lifecycle-standing
question the authority model answers, and it MUST NOT be read from
the withdrawal record itself. WITHDRAWAL_ACCEPTED states that the
store accepted the record and states nothing about authority. The
revocation stands, the chain result is unchanged, and no authority
returns. The outcome codes are WITHDRAWAL_ACCEPTED,
WITHDRAWAL_SCHEMA_INVALID, WITHDRAWAL_NAMES_NO_HELD_REVOCATION,
WITHDRAWAL_TARGET_MISMATCH, WITHDRAWAL_SIGNER_WITHOUT_STANDING and
WITHDRAWAL_STANDING_NOT_ESTABLISHED. The last two are different
findings and MUST NOT be collapsed: one says the party may not, the
other says nobody has told the verifier either way. A withdrawal
that changes nothing in silence is indistinguishable from one that
was never submitted, so a refusal MUST be reported with its code.
What it does not claim. It does not claim a correction is forbidden.
The word doing the work is silently. It does not state who may
withdraw a recorded revocation, which is a lifecycle-standing
question the authority model answers. It does not state what a
verifier reports after an accepted withdrawal beyond keeping the
revocation and its result.
Requirements. APS-LC-NO-REVOCATION-REVERSAL, a verifier does not
treat a revocation as reversed, which restates the irreversibility
INV-5 states in the closed core. APS-LC-NO-REPARENTING, a verifier
does not re-parent a revoked chain under a new ancestor, which the
closed core does not state. APS-LC-WITHDRAWAL-NOT-REMOVAL, a record
withdrawing a recorded revocation is a new record, the revocation is
still held and still verifies, and the chain result does not change.
All three are specified, not exercised.
Status: Lifecycle Core for one proposition, carried by APS-LC-NO-
REVOCATION-REVERSAL, that revocation is irreversible for the
authority object it names, which Section 4.6 states as INV-5 and
which is a requirement of the closed core. Everything else in this
subsection is a Candidate feature under the lifecycle continuity
rules named in Section 13.3, normative for an implementation claiming
it and not a requirement of APS Core conformance: the rule against
re-parenting a revoked chain under a new ancestor, carried by APS-LC-
NO-REPARENTING, the treatment of a record stating that a revocation
was published in error, and the withdrawal record and its outcome
codes above. Related fixture families: sponsor-handover (6 vectors),
authority-epoch-rollback (12 vectors). Implemented requirements:
APS-LC-NO-REVOCATION-REVERSAL, APS-LC-NO-REPARENTING, APS-LC-
WITHDRAWAL-NOT-REMOVAL. Related implementation surfaces: agent-
passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI),
experimental authority-state module.
Pidlisnyi Expires 1 April 2027 [Page 71]
Internet-Draft APS September 2026
8.2.4. L4. A Successor Does Not Inherit the Predecessor's Delegation
Tree
A successor's authority covers what the successor issues. A
descendant whose ancestor artifact was revoked is invalid, and it
stays invalid until a party that currently holds the authority issues
it a new grant. The departure is not the event that invalidated it.
A departure with no revocation anywhere on the path leaves the
descendant's result to chain verification, as Section 8.3.8 states.
What it does not claim. It does not decide whether office-based
authority continues, suspends or needs reaffirmation when no current
holder can exercise or revoke it. It does not settle how to treat
long-lived grants an issuer signs shortly before leaving. Both
remain open.
Requirement. APS-LC-SUCCESSOR-NO-INHERITANCE, a successor's
authority covers what the successor issues, and descendants whose
selected chain contains the revoked predecessor delegation stay
invalid until a party that currently holds the authority issues new
grants. Departure is never the invalidating event. Specified, not
exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: sponsor-handover (6 vectors). Implemented
requirements: none. Related implementation surfaces: no released
package.
8.2.5. L5. Independent Chains Are Not Combined
Each action selects one root-to-leaf authority chain. A verifier
MUST NOT union scope grants or spend ceilings from more than one
chain. An agent that holds two valid chains MUST NOT use them
together to obtain authority broader than either chain allows on its
own. An implementation that judges an action against a held set MUST
report the single chain the action was decided against, and that
report MUST name one chain rather than a set.
A presentation that concatenates two root-to-leaf chains into one
array is not a selection of one chain, and an implementation MUST NOT
decide an action against it. An implementation MAY refuse such a
presentation before chain verification runs, on the ground that the
fault is the presentation rather than the records, or it MAY let
chain verification report the broken parent link. Both paths refuse
the action.
Pidlisnyi Expires 1 April 2027 [Page 72]
Internet-Draft APS September 2026
What it does not claim. It does not forbid independently rooted
chains from coordinating on a shared objective while each keeps its
own scope. It does not define how an action selects its chain, which
is an implementation choice. It does not define cross-principal
composition, which requires a separate profile. It does not decide
what an implementation does next when the chain an action selected
turns out to be unusable, which is Section 8.2.11.
Requirements. APS-AUTH-CHAIN-NO-UNION, an action is decided against
one root-to-leaf chain and no verifier unions scope grants or spend
ceilings across chains, which restates the two propositions
Section 4.3 states in the closed core, exercised by single-chain-
selection SCS-06, whose assertion expects the chain verifier's
PARENT_MISMATCH at index 1 when a concatenated presentation is
offered as one chain, and by the eleven cases of chain-selection-no-
union. APS-AUTH-CHAIN-SET-NOT-A-SELECTION, a concatenated
presentation is not a selection of one chain and no action is decided
against it, exercised by the same vector. APS-AUTH-CHAIN-REPORT-ONE-
CHAIN, an implementation that judges an action against a held set
reports the single chain the action was decided against and names one
chain rather than a set, specified and not exercised. Neither of the
last two is stated in the closed core.
Status: Lifecycle Core for one proposition, carried by APS-AUTH-
CHAIN-NO-UNION, that an action is decided against one root-to-leaf
chain with no union across chains, which Section 4.3 states. The
reporting rule of APS-AUTH-CHAIN-REPORT-ONE-CHAIN and the
concatenated-presentation rule of APS-AUTH-CHAIN-SET-NOT-A-SELECTION
are a Candidate feature under the lifecycle continuity rules named in
Section 13.3, normative for an implementation claiming it and not a
requirement of APS Core conformance. Related fixture families:
single-chain-selection (6 vectors), chain-selection-no-union (11
vectors). Exercised requirements: APS-AUTH-CHAIN-NO-UNION, APS-AUTH-
CHAIN-SET-NOT-A-SELECTION. Implemented requirements: APS-AUTH-CHAIN-
NO-UNION, APS-AUTH-CHAIN-SET-NOT-A-SELECTION, APS-AUTH-CHAIN-REPORT-
ONE-CHAIN. Related implementation surfaces: agent-passport-system
7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), chain-selection
module, stable.
8.2.6. L6. An Earlier Approval Is Not Current Authority
An approval issued earlier does not establish that the authority it
rested on is still current. The enforcement boundary MUST recheck
revocation state and temporal validity at the next authorization
boundary, meaning the moment the approval is consumed to admit the
action, and not only at the moment the decision was issued. A cached
authorization decision MUST NOT be used past the freshness bound the
authority model declares for it.
Pidlisnyi Expires 1 April 2027 [Page 73]
Internet-Draft APS September 2026
What it does not claim. It does not state that every input of the
earlier decision is re-evaluated at that boundary. The recheck of
temporal validity sits in the closed core beside the revocation
recheck, at Section 5.3. Revalidation broader than those two is
exercised only as a candidate. It does not state what happens to an
operation already in flight when the recheck fails, which stays open.
Requirements. APS-LC-RECHECK-AT-ADMISSION, the enforcement boundary
rechecks revocation state and temporal validity at the moment the
approval is consumed to admit dispatch and not only at the moment the
decision was issued. This obligation is stated normatively in the
closed core, at Section 4.5, Section 5.3 and Section 7.3.2, and this
rule restates it rather than adding to it. APS-LC-CACHED-DECISION-
FRESHNESS, a cached authorization decision is not used past the
freshness bound the authority model declares for it, which the closed
core does not state. Both are specified, not exercised: no vector
named below asserts a failure keyed to the recheck moment itself.
Status: Lifecycle Core for one proposition, carried by APS-LC-
RECHECK-AT-ADMISSION, that the boundary rechecks revocation state and
temporal validity at the moment the approval is consumed to admit
dispatch, which the closed core states at Section 4.5, Section 5.3
and Section 7.3.2. The cached-decision freshness bound, carried by
APS-LC-CACHED-DECISION-FRESHNESS, is a Candidate feature, normative
for an implementation claiming it and not a requirement of APS Core
conformance. Related fixture families: cached-authorization-
revocation (9 vectors), approval-single-use (9 vectors), runtime-
authority-denial-continuity (9 vectors). Implemented requirements:
none. Related implementation surfaces: no released package.
8.2.7. L7. Unknown Revocation State Is Not Active
A revocation answer that is unavailable or stale is indeterminate. A
verifier MUST NOT read it as active, and the record MUST NOT claim a
revocation that no source stated. An enforcement point MAY deny on
an indeterminate answer. Where it does, the denial MUST say that the
state was not established rather than say that a revocation occurred.
A resolver answer the implementation does not recognize, including a
status value added after the implementation was written, MUST be
treated as not established rather than as active.
What it does not claim. It does not decide between denying and
waiting. It does not define freshness bounds, which the authority
model declares per source. It does not on its own extend to every
current lifecycle state claim, which is a candidate broadening rather
than this invariant.
Pidlisnyi Expires 1 April 2027 [Page 74]
Internet-Draft APS September 2026
Requirements. APS-LC-UNKNOWN-NOT-ACTIVE, an unavailable, stale or
unrecognized revocation state is not active. Specified, not
exercised: the families below decide the normalization, and neither
names a vector whose assertion fails when an unavailable answer is
read as active. APS-LC-UNKNOWN-DENIAL-SAYS-NOT-ESTABLISHED, an
enforcement point may deny on an indeterminate answer, and a denial
on it says the state was not established rather than that a
revocation occurred. Specified, not exercised: neither family names
a vector whose assertion turns on the wording of the denial.
Status: Lifecycle Core for one proposition, that an unknown
revocation state is not active, which Section 4.3 states for an
unavailable, stale or unrecognized revocation-resolution outcome and
which is a requirement of the closed core. Everything else in this
subsection is a Candidate feature under the lifecycle continuity
rules named in Section 13.3, normative for an implementation claiming
it and not a requirement of APS Core conformance: the permission to
deny on an indeterminate answer, and the obligation that such a
denial say the state was not established rather than say a revocation
occurred, which APS-LC-UNKNOWN-DENIAL-SAYS-NOT-ESTABLISHED carries.
Related fixture families: revocation-resolution-forward-compat (14
vectors), conflicting-status-sources (14 vectors). Implemented
requirements: APS-LC-UNKNOWN-NOT-ACTIVE. Related implementation
surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system
4.2.0 (PyPI).
8.2.8. L8. Suspension Is Not Revocation
Suspension pauses the use of an authority artifact and of the
authority that depends on it, and it can be released. Revocation is
terminal for the artifact it names. A verifier MUST report the two
under different verdicts and MUST NOT report one as the other. A
restricted state is a third finding: authority continues in reduced
form under a live constraint that does not pause it, and a
restriction is not required to pause descendants.
What it does not claim. It does not define who may release a
suspension. It does not define a precedence order among concurrent
causes. It does not state what happens to an action queued before a
suspension that is still queued after the release.
Requirement. APS-LC-SUSPENSION-NOT-REVOCATION, a verifier reports
suspension and revocation under different verdicts and reports
neither as the other, and a restricted state is a third finding.
Specified, not exercised.
Pidlisnyi Expires 1 April 2027 [Page 75]
Internet-Draft APS September 2026
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: suspension-cause-composition (16 vectors).
Implemented requirements: APS-LC-SUSPENSION-NOT-REVOCATION. Related
implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-
passport-system 4.2.0 (PyPI), experimental suspension module.
8.2.9. L9. Key Rotation Is Not Delegation Revocation
An identity MAY rotate its signing key and continue. A verifier MUST
select the key version authorized at the artifact's issued_at rather
than the key current at verification time, so a rotation does not on
its own invalidate artifacts signed before it. The artifact
timestamp is an issuer claim. Where the result depends on whether an
artifact was signed before a key was retired, the verifier needs
timestamp or log evidence its authority model accepts, and without it
the result is indeterminate. Revoking a delegation is a statement
about that delegation and not about the key that signed it.
What it does not claim. It does not state which evidence establishes
the signing instant. It does not cover key compromise, where an
authority model may need to reach artifacts signed before the
rotation, and this document states no rule for that case.
Requirements. APS-LC-ROTATION-NOT-REVOCATION, a verifier selects the
key version authorized at the artifact's issued_at rather than the
key current at verification time, the artifact timestamp is an issuer
claim, and the key-authority result is indeterminate where the
signing instant is not established. All three are stated in the
closed core at Section 3.4 and this rule restates them. APS-LC-
REVOCATION-NOT-ABOUT-KEY, revoking a delegation says nothing about
the key that signed it, which the closed core does not state. Both
are specified, not exercised: the family below supplies its own
stand-in evidence record and records that it is a fixture stand-in.
Pidlisnyi Expires 1 April 2027 [Page 76]
Internet-Draft APS September 2026
Status: Lifecycle Core for the three propositions the closed core
states, carried by APS-LC-ROTATION-NOT-REVOCATION: historical key
selection at the artifact's issued_at, the artifact timestamp as an
issuer claim, and the indeterminate key-authority result where the
signing instant is not established. Section 3.4 states all three.
One proposition is a Candidate feature under the lifecycle continuity
rules named in Section 13.3, normative for an implementation claiming
it and not a requirement of APS Core conformance, carried by APS-LC-
REVOCATION-NOT-ABOUT-KEY: that revoking a delegation says nothing
about the key that signed it. Related fixture families: key-
rotation-historical (5 vectors). Implemented requirements: APS-LC-
ROTATION-NOT-REVOCATION, APS-LC-REVOCATION-NOT-ABOUT-KEY. Related
implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-
passport-system 4.2.0 (PyPI).
8.2.10. L10. Expiry Is Not Revocation
Expiry ends authority because a declared bound was reached.
Revocation ends it because a party with lifecycle standing ended it
early. Both stop use. A verifier MUST report which of the two
occurred and MUST NOT collapse them into a single state. Exhaustion
of a non-time bound is an ending of the expiry kind and is not a
revocation. A grant MAY be expired and exhausted at the same
instant, and a verifier MUST report both rather than letting one
overwrite the other.
What it does not claim. It does not state that an ending must
produce a signed record, although Section 8.3.2 defines one for
exhaustion. It does not state that a replacement grant is owed after
either ending.
Requirement. APS-LC-EXPIRY-NOT-REVOCATION, a verifier reports which
of expiry and revocation occurred and does not collapse them, and
reports a grant expired and exhausted at one instant as both.
Specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: lifecycle-purpose-exhaustion (21 vectors),
lifecycle-expiry-and-renewal (15 vectors). Implemented requirements:
APS-LC-EXPIRY-NOT-REVOCATION. Related implementation surfaces:
agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0
(PyPI), experimental bounds module.
Pidlisnyi Expires 1 April 2027 [Page 77]
Internet-Draft APS September 2026
8.2.11. L11. No Silent Authority Resurrection
Where the authority path an implementation selected becomes invalid,
the implementation MUST NOT decide the action against another held
grant unless that switch was itself authorized. A switch MUST be
reported as a decision that names the path switched away from and the
authorization relied on for the switch. An implementation that
refuses to switch MUST NOT read any held chain other than the one the
action selected, so that a refusal cannot conceal a switch.
What it does not claim. The backup-restore and rollback case, where
a restore presents authority state from before a change as current,
is carried by Section 8.3.4 and Section 8.4.2 rather than here. It
does not define what makes a switch authorized. It does not forbid
an agent from holding more than one chain. It does not state what
happens to the operation after the refusal. It does not make an
implementation that has never observed the newer authority state at
fault for not detecting a regression it could not see.
Requirement. APS-LC-NO-RESURRECTION, an implementation does not
decide an action against another held grant when the selected
authority path becomes invalid unless the switch was itself
authorized, and a switch is reported as a decision naming the path
switched away from. Specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: chain-selection-no-union (11 vectors), authority-
epoch-rollback (12 vectors). Implemented requirements: APS-LC-NO-
RESURRECTION. Related implementation surfaces: agent-passport-system
7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI), the fallback
surface of the chain-selection module.
8.2.12. L12. Completeness Is a Separate and Stronger Claim
A record stating that a teardown processed a set of descendants
establishes that its signer made that statement. It does not
establish that the set was every descendant at the relevant boundary,
that every write persisted, or that nothing was issued concurrently.
A claim that a set is complete MUST state the basis on which it is
complete, and a verifier that cannot establish that basis MUST report
not established with the coverage limb named, rather than reading the
claim as covering the whole set. A query whose interval is still
inside a declared delivery lag does not cover that interval, and an
empty result over it is delivery lag rather than absence.
Pidlisnyi Expires 1 April 2027 [Page 78]
Internet-Draft APS September 2026
What it does not claim. It does not define what basis is sufficient
for a completeness claim. That is open: what set a boundary claims
to have accepted at a moment, what prevents an addition afterwards
that still counts as earlier authority, and what public commitment
can establish closure over that set without exposing private state
are all unsettled. It does not turn an incomplete teardown into a
finding that the descendants the record does not name are valid.
Requirement. APS-LC-COMPLETENESS-BASIS, a claim that a set is
complete states the basis on which it is complete, and a verifier
that cannot establish that basis reports not established with the
coverage limb named. This requirement is exercised by lifecycle-
infrastructure-failure LC-F-016-b, LC-F-026-a, LC-F-027-a, LC-F-027-b
and LC-F-029-a, the five cases in which the family names this rule.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: lifecycle-infrastructure-failure (30 vectors),
lifecycle-evidence-and-record (12 vectors). Exercised requirements:
APS-LC-COMPLETENESS-BASIS. Implemented requirements: none. Related
implementation surfaces: no released package.
8.3. Lifecycle Mechanisms
Eight mechanisms, each its own Candidate feature. An implementation
claims them one at a time, and claiming one implies none of the
others. They are the machinery the continuity rules above are
checked with: activation conditions, purpose bounds and exhaustion,
capability and policy binding, the authority epoch, suspension cause
sets, status sources, succession and handover, and what changes when
a person leaves.
8.3.1. Activation Conditions
Authority subject to an activation condition is not exercisable until
that condition is established by evidence the authority model
accepts, from a source the model accepts for that condition. An
activation condition is a separate signed record that references a
delegation by its identifier. It is not a facet, because the
authority vector of Section 4.1 is closed at seven facets.
Two record types carry this surface. A proposed:activation-
condition:v0 record declares the condition and names the delegation
it gates. A proposed:activation-attestation:v0 record is one party's
statement about the condition. An authority model MAY accept
condition evidence in a record shape this document does not define,
and where it does, the model MUST declare which record types it
accepts for that condition.
Pidlisnyi Expires 1 April 2027 [Page 79]
Internet-Draft APS September 2026
A condition is of kind date or of kind recorded_event. A date
condition carries an activation_date and needs no evidence. The
verifier compares the action instant with the date, so an unreached
date is a known negative and never an unknown one. A recorded_event
condition carries an event_type, an event_id, at least one required
attestor role, a threshold of at least one, and an instant_basis.
Required attestor roles are roles and never principals. Who holds a
role at an instant is resolved outside the record, and a condition
that names no accepted source has not stated what it accepts and MUST
be refused rather than treated as accepting anything. A record from
a party holding any named role is acceptable, which is a union and
not a conjunction. The threshold states how many acceptable
attestations establish a finding and has no default value.
The instant_basis states which instant a positive attestation is
measured against, and it has no default value. Under
condition_occurrence the governing instant is the instant the
condition is asserted to have occurred. Under attestation_written it
is the instant the record was written. The two give opposite answers
for an occurrence before an action attested after it, so the
condition MUST state which one governs.
An attestation asserts either condition_occurred, carrying the
occurrence instant, or condition_not_occurred_through, carrying the
instant through which the attestor states the condition had not
occurred. The second is a negative that is evidence rather than an
absence of evidence, and that is what separates not yet effective
from not established.
A verifier checks each presented attestation in this order, and the
first failing check is that record's reason:
1. the record type is one the model declared it accepts for this
condition, else ATTESTATION_RECORD_TYPE_NOT_ACCEPTED
2. a key resolves for the record's verification method at the
record's own written instant, and the signature verifies over
the canonical bytes of the body, else
ATTESTATION_SIGNATURE_UNVERIFIED
3. the verification method belongs to the attestor the body names,
else ATTESTATION_ATTESTOR_BINDING_MISMATCH
4. the accepted source can say whether the attestor holds the role,
else ATTESTATION_ATTESTOR_ROLE_UNKNOWN
Pidlisnyi Expires 1 April 2027 [Page 80]
Internet-Draft APS September 2026
5. the role the record claims for itself agrees with the accepted
source, else ATTESTATION_ROLE_CLAIM_CONFLICT
6. the attestor holds a role the condition requires, else
ATTESTATION_ATTESTOR_ROLE_MISMATCH
7. the condition identifier, event type and event identifier are
the condition's own, else ATTESTATION_CONDITION_MISMATCH
8. the assertion is one of the two defined above and carries the
member that assertion needs, else ATTESTATION_UNKNOWN_ASSERTION
9. every instant on the record is one the verifier will compare,
else ATTESTATION_INSTANT_MALFORMED
10. a condition_not_occurred_through record reaches the action
instant, else ATTESTATION_DOES_NOT_REACH_ACTION
A record that fails any of these checks is not evidence in either
direction. It cannot establish the condition and it equally cannot
establish that the condition was unmet. A negative statement from a
source the model does not accept for this condition therefore gives
not established and MUST NOT give not yet effective.
Each accepted record yields one finding, measured on the condition's
own instants: occurred_by_action, occurred_after_action, or
not_occurred_through_action. The verdict follows in this order.
Where both occurred_by_action and not_occurred_through_action are
present, two accepted records disagree, the verdict is not
established with reason CONDITION_EVIDENCE_CONFLICT, and neither
record is discarded in favour of the other. Where occurred_by_action
alone is present and the threshold is met, the verdict is valid with
reason ACTIVATION_ESTABLISHED. Where not_occurred_through_action is
present, the verdict is not yet effective with reason
CONDITION_ESTABLISHED_NOT_YET_OCCURRED. Where occurred_after_action
is present, the verdict is not yet effective with reason
CONDITION_FIRST_OCCURRED_AFTER_ACTION. Where no finding is present,
the verdict is not established, with ACTIVATION_THRESHOLD_NOT_MET
where accepted records exist but fall short of the threshold, with
NO_ATTESTATION_PRESENTED where nothing was presented, and otherwise
with the reason of the record that got furthest through the checks.
A condition presented against a different delegation gives not
established with reason CONDITION_DELEGATION_MISMATCH and the
coverage limb named. The claim does not state that it covers what
the verdict needed.
Pidlisnyi Expires 1 April 2027 [Page 81]
Internet-Draft APS September 2026
Only three verdicts are reachable here: valid, not yet effective and
not established. An unmet activation condition MUST NOT make a grant
invalid. Whether the grant is valid at all is chain verification's
answer and not this surface's. A record written after an action MAY
establish a condition that obtained before it, which is the ordinary
case for any model built around a determination recorded after the
fact. A condition whose first occurrence is after the action does
not reach back to that action, and the same record establishes the
condition for a later action.
What it does not establish. An activation condition is enforced only
at a boundary that claims this feature. A delegation gated by a
recorded_event condition verifies as valid at a boundary that does
not claim it, because the condition is a separate record the chain
does not carry and chain verification never reads. An issuer that
needs a gate enforced at every boundary has only the time facet of
Section 4.1, whose not_before every chain verifier applies. It does
not settle which clock governs an instant comparison, and a single
time source or a declared smear window can both produce readings a
verifier has no basis to accept. It has no vocabulary for a
condition whose trigger is that something did not happen within a
declared window, and the unresolved standing answer is what keeps
that case reachable rather than silently answered. It does not state
whether a condition, once established, stays established. It does
not decide whether a wait carried by the time facet is reported as
invalid or as not yet effective: chain verification returns invalid
with NOT_YET_VALID for a not_before that has not been reached, this
surface returns not yet effective for an activation date at the same
instant, and the difference is recorded here rather than resolved.
Requirements. APS-LC-ACTIVATION-SOURCE-DECLARED, an authority model
accepting condition evidence in a record shape this document does not
define declares which record types it accepts for that condition, and
a condition naming no accepted source is refused rather than read as
accepting anything. APS-LC-ACTIVATION-EVIDENCE-ORDER, each presented
attestation is checked in the stated order and the first failing
check is that record's reason. APS-LC-ACTIVATION-NOT-INVALID, an
unmet activation condition does not make a grant invalid, and only
valid, not yet effective and not established are reachable on this
surface. All three are specified, not exercised: the family below
decides the verdicts and does not carry an assertion keyed to the
order of the checks.
Pidlisnyi Expires 1 April 2027 [Page 82]
Internet-Draft APS September 2026
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: activation-not-established (19 vectors).
Implemented requirements: APS-LC-ACTIVATION-SOURCE-DECLARED, APS-LC-
ACTIVATION-EVIDENCE-ORDER, APS-LC-ACTIVATION-NOT-INVALID. Related
implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-
passport-system 4.2.0 (PyPI), experimental activation module.
8.3.2. Purpose Bounds and Exhaustion
A grant can end because a declared non-time bound was reached. Three
bound kinds are defined: purpose, use_count and budget. A
proposed:authority-bound:v0 record declares one bound on one
delegation, carrying a bound identifier, the delegation's identifier,
the kind, the bound value, and the attestor roles that may state the
bound was reached. Like an activation condition, a bound is a
separate record rather than a facet.
The three kinds are reached by different means and MUST NOT be
conflated. A purpose bound is reached when a fulfilment record from
a party with standing establishes that the stated reason was met.
Exercising the grant does not reach it. A use_count bound is reached
by the admission itself, and no fulfilment record is involved. A
budget bound is reached when committed plus reserved spend reaches
the cumulative ceiling, under the cumulative spend rules this
document states for a delegation subtree, where signatures establish
static limits and do not establish the current cumulative total. A
budget bound is never wider than the facet's cumulative limit.
Reaching the facet's limit is the reservation refusal the closed core
already states at Section 4.4, not exhaustion under this feature, and
a boundary reports the two separately.
Purpose membership is not purpose exhaustion. Whether a requested
purpose falls inside a grant's allowed purposes answers the same way
for the second action as for the first. An implementation that
checks the chain, the time facet, revocation state and purpose
membership, and stops there, admits an action under a grant that has
already done its one job. A conforming enforcement boundary MUST
evaluate the bound separately from membership.
A fulfilment record has record type proposed:authority-bound-
fulfilment:v0 and carries the bound identifier, the delegation
identifier, the attestor, the verification method, the instant the
record was written inside the signed content, a machine-readable
outcome of fulfilled or not_fulfilled, a machine-readable reason
code, and optional free-text detail. It is shaped after what this
document requires of a revocation record, which is the nearest case
of a party with standing recording that an authority artifact's state
Pidlisnyi Expires 1 April 2027 [Page 83]
Internet-Draft APS September 2026
changed. A record that says not_fulfilled is a statement about the
world, so that a fulfilment record existing and the record saying the
purpose was met stay two facts.
A bound evaluation reports one of three states. The bound is not
reached, with reason BOUND_NOT_REACHED. The bound is exhausted, with
reason PURPOSE_EXHAUSTED, USE_COUNT_EXHAUSTED or BUDGET_EXHAUSTED
according to the kind. Or the state is not established, with reason
BOUND_STATE_NOT_ESTABLISHED. A fulfilment claim the boundary cannot
establish MUST give not established and MUST NOT give exhausted.
That covers a record whose signature does not verify and a record
authenticated by a party without standing, and the two MUST be
reported under different per-record codes:
FULFILMENT_SIGNATURE_INVALID and
FULFILMENT_ATTESTOR_WITHOUT_STANDING. Where no key resolves for the
attestor's method the code is FULFILMENT_KEY_UNRESOLVED, which is a
source gap and not a signature failure. Where the accepted source
cannot say whether the attestor holds a role the code is
FULFILMENT_ATTESTOR_ROLE_UNKNOWN, which is not the same finding as
the party lacking standing. The remaining per-record codes are
FULFILMENT_ACCEPTED, FULFILMENT_SCHEMA_INVALID,
FULFILMENT_NOT_BOUND_TO_BOUND, FULFILMENT_OUTCOME_NOT_FULFILLED,
FULFILMENT_NOT_YET_ATTESTED and FULFILMENT_NOT_APPLICABLE_TO_KIND. A
verifier asked about one instant MUST NOT read a record written after
it.
An exhaustion is not reversible. A record asking to void an
exhaustion MUST be refused, and it MUST be refused whether or not its
signer holds standing to revoke the grant, because standing to revoke
is not standing to undo an ending that already occurred. A refusal
for want of standing and a refusal because the ending is terminal are
two findings and are reported apart. This document fixes no reason
code for either refusal, and no released package ships one.
An exhaustion MAY be recorded. A proposed:authority-exhaustion:v0
record carries the bound identifier, the delegation identifier, the
kind, the enforcement boundary making the finding, the verification
method, the instant the finding was made inside the signed content,
the reason code that reached exhausted, and the evidence the finding
rests on. For a purpose bound the evidence names the attestor and
written instant of every accepted fulfilment record. For a use_count
or budget bound the evidence is empty, because the basis is the
boundary's own ledger. The record attests that the named boundary
found, from the evidence it names, that the bound had been reached.
It does not attest that the purpose was met in the world, which is
the same separation Section 7.3 draws for an action-result record.
Pidlisnyi Expires 1 April 2027 [Page 84]
Internet-Draft APS September 2026
Expiry and exhaustion are separate endings and can hold at the same
instant. A verifier MUST report the chain result and the bound state
side by side, and neither overwrites the other. Neither is a
revocation.
What it does not establish. This document does not authenticate a
bound declaration. Because the facet set is closed, a bound cannot
ride inside the signed delegation, and the declaration is an input
the authority model establishes by its own means, whether a principal
signature over the body, an entry in a registry the verifier accepts,
or a term outside the wire format. It does not state who holds
standing to attest a fulfilment. It does not let a verifier with no
access to the boundary's ledgers reach an exhaustion verdict for a
use_count or budget bound from signed records alone, and the empty
evidence array on the record says so rather than hiding it. It does
not settle how far a detected reuse of a single-use artifact reaches
into artifacts already issued under that grant.
Requirements. APS-LC-BOUND-KINDS-DISTINCT, the three bound kinds are
reached by different means and are not conflated. APS-LC-PURPOSE-
MEMBERSHIP-NOT-EXHAUSTION, a conforming enforcement boundary
evaluates the bound separately from purpose membership. APS-LC-
FULFILMENT-UNESTABLISHED-NOT-EXHAUSTED, a fulfilment claim the
boundary cannot establish gives not established rather than
exhausted, and a signature failure and an attestor without standing
carry different codes. APS-LC-EXHAUSTION-IRREVERSIBLE, a record
asking to void an exhaustion is refused whether or not its signer
holds standing to revoke the grant. All four are specified, not
exercised: the family below carries the events and no vector named in
the handoff asserts a failure keyed to one of these rules alone.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: lifecycle-purpose-exhaustion (21 vectors).
Implemented requirements: APS-LC-BOUND-KINDS-DISTINCT, APS-LC-
PURPOSE-MEMBERSHIP-NOT-EXHAUSTION, APS-LC-FULFILMENT-UNESTABLISHED-
NOT-EXHAUSTED, APS-LC-EXHAUSTION-IRREVERSIBLE. Related
implementation surfaces: agent-passport-system 7.2.0 (npm) and agent-
passport-system 4.2.0 (PyPI), experimental bounds module.
8.3.3. Capability Binding and Policy Version
A stable identifier, name or identity does not establish that what it
refers to is unchanged. A tool can keep its name while its
implementation or its declared schema, description and permissions
change, which widens effective authority with no change to the grant.
Where the authority model declares a class of referent change
capability-relevant, continuity of the referent across such a change
Pidlisnyi Expires 1 April 2027 [Page 85]
Internet-Draft APS September 2026
MUST be established by something the grant, the model or an attesting
party pins. A verifier MUST NOT treat an unchanged name as evidence
of an unchanged controller, an unchanged implementation or an
unchanged declared schema.
A pin is carried in one of two encodings, and an implementation
states which it used. Under scope_grant_v0 the pin is further colon-
separated segments under the tool grant, which keeps it inside the
scope grammar of Section 4.1. That encoding has one consequence
worth stating: a pin then narrows across a chain by the ordinary
covering rule, so a child carrying a different pin fails as scope
widening rather than as a binding failure. Under bound_record_v0 the
pin is a separate signed record referencing the delegation
identifier. This document reserves the name and does not define that
record's wire format.
Two axes are pinned separately, and each is a set rather than a
single value, so that a grant may pin more than one acceptable
revision. The implementation axis pins digests of acceptable
implementations. The declared-metadata axis pins digests of
acceptable declared metadata blocks. They are distinct because a
tool can keep its name and its implementation bytes while its
declared schema, description or permissions change, which is a
different evidence problem. An empty set on an axis means that axis
is not pinned.
Continuity of the referent has three values. Established means the
referent the grant pinned is the referent observed. Mismatch means
the verifier reached a conclusion and the conclusion is that the
referent changed. Not established means the verifier could not reach
a conclusion either way, because nothing was pinned or because no
accepted attestation covered what the answer needed. An established
mismatch MUST deny the action at that boundary under a mismatch
reason and MUST NOT be reported as not established. A not-
established continuity MUST name at least one missing limb from
source, freshness and coverage. Neither outcome makes the delegation
invalid. The grant is intact, and what is not established is that
the action now attempted is within it.
The reason codes for this surface are
CAPABILITY_CONTINUITY_ESTABLISHED for an authorized outcome,
TOOL_NOT_IN_GRANT_SCOPE, SCOPE_NOT_GRANTED,
PINNED_IMPLEMENTATION_DIGEST_MISMATCH and
PINNED_METADATA_DIGEST_MISMATCH for a denial, and
TOOL_ATTESTOR_KEY_UNRESOLVED, TOOL_ATTESTATION_SIGNATURE_INVALID,
TOOL_ATTESTATION_ABSENT, REGISTRY_ENTRY_TOOL_NAME_MISMATCH,
REGISTRY_ENTRY_IMPLEMENTATION_MISMATCH, NO_CAPABILITY_PIN_IN_GRANT,
IMPLEMENTATION_NOT_PINNED_IN_GRANT, METADATA_NOT_PINNED_IN_GRANT and
Pidlisnyi Expires 1 April 2027 [Page 86]
Internet-Draft APS September 2026
OBSERVATION_ABSENT for a not-established outcome. A metadata pin
does not cover an implementation and an implementation pin does not
cover a declared schema, which is what the two partial-pin codes
record. An axis the verifier did not observe MUST NOT be reported as
matching.
The identifier limb is the same rule applied to who controls a name.
A grant that does not declare an identifier the action in fact relies
on gives not established, because a verifier that never modelled the
identifier has no record to invalidate when control of it moves. A
single accepted holder at the instant that is not a pinned controller
denies the action under IDENTIFIER_CONTROLLER_CHANGED, and the result
names the party that holds the identifier now. Two accepted
custodian records naming different holders at one instant give not
established under IDENTIFIER_BINDING_CONFLICT rather than a winner.
An interval between issuance and the instant that is neither bound to
the holder nor covered by an accepted retention record gives not
established under IDENTIFIER_CONTINUITY_GAP_UNCOVERED, and a
retention record whose issuer is not the custodian the verifier
resolves for that identifier kind gives
RETENTION_CUSTODIAN_WITHOUT_STANDING. The remaining codes are
IDENTIFIER_CONTINUITY_ESTABLISHED,
IDENTIFIER_DEPENDENCY_NOT_DECLARED, IDENTIFIER_CONTROLLER_NOT_PINNED
and IDENTIFIER_BINDING_LAPSED.
The released capability-binding module evaluates custodian binding
and retention records it does not itself produce. Its entry point
takes the binding and retention records as inputs together with two
caller-supplied resolvers, one for which custodian the caller
resolves for an identifier kind and one for that custodian's key, and
its contract states that standing is resolved "by KIND and never from
the custodian member the record asserts about itself: a valid
signature establishes who signed, not that they had standing". The
module issues no custodian record and signs none. It exports the
signed-byte construction a custodian signs over and nothing that
mints or signs a record.
A policy version is a dependency of a decision that the grant does
not carry. The same action can be allowed under one version and
denied under the next. A decision record MUST identify the policy
version it was evaluated against. Section 7.4 already requires the
policy input a decision commits to through policy_ref to identify the
policy and version actually evaluated, so a decision whose policy_ref
commits to such an input satisfies this rule even where the
deployment keeps the value private and no reader can recompute the
component. Not established applies where no such commitment exists,
because a reader then cannot tell which rules produced the decision.
A pin that resolves to no version is likewise not established. A
Pidlisnyi Expires 1 April 2027 [Page 87]
Internet-Draft APS September 2026
pinned decision renders under its own version whatever version is
operative at the moment it is read, which is this document's rule
that later findings never rewrite earlier records applied to a policy
change.
Which version is operative at an instant is resolved from pointers,
not from write order. The operative version at an instant is the
target of the acceptable pointer with the greatest effective instant
at or before it. Two acceptable pointers sharing that instant and
naming different targets give not established rather than a winner.
A pointer from an issuer that does not hold standing over the policy
is not established. A pointer's own claim to be a rollback does not
make it one: a rollback is established only where the version it
names was already operative under an earlier acceptable pointer, and
a newly authored version that reproduces an older version's rules is
a new version whatever the pointer calls it.
A policy that tightens after a grant was issued restricts the action
at the authorization boundary. The chain is unchanged and the grant
stays valid. A verifier MUST report that case as restricted and MUST
NOT report it as invalid. Invalid is what an actual revocation
produces, and keeping the two apart is what lets a reader tell a
policy change from an authority change. A tightened policy does not
reach backward on its own, and the earlier grant does not need to be
revoked for the new rule to bind future actions.
What it does not establish. It does not claim every referent must be
pinned, because pinning has real cost and many grants do not need it.
The claim is that where nothing pins it, continuity is not
established and the verdict says so. It does not claim a verifier
can always detect a referent change, and often a verifier cannot. It
does not cover narrowing: a referent that loses a capability has not
widened or redirected what the authority permits, and denying there
would be a false denial. It does not claim a capability change
invalidates the grant. It does not claim re-consent is the only
remedy. It does not resolve semantic drift generally, and when a
change in meaning should invalidate an earlier grant or approval
stays open. It does not define how a policy version is published,
who holds standing over a policy, or how a verifier learns which
pointers are acceptable. This document fixes no reason codes for the
policy-version limb, and no released package ships any.
One divergence is recorded rather than resolved. The candidate
families named below were authored against an earlier reading and
label an established pinned-referent mismatch as not established, in
a verdict set that has no denial member. This document specifies the
denial. A family run that reproduces the earlier labelling is
reproducing the family's vocabulary and is not deciding the rule.
Pidlisnyi Expires 1 April 2027 [Page 88]
Internet-Draft APS September 2026
Requirements. APS-LC-REFERENT-CONTINUITY-PINNED, continuity of a
referent across a change the authority model declares capability-
relevant is established by something the grant, the model or an
attesting party pins, and an unchanged name is not evidence of an
unchanged controller, implementation or declared schema. APS-LC-
PINNED-MISMATCH-DENIES, an established mismatch denies the action
under a mismatch reason and is not reported as not established, and a
not-established continuity names at least one missing limb. APS-LC-
POLICY-VERSION-IDENTIFIED, a decision record identifies the policy
version it was evaluated against, and one that does not is not
established when read afterwards. That identifier restates
Section 7.4 and adds nothing to it, and Appendix D carries it as a
Core restatement. APS-LC-POLICY-TIGHTENING-RESTRICTS, a policy that
tightens after issuance is reported as restricted and not as invalid.
All four are specified, not exercised, and the divergence recorded
below is why: the families label the mismatch outcome differently
from the rule this subsection states.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: lifecycle-policy-change (13 vectors). Diverging
families, not evidence: capability-binding-drift (8 vectors) and
lifecycle-identifier-reuse-and-rename (13 vectors), whose vectors
label an established pinned-referent mismatch as not established, so
a run of either counts neither for nor against the rule this
subsection states, and Appendix A.4 records the same divergence.
Implemented requirements: APS-LC-REFERENT-CONTINUITY-PINNED, APS-LC-
PINNED-MISMATCH-DENIES. Related implementation surfaces: agent-
passport-system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI),
experimental capability-binding module, for the capability and
identifier limbs, and no released package for the policy-version
limb.
8.3.4. Authority Epoch and Fencing
An authority epoch detects regression of a monotonic value the
deployment supplies, where a stale value can survive in sessions,
queues, replicas, snapshots or restored state. The feature specified
here is a regression rule and a fencing comparison over that value,
and nothing more. A value that has not regressed establishes nothing
about whether the authority behind it is current. No record defined
by this document carries an epoch value, and no decision commits to
one. An approval's usability is decided by the rules in
Section 7.3.2 and not by an epoch comparison.
Pidlisnyi Expires 1 April 2027 [Page 89]
Internet-Draft APS September 2026
This document names the concept and the comparison and defines no
wire field for either. A deployment that uses generations supplies
the value, and what is specified here is what a verifier does with
it.
The design is incomplete, and the gaps are stated rather than filled.
The value the reference packages carry is an in-memory marker. It is
not signed, it is not a wire field, and the module that holds it
supports neither durability nor concurrency. Five questions follow
from that and none of them is answered here. Which authority the
epoch is counted for, which this document leaves to the deployment or
its profile and for which the root authority basis and its delegation
lineage is the recommended answer. Who is authorized to advance it.
How an advance is authenticated, given that an unsigned marker can be
presented by any party that can reach the comparison. What a
verifier does on a first observation, where there is no high-water
mark to compare against. And what a verifier does when its own
remembered high-water mark is itself restored from stale state.
An implementation claiming the authority-epoch feature MUST define
its epoch domain, its authorized updater, the authenticated
representation of an advance, its first-observation trust rule and
its handling of stale verifier state. An implementation that leaves
any of the five undefined MUST report the feature as unsupported
rather than applying the comparisons below to a value whose meaning
it cannot state.
An epoch value is a canonical unsigned decimal integer with no sign,
no leading zero and no separators, compared as an integer and never
lexically. It is counted within an epoch domain, which the
deployment or the applicable profile defines and declares. A
declared domain names what the value is counted within. A verifier
MUST compare two values only where both are carried in the same
declared domain, and two values from different domains order nothing.
Placing a presented value against what a verifier has already
established gives one of three results. Forward means the value
advanced or held equal, and the presented state is read normally.
Regressed means the value went backwards against an established high-
water mark. Unplaceable means there is nothing to compare against,
or the two values are counted in different declared domains.
Pidlisnyi Expires 1 April 2027 [Page 90]
Internet-Draft APS September 2026
For each authority subject, an enforcement point MUST NOT act on a
state older than the newest state it has established for that subject
under the scheme in force. Where the value regresses, the operation
MUST be refused rather than resolved by recency of write.
Monotonicity is per subject and is measured against what the verifier
has established, not against global truth, so a verifier legitimately
holds a current epoch for one artifact and an older snapshot for
another.
Unplaceable is not a verdict. A high-water mark has to start
somewhere, and this document does not state whether a first
observation is read or refused. Both are defensible and the outcomes
differ, so the authority model MUST declare which disposition applies
and an implementation MUST NOT supply a default. This is the first-
observation trust rule the feature definition above requires, and
declaring it is not the same as establishing that the first value
observed was current.
A regressed view never answers active. Two verifiers holding the
same high-water mark can give different answers about the same
restored state, and the difference is what each retained. A verifier
that retained the revocation records it observed can establish the
revocation from those records and answers revoked. A verifier that
retained only the epoch value cannot, and answers unknown, which
chain verification reports as indeterminate under a revocation-
unknown failure code. Both answers are correct for the verifier that
gives them, and neither is active.
Fencing applies between the components of one enforcement boundary.
Where the component that evaluates authority is not the component
that performs the effect, the value MUST be carried to the performing
component inside the boundary and checked there. A write to an
authority state source inside the boundary MUST carry the value of
whoever claims to be the current publisher, and that source MUST
refuse a write whose value went backwards against the highest it has
already seen. An equal value has not gone backwards, so an equal
value is accepted and the retry is idempotent. The three refusal
codes are STALE_FENCING_TOKEN, FENCING_SCOPE_MISMATCH and
FENCING_TOKEN_UNREADABLE. A write path that cannot order a value is
not fenced, so the second and third refuse rather than guess. This
document places no obligation on a party outside the deployment's
enforcement boundary, here or anywhere else.
What it does not establish. It does not require a deployment to run
an epoch scheme. It claims that where a deployment has one, a
regression is a refusal rather than an input to a merge. It does not
make a verifier that has never seen the newer state at fault, because
that verifier cannot detect the regression at all. It does not say
Pidlisnyi Expires 1 April 2027 [Page 91]
Internet-Draft APS September 2026
who advances an epoch, whether the value is signed, or what evidence
carries it, and the feature definition above turns those into
obligations on an implementation rather than answers from this
document. It does not state that last-writer-wins storage is
misconfigured, only that such a store is the wrong place to resolve a
revocation. It does not bind any decision or approval to an epoch.
It does not close authority rollback, which stays open at
Section 19.2.7, and it does not establish that a verifier whose own
remembered high-water mark was restored from stale state can detect
that it was.
Requirements. APS-LC-EPOCH-FEATURE-DEFINITION, an implementation
claiming this feature defines the five items above or reports the
feature unsupported. APS-LC-EPOCH-NO-REGRESSION, an enforcement
point does not act on a state older than the newest it has
established for that subject, and refuses rather than resolving by
recency of write. APS-LC-EPOCH-SCOPE-DECLARED, an epoch value is
counted within a declared epoch domain that names what it is counted
within, a verifier compares two values only within the same declared
domain, and two values from different domains order nothing. APS-LC-
EPOCH-NO-REGRESSION is exercised by authority-epoch-rollback for the
rejection of stale authority. The other two are specified, not
exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: authority-epoch-rollback (12 vectors), for the
rejection of stale authority only. That family is not cited here for
recovery from stale verifier memory, which no family exercises.
chain-selection-no-union (11 vectors). Exercised requirements: APS-
LC-EPOCH-NO-REGRESSION. Implemented requirements: APS-LC-EPOCH-NO-
REGRESSION, APS-LC-EPOCH-SCOPE-DECLARED. Related implementation
surfaces: agent-passport-system 7.2.0 (npm) and agent-passport-system
4.2.0 (PyPI), experimental authority-state module, whose marker is
unsigned, is not a wire field, and supports neither durability nor
concurrency.
8.3.5. Suspension, Cause Sets and Release
Suspension pauses the use of an authority artifact without ending it.
Restriction leaves the artifact in force and blocks some of what it
covers. The two are separate states and neither is revocation.
Revocation is terminal for the artifact it names, and a release
record never reverses one.
A lifecycle cause is a separate signed record that references a
delegation_id. It is not a facet. The authority vector is closed at
seven facets and a missing facet is invalid, so a cause cannot ride
Pidlisnyi Expires 1 April 2027 [Page 92]
Internet-Draft APS September 2026
inside a signed delegation. A cause record carries record_type
proposed:suspension-cause:v0, a cause_id unique within one
evaluation, the delegation_id it stands against, a kind of either
suspension or restriction, the party that imposed it, the instant it
was imposed, a stable reason code, a verification method prefixed by
the imposing party, and a signature over the RFC 8785 [RFC8785]
canonical bytes of the record with record_id and signature removed.
A verifier MUST represent the causes standing against one artifact as
a set, and MUST NOT collapse them into a single flag. Where any
cause remains unreleased, the verdict is suspended if at least one
remaining cause is of kind suspension, and restricted if every
remaining cause is of kind restriction. The result MUST name the
remaining causes, each with its kind and its reason code. A count or
a boolean does not satisfy this.
A release record carries record_type proposed:cause-release:v0, a
release_id, the delegation_id, the list of cause_ids it claims to
clear, the releasing party, the instant it was recorded, a
verification method prefixed by the releasing party, and a signature
over the same preimage rule. One release record MAY name several
causes. A verifier MUST decide each named cause independently, so a
record from a party holding standing over two of the three causes it
names clears exactly those two. Releasing one cause MUST NOT clear
another as a side effect.
Standing over a cause is resolved outside the record. A verifier
MUST NOT read standing from the record asserting it, and MUST NOT
treat a cause's own statement of who may release it as deciding the
question. Standing is not authorship. A party that holds standing
over a cause it did not impose can release it, and a party that
imposed a cause does not thereby hold standing over a different one.
A record that fails a record-level check releases nothing and is
never applied to any cause. The record-level checks are the
signature under the key the verification method names, the binding of
that verification method to the party the body names, and that the
record was recorded at or before the instant being evaluated. An
unverified claim does not become a lifecycle state. Reporting
suspended on a cause whose signature does not verify converts an
unauthenticated assertion into a pause the artifact never carried.
Three time rules apply. A cause is not in evidence at an instant
before it was imposed, and the same record is in evidence at a later
instant. A release is not in evidence at an instant before it was
recorded. A release recorded before the cause it names was imposed
clears nothing.
Pidlisnyi Expires 1 April 2027 [Page 93]
Internet-Draft APS September 2026
Where a standing resolver cannot establish whether a releasing party
holds standing over a cause, the state is not established, with
reason code RELEASE_STANDING_NOT_ESTABLISHED and the source limb
missing. Failing to establish that a cause was released is not
establishing that it still holds, and it is not a finding that the
release was ineffective.
A release never clears a revocation recorded while the artifact was
suspended. Where chain verification returns anything other than
valid, a verifier MUST report that result and MUST NOT report the
pause state as if it answered the chain question. A fully released
cause set on a revoked chain is invalid. A fully released cause set
with an unresolvable revocation answer is not established. Neither
is exercisable.
The reason codes for this subsection are NO_CAUSE_PRESENTED,
NO_CAUSE_IN_EVIDENCE, ALL_CAUSES_RELEASED, CAUSES_OUTSTANDING and
RELEASE_STANDING_NOT_ESTABLISHED on a verdict, and CAUSE_IN_EVIDENCE,
CAUSE_NOT_ON_DELEGATION, CAUSE_RECORD_TYPE_UNRECOGNISED,
CAUSE_NOT_YET_IN_EVIDENCE, CAUSE_SIGNATURE_UNVERIFIED,
CAUSE_IMPOSER_BINDING_MISMATCH, CAUSE_RELEASED, RELEASE_IN_EVIDENCE,
RELEASE_NOT_ON_DELEGATION, RELEASE_RECORD_TYPE_UNRECOGNISED,
RELEASE_SIGNATURE_UNVERIFIED, RELEASE_ISSUER_BINDING_MISMATCH,
RELEASE_AFTER_EVALUATION_INSTANT, CAUSE_NOT_PRESENTED,
RELEASE_PRECEDES_IMPOSITION and RELEASER_WITHOUT_STANDING on a per-
record or per-cause disposition.
What this subsection does not establish. It defines no precedence
order among causes, so a deployment holding two causes whose releases
point in opposite directions has no rule here to apply. It says
nothing about whether a cause propagates to descendants of the
artifact it names, and it decides the state of that one artifact
only. It does not claim that a release returns authority to its
shape before the cause was imposed, because something else may have
ended in the interval. It does not say where a standing registry
comes from or who publishes one. It does not say what a verifier
should report first when a chain is revoked and causes are still
outstanding.
Informative. The open question this subsection was written against
asks that lifting one suspension not clear another, not bypass a
revocation that happened while the agent was suspended, and not
recreate rights that changed in the meantime. The composition rule
above answers the first two. The third is the same question as the
pre-suspension shape, and it stays open.
Pidlisnyi Expires 1 April 2027 [Page 94]
Internet-Draft APS September 2026
Requirements. APS-LC-CAUSE-SET-NOT-FLAG, a verifier represents the
causes standing against one artifact as a set, names the remaining
causes with kind and reason code, and does not collapse them into a
flag or a count. APS-LC-RELEASE-PER-CAUSE, each named cause is
decided independently and releasing one clears no other. APS-LC-
RELEASE-STANDING-EXTERNAL, standing over a cause is resolved outside
the record and is not read from the record asserting it or from the
cause's own statement of who may release it. APS-LC-CHAIN-RESULT-
PRECEDES-PAUSE, where chain verification returns anything other than
valid the verifier reports that result and does not report the pause
state as if it answered the chain question. All four are specified,
not exercised: the family below carries sixteen composition cases and
the handoff names no single vector whose assertion fails on one of
these rules alone.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: suspension-cause-composition, 16 cases and 5 gates.
Implemented requirements: APS-LC-CAUSE-SET-NOT-FLAG, APS-LC-RELEASE-
PER-CAUSE, APS-LC-RELEASE-STANDING-EXTERNAL, APS-LC-CHAIN-RESULT-
PRECEDES-PAUSE. Related implementation surfaces: agent-passport-
system 7.2.0 (TypeScript) and agent-passport-system 4.2.0 (Python),
suspension module, experimental and opt-in.
8.3.6. Status Sources, Freshness and Coverage
A claim about the current lifecycle state of an authority artifact,
meaning its revocation, suspension, restriction, expiry or exhaustion
state, is established only from a source the deployment profile
accepts for that state, within a freshness bound that profile
declares for that source, and only over the set the claim itself
states it covers. An answer from a source the profile does not
accept for the state does not establish it, whatever the answer says.
A status answer is active, revoked or unavailable. The first two are
determinate. unavailable is a source that was consulted and produced
no usable answer, and a verifier MUST NOT use it as a third
determinate state. A source that produced no observation at all is
silent, which is a different input, and a profile MUST declare
whether silence from a required source is a coverage gap or is read
as that source answering unavailable.
Freshness is declared per source, not globally. Each accepted source
carries its own bound in whole seconds, and the comparison is
inclusive, so an age exactly equal to the bound is within it. A
profile MUST declare whether an answer past its own bound still
counts, separately for a revoked answer and for an active answer.
The two readings differ and this document does not choose between
Pidlisnyi Expires 1 April 2027 [Page 95]
Internet-Draft APS September 2026
them. An answer dated after the boundary instant has no measurable
age and MUST NOT be read as fresh. A verifier records that answer as
skew, distinctly from staleness, and does not use it.
Where the used answers carry more than one determinate state, that is
an unresolved conflict. A verifier MUST NOT admit on a conflict,
whatever coverage says. The record MUST name both states and the
sources that carried them, because a conflict a record does not
attribute cannot be acted on. A profile declares whether a conflict
denies the action with a conflict reason or returns not established.
Under either reading the artifact verdict is not established and
never invalid. The verifier refused the action. It reached no
conclusion about the authority, and it does not claim that either
answer is false.
Unknown is not active. A revocation answer that is unavailable,
stale past its declared bound, silent or in unresolved conflict
leaves the state not established. It does not become active, and the
record MUST NOT claim a revocation that was never observed. An
enforcement boundary MAY deny on not established, and the denial
records which of source, freshness or coverage was missing.
Chain verification already requires that a revocation-resolution
outcome a verifier does not recognise is not treated as active,
leaving the revocation state not established and the chain result
indeterminate. That rule covers more shapes than an implementation
tends to anticipate. A casing or whitespace variant of a recognised
answer, a value of the wrong type, a null, an empty object or array,
and a resolver that raises rather than answering all land in the same
place. A known-active answer at one chain member does not make the
chain valid when another member's answer is not understood. This
document defines no failure-code vocabulary for chain verification,
so the reason an implementation reports for that result is the
implementation's own.
A verifier that declared an offline posture in advance, with a
snapshot source and the maximum snapshot age it declared it would
admit on, MAY admit on a snapshot inside that bound. The record MUST
name the snapshot source, the instant the snapshot was known correct,
the age it admitted at, and the declared bound. A verifier that
declared no bound in advance MUST NOT admit on a snapshot. Being
offline does not soften an observed revocation.
Where a decision is cached, the profile declares two limits. The
first is the maximum age of a cached authorization decision usable
without consulting the authority again. The second is the maximum
delay between a revocation being acknowledged and denial of
subsequent protected operations. A cached decision past the first
Pidlisnyi Expires 1 April 2027 [Page 96]
Internet-Draft APS September 2026
limit MUST be re-resolved at the next authorization boundary, on a
retained session, after a reconnect and on any other worker holding
the same credential. A grant the authority can be reached for but
whose state it cannot resolve is denied rather than served from
cache.
Coverage is measured over the source set the relying party declared,
and the record states which denominator was used. A coverage block
reporting that every declared source produced a usable determinate
answer MUST NOT be read as a statement that the declared set was
every source that mattered. A verifier MUST NOT read a state claim
as covering more than the claim states.
The reason codes for this subsection are
STATUS_ACTIVE_ALL_SOURCES_AGREE,
ADMITTED_ON_SNAPSHOT_WITHIN_DECLARED_BOUND, STATUS_REVOKED,
STATUS_SOURCES_CONFLICT, STATUS_STALE_BEYOND_BOUND,
STATUS_COVERAGE_INCOMPLETE and STATUS_NO_USABLE_OBSERVATION. The
bases a record carries for why one answer was or was not used are
within_freshness_bound, revocation_observed_outside_bound_still_used,
stale_active_admitted_by_policy, stale_beyond_bound,
source_gave_no_answer, answer_dated_after_boundary and
source_not_accepted.
What this subsection does not establish. It does not solve
completeness. The coverage rule is a rule for reading a claim, not a
duty to establish that a set was complete, and the completeness
invariant stays open. It declares no freshness number, and a
deployment with no declared bound has nothing to measure against. It
does not say which sources a profile must accept for which state. It
does not choose what a conflict returns or whether a stale answer
counts, and two implementations choosing differently are both
consistent with this text. It does not rule clock skew beyond
refusing an answer dated after the boundary. It does not say what a
relying party that acted on stale but authentic evidence is entitled
to.
Pidlisnyi Expires 1 April 2027 [Page 97]
Internet-Draft APS September 2026
Requirements. APS-LC-STATUS-SOURCE-ACCEPTED, a lifecycle-state claim
is established only from a source the profile accepts for that state,
and an answer from a source it does not accept establishes nothing
whatever the answer says. APS-LC-FRESHNESS-PER-SOURCE, freshness is
declared per source, and an answer dated after the boundary instant
is recorded as skew and not used. APS-LC-STATUS-CONFLICT-NO-ADMIT, a
verifier does not admit on an unresolved conflict between determinate
answers, and the record names both states and their sources. APS-LC-
COVERAGE-AS-STATED, a verifier does not read a state claim as
covering more than the claim states. APS-LC-OFFLINE-DECLARED-IN-
ADVANCE, a verifier that declared no snapshot bound in advance does
not admit on a snapshot. All five are specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: conflicting-status-sources, 14 cases. revocation-
resolution-forward-compat, 14 cases. cached-authorization-revocation,
9 cases. Implemented requirements: APS-LC-STATUS-SOURCE-ACCEPTED,
APS-LC-FRESHNESS-PER-SOURCE, APS-LC-STATUS-CONFLICT-NO-ADMIT, APS-LC-
COVERAGE-AS-STATED. Related implementation surfaces: the
unrecognised-answer path is in the released chain verifier of agent-
passport-system 7.2.0 (TypeScript) and agent-passport-system 4.2.0
(Python), which report it as REVOCATION_UNKNOWN under their own
failure-reason vocabulary. Multi-source status, per-source freshness
and the coverage block are the status-coverage module of the same two
packages, experimental and opt-in. The cached-decision limits are no
released package.
8.3.7. Succession, Handover and Reauthorization
Continuity after an authority ends means a new grant from a principal
who currently holds authority. It never means reversing a revocation
and it never means re-parenting the old chain onto a new ancestor.
Revocation is irreversible, and a succession record is not an
exception to that.
A successor does not inherit the predecessor's delegation tree. A
successor's grant covers what the successor issues. A descendant
whose ancestor artifact was revoked stays invalid until a party with
current authority issues it a new grant, and the departure is not
what invalidated it. A successor's fresh grant is bounded by the
successor's own ceiling and not by the predecessor's.
An agent identity can appear as the subject of one chain issued under
one root and, separately, as the subject of a chain issued under an
independently issued root. Revoking the shared ancestor of the first
chain invalidates that chain at that ancestor's own index. The
second chain is unaffected. This is the whole of what chain
Pidlisnyi Expires 1 April 2027 [Page 98]
Internet-Draft APS September 2026
verification says about a handover, and a verifier MUST NOT read the
continuing identity as continuity of the revoked authority. How the
cutover is ordered is a deployment choice. A planned handover may
accept a short overlap and a compromised principal may call for
revoking first and accepting a gap. In either case the old grant
cannot authorize a new effect at the next authorization boundary
after revocation, and continued operation has to run on the
replacement authority.
A delegation may be bound to an office, so that turnover moves it, or
to an identity, so that turnover does not. Where the delegation's
terms declare neither and the actor is the very subject the
delegation names, the answer is valid and the missing term does not
have to be resolved. Where the terms declare neither and the actor
is somebody else, the binding mode is not established, and a verifier
MUST NOT supply a default in either direction. Not established here
is not a finding that the new occupant inherits, and it is not a
finding that they do not.
Under office binding, an office-holder record from a party with
standing, whose window covers the action instant, has to name the
acting party. No covering record leaves the question not
established. A covering record naming somebody else is invalid,
which is a positive finding rather than a missing one. A vacancy
record covering the action instant leaves the question not
established, and a verifier MUST NOT carry the last known holder
through a vacancy. A verifier MUST NOT read an attestor's role off
the record body.
Replacement authority does not have to be issued after the
contingency. Where an instrument or a declared rule of the authority
model pre-commits it, the replacement holder's authority derives from
that source at the scope that source declared, and becomes
exercisable when the declared contingency is established by evidence
the model accepts for that contingency. A pre-committed replacement
whose pre-committing instrument is itself revoked or otherwise
invalid is invalid with it. Pre-commitment does not reverse a
revocation, and the successor receives the scope the pre-committing
source declares for the successor, not the predecessor's other
descendants.
Where an instrument names several co-equal holders, the declared
decision rule is evaluated over the holders current at the action
instant. A holder whose vacancy reaches that instant is not a
current holder and that holder's approval is not counted. An acting
holder's own vacancy ends the enquiry. Where the model declares a
majority rule, a vacancy does not have to be filled before the
remaining holders can act.
Pidlisnyi Expires 1 April 2027 [Page 99]
Internet-Draft APS September 2026
A later record from a party with standing may attach effects to an
act already taken, including effects the governing authority model
gives retroactive reach. Such a record is a new record that
references the earlier one. It does not rewrite the decision record
the earlier boundary produced, and a verifier evaluating before that
later record exists reaches the answer the evidence then available
supports. Where the model bounds such a record, for example by
requiring it to cover the whole of a single act, by requiring
capacity at the moment it was made, or by excluding effect on
interests acquired in the meantime, those bounds are checked and
recorded.
What this subsection does not establish. It does not say what
happens when nobody holds an office and nobody is empowered to
exercise, reaffirm or revoke what the previous holder issued. That
stays open. It sets no bound on what an outgoing issuer may pre-
commit, so grants signed shortly before a departure stay open. It
does not say whether an operation already running resumes, restarts,
compensates or stops after the authority it ran under changes. It
does not say which clock governs a contingency. It does not decide
the order of a cutover for any deployment.
Requirements. APS-LC-SUCCESSION-NEW-GRANT, continuity after an
authority ends is a new grant from a principal who currently holds
the authority, never a reversal of a revocation and never a re-
parenting of the old chain. APS-LC-BINDING-MODE-NO-DEFAULT, where a
delegation's terms declare neither office nor identity binding and
the actor is not the named subject, the binding mode is not
established and a verifier supplies no default in either direction.
APS-LC-VACANCY-NOT-ESTABLISHED, a vacancy record covering the action
instant leaves the question not established and a verifier does not
carry the last known holder through a vacancy. All three are
specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: lifecycle-root-authority-succession, 13 cases.
lifecycle-fiduciary-succession, 25 cases. sponsor-handover, 6 cases.
lifecycle-organization-events, 35 cases. Implemented requirements:
APS-LC-SUCCESSION-NEW-GRANT. Related implementation surfaces: chain
verification, revocation state per chain member and the independence
of separately rooted chains are the released chain verifier of agent-
passport-system 7.2.0 (TypeScript) and agent-passport-system 4.2.0
(Python). Subject binding mode, office-holder and vacancy records,
co-holder decision rules, pre-commitment and later attached effects
are no released package.
Pidlisnyi Expires 1 April 2027 [Page 100]
Internet-Draft APS September 2026
8.3.8. Principals, Identities and What Changes When a Person Leaves
A person's departure is not a revocation. It is an external event,
and its effect on authority depends on the authority relationship
involved and the rules that govern it. A personnel change does not
silently remove a dependency, re-parent authority or create
replacement authority. Where an authority artifact a grant currently
depends on is revoked, the dependent authority is invalid, and a
departure does not change which artifact that is.
Whether an artifact was validly issued and whether it still confers
authority are two findings, established separately. Issuance
standing turns on the issuer at the moment of issuance and does not
change with later events. Continuing authority turns on what the
grant depends on now, on its lifecycle state, on any restriction from
outside the grant chain, and on the profile's freshness rules. A
verifier MUST NOT report either finding as if it answered the other.
A person can be the principal of a grant. A person can instead be an
issuer acting for an organization or an office, with standing to
issue that comes from another authority relationship. These are not
interchangeable, and the supporting evidence has to distinguish the
principal, the issuer and the relevant dependency. Where it cannot,
continuation of authority is not established.
Identity continuity does not establish authority continuity. The
same agent identity can appear under an old chain and under an
independent replacement chain. Revoking the old chain's ancestor
invalidates the old chain and leaves the replacement chain standing
on its own.
A record of a principal event, such as death, a finding of
incapacity, a forfeiture of an appointment or the appointment of an
outside authority over the principal, decides nothing without a role
the profile accepts for that record type. A verifier MUST NOT read
an attestor's role off the record body, and MUST NOT honour a grant's
own claim that it survives an event when nothing outside the grant
supports that claim. A finding recorded later may reach an earlier
instant where the model gives it that reach. Such a finding is a new
record that references the earlier one and does not rewrite the
decision record an earlier boundary produced.
Recording a transition and observing it are different events. Where
a profile makes a change effective on a party's notice rather than at
the event, the notice finding carries its own time, and a verifier
records a notice finding or records that it has none.
Pidlisnyi Expires 1 April 2027 [Page 101]
Internet-Draft APS September 2026
Where a grant's own terms make an action class effective only once an
agreed confirmation procedure with the principal has been completed,
and that confirmation cannot be obtained, the boundary outcome is not
established. It is neither an approval nor a denial. Silence past a
deadline MUST NOT be read as the principal answering, and an
unreachable principal MUST NOT be read as a refusal. A confirmation
reaches an action only from the instant the confirmation exists, it
has to come from a party the profile accepts for it, and it has to
cover this action rather than another. A different action class
under the same grant, at the same instant, is unaffected.
Authority can also end from the agent's side. An agent may end its
own role, and where the profile makes that effective on delivery of
notice, the principal's silence is not a veto. A stated later date
or a stated triggering event moves when it takes effect and does not
change what it is. An obligation outside this protocol that the
renunciation may have breached belongs to the accountable principal
and is outside this document. A verifier does not answer it, and the
result carries no finding about it. A renunciation that breached
such an obligation reaches the same verdict and the same reason code
as a clean one.
Continuity of a name does not establish continuity of the thing
named. Where a grant depends on an identifier that no party in the
delegation graph controls, such as a mail domain a recovery path
delivers to or an account name a reference resolves, that identifier
has its own lifecycle run by a custodian. Section 8.3.3 states the
rule for that case, including which outcomes deny the action and
which leave continuity not established, and this subsection adds
nothing to it. The reason the case belongs here as well is that a
departure is one of the events that moves control of such an
identifier without producing any record in the delegation graph.
A credential more than one person can drive establishes authority and
does not establish who acted. Accountability is a separate finding
with its own evidence. Where a record from a party with standing
assigns the action to an individual and covers this action at this
instant, accountability is established. Where no such record exists,
where two such records overlap and resolve to neither individual, or
where the record references a different action, authority can be
valid and accountability not established at the same boundary. An
accountability finding does not by itself establish legal liability.
What this subsection does not establish. It does not say whether a
validly issued organizational grant survives the departure of the
individual who issued it. Authority models differ and the departure
alone does not choose between them, so this document leaves the
choice to the profile. It does not resolve office vacancy, and it
Pidlisnyi Expires 1 April 2027 [Page 102]
Internet-Draft APS September 2026
does not bound what an issuer may sign shortly before leaving. It
establishes nothing about who covers an agent's work after the agent
gives up the role. It makes no claim that any doctrine of human
agency law applies to an AI agent. Those doctrines are a source of
case shapes here and nothing more.
Requirements. APS-PRIN-TWO-FINDINGS, whether an artifact was validly
issued and whether it still confers authority are established
separately and neither is reported as if it answered the other. APS-
PRIN-ROLE-NOT-FROM-BODY, a verifier does not read an attestor's role
off the record body and does not honour a grant's own claim that it
survives an event when nothing outside the grant supports it. APS-
PRIN-SILENCE-NOT-CONSENT, silence past a deadline is not the
principal answering and an unreachable principal is not a refusal.
APS-PRIN-ACCOUNTABILITY-SEPARATE, authority can be valid while
accountability is not established at the same boundary. All four are
specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: lifecycle-principal-events, 32 cases. lifecycle-
principal-unreachable, 12 cases. lifecycle-identifier-reuse-and-
rename, 13 presentations. lifecycle-shared-identity-with-no-
accountable-principal, 12 cases. lifecycle-agent-renunciation, 13
cases. Implemented requirements: none. Related implementation
surfaces: chain verification and revocation state per chain member
are the released chain verifier of agent-passport-system 7.2.0
(TypeScript) and agent-passport-system 4.2.0 (Python). Principal-
event records, confirmation procedures, renunciation and
accountability findings are no released package. Identifier
custodian records are implemented, in the experimental capability-
binding module of the same two packages, which is the surface
Section 8.3.3 records and to which this subsection adds nothing.
8.4. Candidate Lifecycle Extensions
This subsection is informative. Each entry below is a candidate
extension: a short name, the rule in precise terms, its status, the
families that exercise it or a record that none does, the strongest
counterexample found against it, and whether adopting it would change
Core behavior. Nothing here is normative, nothing here is an
adoption claim, and no requirement elsewhere in this document depends
on any of it.
Pidlisnyi Expires 1 April 2027 [Page 103]
Internet-Draft APS September 2026
Two candidates that were in this list are not here. A candidate
whose strongest counterexample is unresolved is not a candidate
extension, it is an open question, and it is carried in Section 19
with the behavior this document requires until the question is
settled. The two are the conferral rule, at Section 19.2.13, and the
effectiveness-rule default, at Section 19.2.14.
Status: none of the entries below is a feature an implementation can
claim. Implemented: the lifecycle-state vocabulary these statements
are written in is the lifecycle-state module of agent-passport-system
7.2.0 (TypeScript) and agent-passport-system 4.2.0 (Python),
experimental and opt-in. No released package decides any statement
in this subsection.
8.4.1. CAND-01: An External Event Is Authority-Changing Only When
Established
A verifier may treat an external event as authority-changing only
when evidence it accepts establishes both the event and its authority
effect under the applicable authority model. Absence of such
evidence gives not established for the event, which is not a finding
that the event did not occur.
Strongest counterexample. A successor designation is simply missing,
and under the applicable model the absence resolves to a named
fallback holder. A literal reading returns not established and
denies authority the model says exists. The clause about the
applicable model carries this, because the established event is the
absence and the model's own default rule supplies the authority
effect.
What it does not establish. It does not claim the world only changes
when a record exists, and it does not claim that a valid verdict
means no authority-changing event occurred. It does not say which
events are authority-changing. It does not resolve when a change
becomes effective.
Related fixture families: lifecycle-purpose-exhaustion, 21 ordered
events, the unauthenticated event record and the record authenticated
by a party without standing. conflicting-status-sources, 14 cases,
for two accepted sources disagreeing. Not covered: events a model
makes effective with no record anywhere, and a default supplied on
absence.
Changes Core behavior: no. No requirement of APS Core conformance
depends on this statement, and an implementation that ignores it is
not for that reason non-conforming.
Pidlisnyi Expires 1 April 2027 [Page 104]
Internet-Draft APS September 2026
8.4.2. CAND-02: Later Evidence Does Not Rewrite Earlier Evidence
Later lifecycle evidence does not rewrite contemporaneous decision
evidence. A later finding is a new record that references the
earlier one and states its own effect, including how far back that
effect reaches.
Strongest counterexample. A later denial of ratification
recharacterises a past action as having only ever been provisional,
which is the closest thing in the corpus to a rewrite. The
recharacterisation is itself a dated record from a party with
standing, and the sentence it has to write is only writable while the
original record still exists in its original form.
What it does not establish. It does not claim the earlier decision's
authority effect is unchanged, and retroactive effect is real. It
does not claim a later finding can reach back without limit. It does
not claim records are immutable, and it does not override an
obligation to correct the content of a record. It does not say who
has standing to make a later finding.
Related fixture families: authority-epoch-rollback, 12 cases, a
signed withdrawal accepted as a new record with the original still
held and still verifying. conflicting-status-sources, 14 cases,
where a later conflict does not change the record written at the
earlier boundary. Not covered: the bounded-reach limb and the
amendment-obligation case.
Changes Core behavior: no. No requirement of APS Core conformance
depends on this statement, and an implementation that ignores it is
not for that reason non-conforming.
8.4.3. CAND-03: Issuance Validity, Later Attached Effects and Current
Validity Are Three Separate Findings
Three findings about an authority artifact are separate and
separately established. Whether it was validly issued, which turns
on the issuer's standing at issuance and does not change with later
events. Whether a later record from a party with lifecycle standing
has attached effects to it or to acts taken under it. Whether it is
currently valid, which turns on its dependencies, its lifecycle
state, any restriction from outside the chain and the profile's
freshness rules. A verifier does not report any one of these as if
it answered another.
Strongest counterexample. Where the finding is that issuance was
never valid, current validity looks moot, and if the findings always
moved together the separation would be decoration. They do not move
Pidlisnyi Expires 1 April 2027 [Page 105]
Internet-Draft APS September 2026
together. Issuance can be untouched while continuing scope is
narrowed from outside the chain, and issuance can be valid while
exercisability is still pending. A void-from-issuance status is also
not a revocation event, which needs the issuance question to stay
answerable after the fact.
What it does not establish. Standing at issuance cannot be inferred
from a valid signature. It does not claim an organizational grant
survives its issuer's departure and it does not claim the opposite.
It does not resolve grants signed just before a departure, and it
does not resolve office vacancy.
Related fixture families: no family in this suite. No built fixture
tests issuer standing at issuance.
Changes Core behavior: no. No requirement of APS Core conformance
depends on this statement, and an implementation that ignores it is
not for that reason non-conforming.
8.4.4. CAND-06: Collective Authority Must Satisfy Its Declared
Composition
Where the authority model requires an operation to be authorized
collectively, the operation is authorized only when the declared
composition rule is satisfied at the boundary the operation requires.
A composition rule states which members are required, the threshold,
the direction, and any restriction carried by an individual member.
What it takes to authorize an action is not necessarily what it takes
to stop or narrow it. A single valid chain does not satisfy a multi-
member rule however broad that chain is. The authority the
collective act exercises is the authority the rule attaches to, and
satisfying the rule adds nothing to any contributing member's own
scope. Where collective authority is required and the rule's
membership, threshold or direction is not declared, composition is
not established and a verifier does not supply one. A default
declared by the authority model is a declared rule and not an
inference.
Strongest counterexample. A joint release that neither party may
perform alone does something neither may do alone, which an earlier
drafting of the no-widening clause forbade. The scope clause is
about contributing members. The collective authority was never
either individual's to begin with, so neither member's scope grows.
Pidlisnyi Expires 1 April 2027 [Page 106]
Internet-Draft APS September 2026
What it does not establish. Composition is not a union of scopes.
Composition rules are not symmetric. There is no universal default
for undeclared composition. Not every member must be reachable.
Concurrences may not be aggregated across time without a declared
freshness rule. A standing superior override is lifecycle standing
and not composition.
Related fixture families: chain-selection-no-union, 11 vectors, the
negative half only. The obligation half has no coverage and must not
be reported as covered.
Changes Core behavior: no. No requirement of APS Core conformance
depends on this statement, and an implementation that ignores it is
not for that reason non-conforming.
8.4.5. CAND-09: Chain Validity Is Not Permission to Execute
Whether an authority chain is valid and whether the action it
authorizes is permitted by rules outside the grant chain are separate
findings. This candidate is stated in full at Section 9.9, with its
counterexample and its limits, and is listed here so that the
candidate set is complete.
Related fixture families: no family in this suite.
Changes Core behavior: no. No requirement of APS Core conformance
depends on this statement, and an implementation that ignores it is
not for that reason non-conforming.
8.4.6. CAND-11: A Valid Grant Can Be Unexecutable
An artifact can be valid while the target, executor or capability it
names no longer exists, in which case the artifact verdict is
unchanged and the execution attempt fails. This candidate is stated
in full at Section 9.10, with its counterexample and its limits, and
is listed here so that the candidate set is complete.
Related fixture families: no family in this suite.
Changes Core behavior: no. No requirement of APS Core conformance
depends on this statement, and an implementation that ignores it is
not for that reason non-conforming.
Pidlisnyi Expires 1 April 2027 [Page 107]
Internet-Draft APS September 2026
8.4.7. CAND-12: Ending Authority Bounds Future Effects and Does Not
Undo Past Ones
Ending or narrowing authority takes effect at the next authorization
boundary the operation requires. Where an operation has a terminal
boundary after which no further authorization decision occurs, a
change arriving after that boundary does not reach the completed
effect and is recorded as a later event rather than as a denial.
Ending authority does not undo effects already completed, does not
retract information already obtained, and does not by itself end
sessions or derived credentials already issued. Where the model
provides a compensating or reversing action, that action is separate
authority with its own boundary and its own record.
Strongest counterexample. Models that allow cancellation after
acceptance in defined circumstances look like undoing a completed
effect. They are a separately authorized action rather than an
automatic consequence, which is what the last sentence of the
statement says.
What it does not establish. This is not an argument against
terminating sessions on revocation. Session termination is a control
a profile may and often should require, and the claim is only that it
does not follow automatically, so a profile that wants it has to say
so. It does not claim a post-boundary reversal is impossible. It
does not claim exhaustion is always a separate step from use. It
does not resolve work in flight.
Related fixture families: no family in this suite.
Changes Core behavior: no. No requirement of APS Core conformance
depends on this statement, and an implementation that ignores it is
not for that reason non-conforming.
8.4.8. BROAD-L6: Every Authorization Boundary the Operation Requires
An earlier approval or authorization decision does not establish
current authority at any later authorization boundary the operation
requires. Each boundary is evaluated against lifecycle state the
verifier can establish as current and effective at that boundary,
including boundaries added from outside the grant chain and
boundaries inside a long-running or multi-step operation. Rechecking
current lifecycle state is not re-evaluating the operation under a
newer policy version, and which policy version governs is a
separately declared rule.
Pidlisnyi Expires 1 April 2027 [Page 108]
Internet-Draft APS September 2026
Strongest counterexample. Two cases where more rechecking is the
wrong answer. An in-flight instance whose remaining steps have to
resolve against a pinned policy version, where jumping to current
rules mid-replay is not a safety improvement. And a declared
graceful-shutdown window, where the final in-flight call should
succeed. The statement survives by separating current lifecycle
state from policy version and by leaving the boundary set to the
operation.
What it does not establish. It does not claim the operation must be
re-evaluated against the current policy version. It does not claim a
retry of an already decided effect is a new boundary. It does not
claim the start of a shutdown is a boundary, nor that every technical
step is one. It does not claim a recorded change is automatically
effective at the next boundary. It does not own the terminal-
boundary rule. It does not resolve work in flight.
Related fixture families: no family in this suite. The cached-
authorization-revocation family, 9 timeline cases, exercises the
narrower published invariant about rechecking revocation state at
execution time and is a related family rather than coverage of this
broadening.
Changes Core behavior: yes, if adopted. The recheck obligation at
the moment an approval is consumed is a requirement of the closed
core. This statement extends rechecking to every authorization
boundary the operation requires, including boundaries the core does
not name, so adopting it would widen a Core requirement rather than
add a feature beside it.
9. Decision to Effect
A policy decision and an external effect are separate facts about
separate moments. The records of Section 7 carry the decision side
and the boundary's own observation after dispatch. The effect side
needs evidence a verifier resolves under Section 7.5. This section
states what a verifier may carry across that gap, what it may not,
and what it reports when the evidence it holds does not settle the
question.
This section answers five questions, separately, and never lets an
answer to one stand in for an answer to another. Was the action
authorized. Was it still admissible at the moment of admission. Was
it admitted. Was dispatch attempted. Was the external effect
established. A deployment that can answer the first and reports it
as an answer to the fifth has lost four findings.
Pidlisnyi Expires 1 April 2027 [Page 109]
Internet-Draft APS September 2026
The stage vocabulary this section uses has seven positions: proposed,
then authorized or denied, then admitted or refused, then dispatch
attempted, then result observed, then external effect established or
not established, then settled or compensated. The positions are
findings and not record types. Section 9.6 states which of them any
record in this document carries.
One of the five questions has no durable answer in this revision.
The admission transition produces no record. Whether an approval was
consumed is enforcement-boundary state keyed by the approval's
identity, and it is not content of any record this document defines,
so a verifier without access to that state reports the approval-state
axis as not established and can reach no further. Section 19.2.11
carries what that leaves open and what this document requires until
it is settled.
Everything in this section is a Candidate feature except the Core
restatements Section 9.1 and Section 9.8 name. It is specified here
and tested against this text. A Candidate part of it is normative
for an implementation claiming the feature and is not a requirement
of APS Core conformance. No part of it is a conformance claim.
9.1. Relations Between a Decision and an Effect
Four relations sit between a valid authority artifact and an effect
in the world. None of them is transitive, and a finding about one is
not a finding about the next.
1. A valid authority chain does not establish that an enforcement
boundary authorized an action.
2. An authorization does not establish that the exact authorized
call was the call dispatched.
3. An exact dispatched call does not establish that the effect was
reached only through the boundary that admitted it.
4. Dispatch does not establish that the intended effect occurred.
A verifier MUST report each of these as its own finding. It MUST NOT
derive a later one from an earlier one, and MUST NOT report a finding
it did not establish. A caller holding a report on one of them MUST
NOT read it as a report on another. This is the axis discipline of
Section 7.6 applied across the decision and the effect rather than
within one record.
Pidlisnyi Expires 1 April 2027 [Page 110]
Internet-Draft APS September 2026
Where a verifier holds a receipt and a decision, the binding between
them is a recomputation, not a presumption. The reference is rebuilt
under Section 7.4 from the full decision evidence together with the
action reference the receipt itself carries, and it MUST equal the
receipt's decision_ref. A decision supplied alongside a receipt that
does not bind to it is not evidence about that receipt, and a
verifier MUST settle the binding before it reads any member of the
decision, including its validity window. Reading a window off a
decision that belongs to a different receipt reports a temporal
relation the verifier never checked.
The four relations were named on [COSAI-149], where the last three
are stated as "an authorized action does not imply the exact
authorized call ran", "an exact authorized call does not imply
execution was non-bypassable" and "execution does not imply the
intended effect occurred". The candidate corpus this section is
written against isolates those three.
What this subsection does not establish. It does not establish that
a verifier can reach any of the four findings from signed records
alone. Three of the four need evidence from outside the record set.
It does not establish an order in which a deployment must attempt
them. It states only that a finding on one is not a finding on
another.
Requirements. APS-EVID-RELATIONS-NOT-TRANSITIVE, a verifier reports
each of the four relations as its own finding, derives no later one
from an earlier one, and reports no finding it did not establish.
Specified, not exercised. APS-REC-DECISION-REF-RECOMPUTED, the
decision reference is rebuilt from the full decision evidence and the
receipt's own action reference and must equal the receipt's
decision_ref. That is the requirement Section 7.3.3 states with a
keyword and Section 7.6 step 8 performs, restated here and not added
here, and receipt-decision-relation exercises it by asserting
DECISION_REF_MISMATCH over its seven vectors. APS-REC-DECISION-
BINDING-BEFORE-READ, the binding is settled before any member of the
decision is read, including its validity window, which the closed
core does not state. Specified, not exercised: no vector asserts the
ordering of the binding check against the temporal check.
Status: Core for one proposition, carried by APS-REC-DECISION-REF-
RECOMPUTED, which restates Section 7.3.3 and Section 7.6 step 8. The
rest of this subsection is a Candidate feature, normative for an
implementation claiming it and not a requirement of APS Core
conformance, and the additions are the four non-transitive relations
and the ordering rule of APS-REC-DECISION-BINDING-BEFORE-READ.
Related fixture families: receipt-decision-relation, 7 vectors.
action-result-binding, 6 cases. approval-single-use, 9
Pidlisnyi Expires 1 April 2027 [Page 111]
Internet-Draft APS September 2026
presentations. The interop record cosai-ws4-149-decision-to-effect
in the same suite, 11 cases, which is an interop record and not a
fixture family. Exercised requirements: APS-REC-DECISION-REF-
RECOMPUTED. Implemented requirements: APS-REC-DECISION-REF-
RECOMPUTED, APS-REC-DECISION-BINDING-BEFORE-READ. Related
implementation surfaces: agent-passport-system receipt-core 7.2.0
(TypeScript) and 4.2.0 (Python) for the receipt-to-decision binding
and its temporal relation, no released package for the remaining
three relations.
9.2. The Exact Call
An approval admits one action. The permit or narrow record of
Section 7.3 is bound to the action reference it approves, and that
reference commits to the call, not to a class of calls.
At the next authorization boundary the boundary MUST compare the call
it is about to admit against the action the approval names, and MUST
NOT admit a call whose action reference differs from it. An argument
changed after the decision produces a different action reference, so
the comparison catches it without any separate argument-level rule.
A refusal on that ground is a finding in its own right and the
boundary SHOULD record the cause it attributes the refusal to. Where
a refusal carries no attributed cause, a verifier MUST NOT read it as
a finding about the exact call, because a refusal on its own does not
say which boundary refused or why.
What this subsection does not establish. It does not establish that
admitting the call was the right decision under whatever policy
governs the deployment. A call can match its approval exactly and
still be a policy mistake. It does not establish that the arguments
mean what the requesting agent intended them to mean. The comparison
is between references over canonical bytes, not between intentions.
Requirement. APS-ENF-EXACT-ACTION-MATCH, the boundary compares the
call it is about to admit against the action the approval names and
admits no call whose action reference differs. Specified, not
exercised.
Pidlisnyi Expires 1 April 2027 [Page 112]
Internet-Draft APS September 2026
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: approval-single-use, action-result-binding,
actionref-canonical, and the interop record cosai-ws4-149-decision-
to-effect in the same suite, which is an interop record and not a
fixture family. Implemented requirements: none. Related
implementation surfaces: no released package for the boundary-side
comparison. agent-passport-system 7.2.0 (TypeScript) and 4.2.0
(Python) recompute the action and decision references the comparison
reads.
9.3. Bypass and the Mediation Assumption
This document establishes that a governed path was valid. It does
not establish that no other path reached the same effect. That
assumption is load bearing, and a deployment that does not hold it
loses the third relation of Section 9.1 and nothing else in this
document replaces it.
A verifier that cannot establish coverage over the paths to an effect
MUST NOT report that the effect was reached only through the boundary
that admitted it. One observed use of a path that did not pass the
boundary settles that finding negatively on its own. The absence of
an observed alternate path settles nothing about paths outside what
was actually observed.
A coverage premise is supplied to the verifier and is not established
recursively by the same check. Where one is supplied, it MUST name
the scope it covers and the claim instance it is bound to, and a
premise whose scope or claim differs from the one being evaluated
leaves the finding not established rather than settled either way. A
premise that is asserted rather than established is not a premise for
this purpose.
A verifier that holds the boundary's admission state MUST resolve a
claim that a credential use went through the boundary to the
admission that covers it. Where that verifier holds the admission
state and the claim resolves to no admission, the claim is malformed
input, not a weaker finding, because accepting it would let a
relabelling turn a negative finding into an unsettled one. Where the
boundary's admission state is not available to the verifier, the
coverage claim is not established, and the verifier reports neither a
governed path nor a malformed claim.
Pidlisnyi Expires 1 April 2027 [Page 113]
Internet-Draft APS September 2026
What this subsection does not establish. It does not establish that
no alternate path exists anywhere. A coverage premise is scoped, and
a path outside that scope is a path the verifier did not look at, in
either direction. It does not establish that the boundary is the
only way to reach the effect. It does not enumerate paths, and
nothing here is a completeness claim.
Requirements. APS-ENF-NO-COVERAGE-NO-BYPASS-CLAIM, a verifier that
cannot establish coverage over the paths to an effect does not report
that the effect was reached only through the boundary that admitted
it. APS-ENF-COVERAGE-PREMISE-SCOPED, a coverage premise names the
scope it covers and the claim instance it is bound to, and a premise
whose scope or claim differs leaves the finding not established.
APS-ENF-COVERAGE-RESOLVES-TO-ADMISSION, a verifier holding the
boundary's admission state resolves a claim of a governed path to the
admission that covers it and treats a claim resolving to no admission
as malformed input, and where that state is not available to the
verifier the coverage claim is not established. All three are
specified, not exercised: the interop record settles the negative
direction on an observed alternate path and no vector establishes
coverage.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: cached-authorization-revocation, runtime-authority-
denial-continuity, conflicting-status-sources, and the interop record
cosai-ws4-149-decision-to-effect in the same suite, which is an
interop record and not a fixture family. Implemented requirements:
none. Related implementation surfaces: no released package.
9.4. Effect Verification
An action-result record attests what the enforcement boundary
observed after dispatch, as Section 7.3 states. A verifier MUST NOT
report an effect as externally established from an action-result
record alone, whatever its status member says and whatever effect_ref
it carries.
Where a deployment compares an executing tool's own report against a
read-back obtained independently of that tool, three outcomes follow.
Where the two agree, the verifier may report agreement between two
records. Where they disagree, the verifier MUST NOT report the
effect as established. Where the read-back cannot be obtained, the
verifier MUST report the effect finding as not established and MUST
name the source it could not obtain.
Pidlisnyi Expires 1 April 2027 [Page 114]
Internet-Draft APS September 2026
A runtime status value that names its own indeterminacy is evidence
about the run. A verifier MUST NOT read it as a report about the
effect finding, in either direction. The two are different objects:
one says what the executing system observed, the other says what the
evidence establishes.
What this subsection does not establish. Agreement between a self-
report and a read-back does not establish that the action under test
caused the state read back. Something else may have produced the
same state, or the state may have held before the call ran. It does
not establish that the read-back source is trustworthy. A verifier
that treats the read-back as the arbiter is reporting agreement
between two records and not ground truth. Establishing the standing
of the read-back source is a separate question this document does not
answer.
Requirements. APS-EVID-EFFECT-NOT-FROM-RESULT, a verifier does not
report an effect as externally established from an action-result
record alone, whatever its status member says. APS-EVID-READBACK-
OUTCOMES, disagreement between a self-report and an independent read-
back does not establish the effect, and an unobtainable read-back
gives not established with the unobtainable source named. Both are
specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: action-result-binding, lifecycle-evidence-and-
record, accountability-record, and the interop record cosai-ws4-149-
decision-to-effect in the same suite, which is an interop record and
not a fixture family. Implemented requirements: none. Related
implementation surfaces: no released package.
9.5. When the Evidence Is Not Enough
A finding about any of the relations of Section 9.1 has three
outcomes and not two. The property is established, the property is
settled negatively, or the evidence does not settle it. The third is
not a weak form of the second. It is a statement about the
verifier's evidence, not a statement about the world.
A verifier reporting that the evidence does not settle a property
MUST name what is missing, and the name MUST identify a source, a
freshness bound or a coverage claim rather than restating the
property. A caller MUST NOT collapse that outcome into either of the
other two. A deployment MAY deny an action on it, and the denial
states the unsettled property as its reason.
Pidlisnyi Expires 1 April 2027 [Page 115]
Internet-Draft APS September 2026
False and not established stay apart in the record. A verifier that
establishes an alternate path was used reports a negative finding. A
verifier that cannot establish coverage reports that it cannot. A
record that writes the second as the first claims a finding nobody
made, and a record that writes the first as the second loses one.
What this subsection does not establish. It does not define a code
vocabulary for what is missing. The names a verifier reports are its
own and are not protocol constants. It does not say how a deployment
should act on an unsettled finding beyond permitting denial. It does
not make an unsettled finding a defect in the records that were
presented.
Requirement. APS-EVID-MISSING-NAMED, a verifier reporting that the
evidence does not settle a property names what is missing, and the
name identifies a source, a freshness bound or a coverage claim
rather than restating the property. Specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: activation-not-established, conflicting-status-
sources, revocation-resolution-forward-compat, lifecycle-evidence-
and-record, and the interop record cosai-ws4-149-decision-to-effect
in the same suite, which is an interop record and not a fixture
family. Implemented requirements: none. Related implementation
surfaces: agent-passport-system lifecycle-state 7.2.0 (TypeScript)
and 4.2.0 (Python), both experimental, for the verdict and boundary-
outcome vocabulary, no released package for the decision-to-effect
properties.
9.6. Execution States That Are Not Synonyms
Eight findings about one action are routinely written as if they were
one. They are not, and a record that uses one name for another loses
the distinction permanently.
authorized A boundary evaluated the policy chain and issued an
approval bound to the action.
admitted That approval was consumed at the next authorization
boundary, after the rechecks Section 7.3 requires.
dispatch attempted The boundary handed the call onward. Nothing
about the downstream system follows from this alone.
downstream response observed The boundary observed a response. This
is what an action-result record attests.
Pidlisnyi Expires 1 April 2027 [Page 116]
Internet-Draft APS September 2026
effect externally established Evidence resolved outside the boundary
establishes the effect. This needs Section 9.4 and is never
carried by the record alone.
settled A reservation the approval created against a bounded
quantity was closed out at the amount actually used.
compensated A later action reversed or offset the effect. This is
its own action with its own authorization.
unknown The boundary reached no observation. This is the status
member value an action-result record carries for that case.
A verifier MUST NOT report one of these findings from evidence that
establishes another. In particular, it MUST NOT report an effect
externally established from an admitted approval, and MUST NOT report
an action admitted from an approval that was issued.
This document defines no member name, enumeration or wire encoding
for the eight. The status member of an action-result record carries
succeeded, failed and unknown, as Section 7.3 defines, and those
three do not partition the list above. Settled and compensated are
stated here because the distinctions are real in the case corpus, and
no fixture family in the conformance suite exercises either of them.
They are informative in this document for that reason.
What this subsection does not establish. It does not add a state
machine. It does not require a deployment to record all eight, or to
record any of them as a distinct artifact. It does not establish
that the eight are exhaustive.
Requirement. APS-EVID-STATES-NOT-SYNONYMS, a verifier does not
report one of these findings from evidence that establishes another,
and in particular reports neither an effect externally established
from an admitted approval nor an action admitted from an approval
that was issued. Specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. The feature
covers authorized, admitted, dispatch attempted, downstream response
observed, effect externally established and unknown. Settled and
compensated are informative here, because no family exercises either.
Related fixture families: approval-single-use, action-result-binding,
cached-authorization-revocation, and the interop record cosai-
ws4-149-decision-to-effect in the same suite, which is an interop
record and not a fixture family. Implemented requirements: none.
Related implementation surfaces: no released package.
Pidlisnyi Expires 1 April 2027 [Page 117]
Internet-Draft APS September 2026
9.7. An Indeterminate Result After Dispatch
An action-result record with status unknown says the boundary reached
no observation. It does not say the effect failed to occur, and a
verifier MUST NOT read it as either outcome.
A consumed approval admits no further dispatch. A later attempt MUST
obtain a fresh authorization decision and MUST NOT reuse the consumed
approval, which Section 7.3 already makes unusable a second time.
The rest of this paragraph is informative. A deployment that reaches
the same effect by a different call, a different tool or a different
path has not continued the first attempt, and the rule above still
applies to each attempt on its own, because it is stated on the
approval a boundary consumed. This revision defines no identity for
an effect, so a verifier cannot establish that two calls reach one
effect, and the rule is not stated over an effect identity.
Where the action carries a reversibility ceiling at which no
compensating action exists, a deployment that retries on an unknown
result risks a second effect it cannot undo, and the record of the
first attempt does not say whether the first effect occurred. This
document states no normative retry rule for that case. No fixture
family exercises one, and the deduplication mechanisms deployments
use for it, including idempotency keys and at-least-once delivery,
resolve to execution behaviour rather than to an authority finding.
The case corpus records them as boundary cases for that reason.
Compensation is a new record. A compensating or reversing action is
separate authority with its own authorization boundary and its own
records, and its record refers to the prior action rather than
amending it. A later finding about an earlier action, including a
finding that the earlier effect did occur, is recorded the same way.
A verifier MUST NOT treat a later record as having replaced an
earlier one, and both MUST remain independently verifiable. Whether
an operation interrupted at an authorization boundary resumes,
restarts, compensates or stops is open and is not settled here.
What this subsection does not establish. It does not establish that
a compensating action exists for any effect, or that a party holds
authority to take one. It does not define a record type for
compensation. It does not establish what the first effect was. An
unknown result stays unknown until evidence outside the record set
settles it, and a compensation record does not retroactively settle
it.
Pidlisnyi Expires 1 April 2027 [Page 118]
Internet-Draft APS September 2026
Requirements. APS-ENF-RETRY-NEW-DECISION, a consumed approval admits
no further dispatch, and a later attempt obtains a fresh
authorization decision and does not reuse the consumed approval.
APS-ENF-COMPENSATION-NEW-RECORD, a compensating action carries its
own authorization boundary and its own records, a verifier does not
treat a later record as having replaced an earlier one, and both
remain independently verifiable. Both are specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: authority-epoch-rollback, conflicting-status-
sources, runtime-authority-denial-continuity, approval-single-use,
action-result-binding, and the interop record cosai-ws4-149-decision-
to-effect in the same suite, which is an interop record and not a
fixture family. Implemented requirements: none. Related
implementation surfaces: no released package.
9.8. The Reservation and Retry Contract
This subsection is informative. It adds no requirement. It reads
four sections of the closed core together and states the single
contract they hold between them, because those four sections are
where an implementer most often assembles two contracts by mistake.
The reservation contract is the core's, and it has four moments.
Reserve at approval: Section 5.3 places the reservation against the
boundary-held cumulative total at the moment the approval is issued,
and Section 5 requires the reservation to succeed against every
bounded ancestor in the selected chain before dispatch. Complete at
admission: Section 7.3.2 requires the boundary to verify the approval
has not expired, atomically consume its receipt_id, recheck time and
revocation state, and complete any spend reservation, all at the
moment the approval is consumed to admit dispatch. Settle after the
result: Section 4.4 moves every ancestor counter from reserved to
committed on successful settlement. Release only before dispatch or
on trusted evidence that dispatch did not occur, which is the only
release Section 4.4 permits.
The reservation is keyed by action_ref and its footprint is the
action_ref, the unit, the amount and the set of bounded ancestor
delegation identifiers. A request presenting a footprint already
reserved and not yet settled or cancelled is a retry of the same
reservation and the boundary reserves no second amount for it. A
request under the same action_ref whose unit, amount or bounded
ancestor set differs is conflicting reuse and is rejected.
Pidlisnyi Expires 1 April 2027 [Page 119]
Internet-Draft APS September 2026
An idempotent reservation lookup is not permission to dispatch again.
That is entailed by Section 7.3.2, under which only an approval that
has neither expired nor been consumed admits dispatch. Recognising a
footprint tells the boundary that it already holds a reservation. It
does not tell the boundary that the approval is still unconsumed, and
the approval is what admits dispatch. The three identities are
separate and stay separate: the reservation footprint, keyed by
action_ref, the consumable approval identity, keyed by the policy-
decision record's receipt_id, and the agent nonce, which the intent
record carries inside the action input object that action_ref commits
to and which the boundary refuses when the same agent reuses it
inside the deployment's replay window, as Section 5.1 requires. A
consumed approval does not become reusable because its reservation is
still outstanding.
What this leaves open is the recovery contract. Nothing in this
revision says what a boundary does after a crash between consumption
and dispatch, how two concurrent admissions on one approval resolve
beyond the requirement that consumption be atomic, or how an
operation resumes without repeating its effect. Section 19.2.12
carries that, and it is the one thing a durable admission record
would have to define before it could enter.
Requirement identifiers for the four core moments, so that a claim
can cite them: APS-ENF-RESERVE-AT-APPROVAL, APS-ENF-COMPLETE-AT-
ADMISSION, APS-ENF-SETTLE-AFTER-RESULT, APS-ENF-RELEASE-PRE-DISPATCH-
ONLY, and APS-ENF-CONFLICTING-REUSE-REJECTED. All five are
requirements of the closed core, restated here and not added here.
Appendix D records their coverage.
What this subsection does not establish. It does not establish that
any released package holds a reservation ledger, and none does,
because the enforcement boundary is not a published package. It does
not establish that a deployment's ledger is linearizable, which
Section 4.4 requires for live spend status to be determinate at all.
9.9. Chain Validity Is Not Permission to Execute
This subsection is informative and states no requirement. No fixture
family in the conformance suite exercises it, which is a fact about
the corpus and not the reason.
Whether an authority chain is valid and whether the action it
authorizes is permitted by rules outside that chain are separate
findings. A restriction from outside the chain can block execution
with no event anywhere in the chain, and removing the restriction
restores execution on the unchanged chain without creating new
authority. A verifier that returns one of those findings is not to
Pidlisnyi Expires 1 April 2027 [Page 120]
Internet-Draft APS September 2026
be read as having answered the other. The reason-code rule of
Section 4.6 is what keeps them apart in a record: a restriction from
outside the chain does not make the chain invalid, it denies the
action.
Block and release are not always symmetric. Where what changed is
which party holds the resource rather than a restriction on reaching
it, no release restores anything, and the case corpus carries that
counterexample against any symmetric reading. Where the represented
principal itself changes rather than being restricted, this is not
the finding that applies.
What this subsection does not establish. It does not ask a verifier
to decide whether an action is lawful. It does not claim a
restriction pauses descendants. It says nothing about whether any
legal doctrine applies to an AI agent, and no case behind it is a
source of rules for one.
9.10. A Valid Grant Can Be Unexecutable
This subsection is informative and states no requirement. No fixture
family in the conformance suite exercises it, which is a fact about
the corpus and not the reason.
An authority artifact can be valid, unexpired, unexhausted and under
no live restriction while the target, the executor or the capability
it names no longer exists. The artifact verdict is unchanged. The
execution attempt fails, and the record carries the referent that
could not be resolved. A verifier reporting such an artifact
invalid, expired, revoked or suspended reports a lifecycle event that
did not happen.
Unexecutable is an execution outcome and not an artifact verdict.
This document proposes no additional verdict for it.
What this subsection does not establish. It does not prescribe which
party re-points a grant whose referent is gone, or whether that party
may. It does not claim the authority is unaffected in the world,
since a grant naming a permanently absent executor may well be worth
revoking. It claims only that nothing in the grant's own lifecycle
has changed. It does not cover a referent that changed rather than
vanished.
Pidlisnyi Expires 1 April 2027 [Page 121]
Internet-Draft APS September 2026
9.11. Worked Examples
The five examples below are informative. Each carries a state trace
with six columns, and each walks one situation through the records
this document defines, the lifecycle transition it turns on, the
decision, the point at which an approval is consumed to admit
dispatch, the result, and what an offline verifier holding only the
records can and cannot conclude. Each names the case identifiers in
Appendix C that the situation comes from and the fixture families
that exercise the shapes involved. Naming a family records that
vectors for that shape exist. It does not make any statement in an
example a conformance result.
The examples use no record shape this document has not already
defined. Field names are those of the authority delegation record in
Section 4.1 and of the receipt envelope and stages in Section 7.1 and
Section 7.3. Verdict and outcome names are those of Section 2.3, and
the lifecycle states are those of Section 8. Reason codes are the
module strings the reference implementations carry.
9.11.1. A Purchasing Grant Narrowed by a Subagent
A principal issues a root authority delegation to a procurement
agent. Its scope facet grants commerce:checkout, its spend facet
bounds per_action and cumulative in minor units of one currency, its
depth facet leaves two hops remaining, and its time facet closes at
the end of the quarter. The procurement agent issues a child
delegation to a subagent that handles one supplier. The child
narrows scope to the one supplier's catalogue, lowers per_action,
keeps cumulative at or below the parent, and sets depth remaining to
one.
The lifecycle transition is issuance, and nothing about the parent
changes. The child is a new artifact whose issuance validity rests
on the issuer's standing at the moment it was signed. Because the
issuer checks the parent's signature and temporal validity before
signing, per the issuance obligations in Section 4.6, a child under
an expired parent is refused at the issuer rather than left for a
later verifier.
The subagent then submits one purchase. It emits an action-intent
record whose subject_agent is itself, whose delegation_ref is the
child delegation, and whose action_ref commits the action input
object. The enforcement boundary evaluates the single root-to-leaf
chain the subagent presented, issues a policy-decision record with
verdict permit, and reserves the amount against the boundary-held
cumulative total. At the next authorization boundary, which is the
moment that approval is consumed to admit dispatch, the boundary
Pidlisnyi Expires 1 April 2027 [Page 122]
Internet-Draft APS September 2026
rechecks time and revocation state, atomically consumes the
decision's receipt_id, and dispatches. The action-result record
carries status succeeded and an effect_ref.
Three narrowing failures are what this shape is worth walking. A
child that widens scope is no wider than its parent only when every
component comparison succeeds, so a widened child yields
scope_not_covered and an invalid chain. A child issued past the
parent's declared depth is a distinct failure from a scope failure,
which is LC-H-008. A subagent that holds a scope and hands it to a
process it spawned has not thereby acquired authority to confer it,
which is LC-E-006. If the subagent also holds a second chain from an
unrelated root, the two are never combined: each action selects one
chain, and an amount above the presented chain's own ceiling but
below the two ceilings added together is denied, with
chain_set_presented_as_one where a caller presents both as one. LC-
C-012 is the case that forces this to be a refusal to union rather
than a refusal to coordinate.
The trace below has six columns, split into two tables keyed by step
so that each half fits the page width. Columns one to three are the
state before the step, the artifact or event, and the verifier rule
that applies. Columns four to six are the new authority state, the
next action the state permits, and the evidence available afterwards.
Pidlisnyi Expires 1 April 2027 [Page 123]
Internet-Draft APS September 2026
+======+============+=======================+======================+
| Step | State | Artifact or event | Verifier rule |
| | before | | |
+======+============+=======================+======================+
| 1 | no | root | issuer standing is |
| | authority | AuthorityDelegationV1 | fixed at issuance |
| | for the | signed by the | |
| | subagent | principal | |
+------+------------+-----------------------+----------------------+
| 2 | root | child | no facet wider than |
| | valid, two | AuthorityDelegationV1 | the parent under its |
| | hops | narrowing scope, | component order |
| | remaining | per_action and depth | |
+------+------------+-----------------------+----------------------+
| 3 | chain | action-intent receipt | intent is a |
| | valid to | committing the action | declaration and not |
| | the leaf | reference | an admission |
+------+------------+-----------------------+----------------------+
| 4 | chain | policy-decision | one root-to-leaf |
| | valid, no | receipt, verdict | chain, no union |
| | approval | permit, amount | across chains |
| | | reserved | |
+------+------------+-----------------------+----------------------+
| 5 | approval | consumption at the | recheck time and |
| | unconsumed | enforcement boundary | revocation, consume |
| | | | atomically, complete |
| | | | the reservation |
+------+------------+-----------------------+----------------------+
| 6 | dispatched | action-result | an observed outcome |
| | | receipt, status | is not an external |
| | | succeeded, effect | effect |
| | | reference present | |
+------+------------+-----------------------+----------------------+
Table 2: Purchasing grant narrowed by a subagent: state before,
event, and verifier rule
Pidlisnyi Expires 1 April 2027 [Page 124]
Internet-Draft APS September 2026
+======+================+===============+=======================+
| Step | New authority | Permitted | Evidence afterwards |
| | state | next action | |
+======+================+===============+=======================+
| 1 | root valid | issue a child | the signed root |
| | | inside the | |
| | | root facets | |
+------+----------------+---------------+-----------------------+
| 2 | chain valid to | declare an | two signed |
| | the leaf | intent | delegations |
+------+----------------+---------------+-----------------------+
| 3 | unchanged | seek a | the intent receipt |
| | | decision | |
+------+----------------+---------------+-----------------------+
| 4 | approval | present the | the decision receipt |
| | exists and is | approval at | |
| | unconsumed | the boundary | |
+------+----------------+---------------+-----------------------+
| 5 | approval | dispatch the | none durable, the |
| | consumed | exact bound | approval-state axis |
| | | call | stays not established |
+------+----------------+---------------+-----------------------+
| 6 | unchanged, the | resolve the | the three-record |
| | reservation | effect | chain |
| | settles | evidence | |
+------+----------------+---------------+-----------------------+
Table 3: Purchasing grant narrowed by a subagent: new state,
permitted next action, and evidence afterwards
An offline verifier holding the two delegations, the three receipts
and the action input object can conclude that the chain narrows at
each hop, that the receipt identifiers and signatures recompute, that
the action binding holds because the supplied action input object's
agent_id equals the record's subject_agent, and that the decision
reference rebuilds from the decision evidence. It cannot conclude
that the approval was consumed once, because whether a decision's
receipt_id has been consumed is boundary state and not content of the
record, so the approval-state axis is not established. It cannot
conclude that the cumulative total across the subtree was correct,
because the boundary holds that total. It cannot conclude that the
purchase reached the supplier, because the action-result record
attests to what the boundary observed.
Pidlisnyi Expires 1 April 2027 [Page 125]
Internet-Draft APS September 2026
Families. lifecycle-subdelegation-edges, 13 cases. lifecycle-
conferral-without-authority, 10 vectors. single-chain-selection, 6
cases. chain-selection-no-union, 11 cases. lifecycle-purpose-
exhaustion, 21 events, on an unmerged candidate branch. issuance-
refusal-expiry, two parts, issuance and verification.
What this example does not establish. It does not establish that the
subtree total was enforced, that the supplier received anything, or
that the deployment's own facets are the seven this document defines.
It does not establish that the child was the only child the parent
issued.
9.11.2. An Employee Leaves with In-Flight Descendant Work
A bookkeeping agent runs under a chain rooted in an organization and
issued by an employee acting for an office. Descendants of that
chain have work in progress. The employee resigns.
The departure is not a revocation. It is an external event, and its
effect depends on the authority relationship and the rules that
govern it. Two findings stay separate. Whether the grant was
validly issued turns on the issuer's standing at issuance and does
not change with the departure. What the grant continues to depend on
is a separate question about the present. Where the record cannot
distinguish the principal, the issuer and the relevant dependency,
continuation has not been established, and not established is
ignorance rather than a finding that the chain is invalid.
Suppose the organization revokes the employee's issuing authority.
At the next authorization boundary, the old grant cannot authorize
any new effect. Once a verifier establishes the revocation under the
freshness rules this document states for chain verification, every
chain containing the revoked delegation is invalid with reason
revoked, which is Section 8.2.1, whether or not any record names the
descendant and whether or not the descendant was ever enumerated.
Replacement authority is a fresh grant from a principal who currently
holds authority, and the successor's grant covers what the successor
issues, not the departing principal's whole tree.
What happens to the work already in flight is a different question,
and this document does not answer it in general. It answers one
part. Effects already completed stand. A decision already consumed
to admit dispatch is not undone by a later revocation, and an action-
result record issued after the consumed decision's valid_until has
passed is not invalid on that ground alone, because execution and
observation can complete after the approval is consumed. Whether the
operation resumes, restarts, compensates or stops is open, and
Section 19.2.2 states why. LC-B-029 supplies one instrument's
Pidlisnyi Expires 1 April 2027 [Page 126]
Internet-Draft APS September 2026
concrete boundary, a receiving institution's acceptance, after which
a mid-flight authority change no longer stops the order. LC-E-013 is
the same interval from the agent's side, where invalidation arrives
mid-run rather than at the next gateway check.
A handover can be ordered differently from a compromise. A planned
handover may require the incoming holder's acknowledgment, with
authority staying with the outgoing holder until it arrives, which is
LC-C-014. A compromised principal may call for revoking first and
accepting a gap. In neither case does the old chain remain the basis
for continuity.
The trace below has six columns, split into two tables keyed by step
so that each half fits the page width. Columns one to three are the
state before the step, the artifact or event, and the verifier rule
that applies. Columns four to six are the new authority state, the
next action the state permits, and the evidence available afterwards.
Pidlisnyi Expires 1 April 2027 [Page 127]
Internet-Draft APS September 2026
+======+===============+==================+=====================+
| Step | State before | Artifact or | Verifier rule |
| | | event | |
+======+===============+==================+=====================+
| 1 | chain valid, | no event | issuance standing |
| | issued by the | | does not change |
| | employee for | | with later events |
| | an office | | |
+------+---------------+------------------+---------------------+
| 2 | valid | the employee | a departure is not |
| | | resigns, no APS | a revocation |
| | | record exists | |
+------+---------------+------------------+---------------------+
| 3 | valid | the organization | an established |
| | | revokes the | revocation |
| | | issuing | invalidates every |
| | | authority | chain containing it |
+------+---------------+------------------+---------------------+
| 4 | invalid | action-result | execution and |
| | | receipt for work | observation |
| | | admitted before | complete after |
| | | the revocation | admission |
+------+---------------+------------------+---------------------+
| 5 | invalid | a new grant from | a successor does |
| | | a principal who | not inherit the |
| | | currently holds | predecessor tree |
| | | the authority | |
+------+---------------+------------------+---------------------+
Table 4: Employee leaves with in-flight descendant work:
state before, event, and verifier rule
Pidlisnyi Expires 1 April 2027 [Page 128]
Internet-Draft APS September 2026
+======+=======================+==============+=============+
| Step | New authority state | Permitted | Evidence |
| | | next action | afterwards |
+======+=======================+==============+=============+
| 1 | valid | act under | the chain |
| | | the chain | |
+------+-----------------------+--------------+-------------+
| 2 | valid, continuation | act only | none inside |
| | not established where | where | APS |
| | the evidence cannot | continuation | |
| | separate principal, | is | |
| | issuer and dependency | established | |
+------+-----------------------+--------------+-------------+
| 3 | invalid | none under | the |
| | | this chain | revocation |
| | | | record and |
| | | | a status |
| | | | observation |
+------+-----------------------+--------------+-------------+
| 4 | invalid, the | none under | the receipt |
| | completed effect | the old | chain of |
| | stands | chain | the earlier |
| | | | action |
+------+-----------------------+--------------+-------------+
| 5 | a separate chain is | act under | the new |
| | valid, the old chain | the | delegation |
| | stays invalid | replacement | records |
| | | chain | |
+------+-----------------------+--------------+-------------+
Table 5: Employee leaves with in-flight descendant work:
new state, permitted next action, and evidence afterwards
An offline verifier holding the chain, a revocation record in a
format its profile defines, and the receipts can conclude that the
chain is invalid from the point it established the revocation, and
can conclude from the receipts which actions the boundary recorded
before that point. It cannot conclude that the set of descendants
processed by a teardown was every descendant at the relevant moment,
because that is a completeness claim with a basis this document does
not define. It cannot conclude, from an audit window with no records
in it, that nothing happened in that window, which is LC-F-027. It
cannot conclude when any particular relying party learned of the
revocation, because recording a transition and observing it are
different events.
Pidlisnyi Expires 1 April 2027 [Page 129]
Internet-Draft APS September 2026
Families. sponsor-handover, 6 cases. lifecycle-organization-events,
35 cases. lifecycle-principal-events, 32 cases. ancestor-revocation-
chain, 4 cases. cached-authorization-revocation, 9 cases. lifecycle-
evidence-and-record, 12 cases.
What this example does not establish. It does not establish what the
in-flight operation should do, it does not establish that the
teardown was complete, and it does not establish that any relying
party had notice. It states nothing about whether any legal rule
about human agents applies here.
9.11.3. Two Independent Holds and One Clears
One grant acquires two causes at once, from two sources. A regulator
imposes a suspension. The organization's own compliance function
imposes a second, unrelated suspension. The chain itself is
untouched and every signature still verifies.
The lifecycle transition is suspension, not revocation, which is
Section 8.2.8 and Section 8.3.5. Suspension pauses the use of
authority and of what depends on it, and it is releasable.
Revocation is terminal for the artifact it names. The verdict is
suspended, and it names which causes remain rather than collapsing to
one flag, because causes compose and each release has to come from a
source with standing over that cause.
The regulator's release arrives. It is genuine, its signature
verifies, and the standing registry places its signer over the cause
it releases. That cause clears. The verdict stays suspended,
because the compliance suspension still stands, and a release from
one source does not reach a cause imposed by another. Two further
shapes matter. A release from a source the registry does not place
over a cause does nothing to that cause even when the record is
genuine. A release from a source that does hold standing over a
cause it did not itself impose is effective, because standing is not
authorship. LC-B-024 is the case that forces independent release,
and LC-B-011 is the case where an externally imposed restriction
needs an equally external release trigger.
Where only a restriction is left, the verdict is restricted rather
than suspended, because authority continues in reduced form under a
live constraint that does not pause it. A composition rule that is
not satisfied does not make any artifact invalid. It denies the
action, with reason composition_not_satisfied, and LC-C-011 is why a
concurrence requirement is a gate at the next authorization boundary
rather than a second chain to combine with the first.
Pidlisnyi Expires 1 April 2027 [Page 130]
Internet-Draft APS September 2026
Two timing shapes sit next to this one. A revocation recorded while
the grant was suspended still makes the chain invalid after every
cause has been released, and an unresolvable revocation answer leaves
the chain not established rather than exercisable. A queued action
that outlasts a suspension needs a live check when it fires rather
than only at the moment it was queued, which is LC-E-034, a reviewed
hypothetical whose point is that a scheduler with no view of
suspension state can reach the right answer for the wrong reason.
The trace below has six columns, split into two tables keyed by step
so that each half fits the page width. Columns one to three are the
state before the step, the artifact or event, and the verifier rule
that applies. Columns four to six are the new authority state, the
next action the state permits, and the evidence available afterwards.
Pidlisnyi Expires 1 April 2027 [Page 131]
Internet-Draft APS September 2026
+======+============+=======================+======================+
| Step | State | Artifact or event | Verifier rule |
| | before | | |
+======+============+=======================+======================+
| 1 | chain | no event | chain verification |
| | valid, no | | |
| | causes | | |
+------+------------+-----------------------+----------------------+
| 2 | valid | a suspension cause | causes standing |
| | | record from the | against one artifact |
| | | regulator | are a set |
+------+------------+-----------------------+----------------------+
| 3 | suspended, | a second suspension | causes compose and a |
| | one cause | cause from the | count does not |
| | | compliance function | satisfy the |
| | | | reporting rule |
+------+------------+-----------------------+----------------------+
| 4 | suspended, | a release record from | each named cause is |
| | two causes | a signer the standing | decided |
| | | registry places over | independently, |
| | | the first cause | standing is resolved |
| | | | outside the record |
+------+------------+-----------------------+----------------------+
| 5 | suspended, | the remaining cause | a restriction leaves |
| | one cause | is of kind | the artifact in |
| | | restriction only | force |
+------+------------+-----------------------+----------------------+
| 6 | restricted | a revocation record | illustrative |
| | | dated inside the | deployment outcome, |
| | | suspension | the chain result |
| | | | reported ahead of |
| | | | the pause state |
+------+------------+-----------------------+----------------------+
Table 6: Two independent holds and one clears: state before,
event, and verifier rule
Pidlisnyi Expires 1 April 2027 [Page 132]
Internet-Draft APS September 2026
+======+=====================+=================+================+
| Step | New authority state | Permitted next | Evidence |
| | | action | afterwards |
+======+=====================+=================+================+
| 1 | valid | act under the | the chain |
| | | chain | |
+------+---------------------+-----------------+----------------+
| 2 | suspended, one | none | one cause |
| | cause named | | record |
+------+---------------------+-----------------+----------------+
| 3 | suspended, two | none | two cause |
| | causes named | | records |
+------+---------------------+-----------------+----------------+
| 4 | suspended, one | none | two causes and |
| | cause remaining | | one release |
+------+---------------------+-----------------+----------------+
| 5 | restricted | act within the | the cause set |
| | | live constraint | as it stands |
+------+---------------------+-----------------+----------------+
| 6 | invalid | none | the revocation |
| | | | record |
+------+---------------------+-----------------+----------------+
Table 7: Two independent holds and one clears: new state,
permitted next action, and evidence afterwards
The cell marked illustrative deployment outcome is one deployment's
outcome and not a rule of this document. Section 8.3.5 requires a
verifier not to report the pause state as if it answered the chain
question, and states no order in which the two findings are reported.
An offline verifier holding the chain, the two cause records and the
one release can conclude that the chain's signatures verify, that two
causes attached, and that one release came from a signer the supplied
standing registry places over the cause it names. It cannot conclude
that no further cause exists, because it can only report on the
causes it holds. It cannot conclude a precedence order among causes,
because none is defined. It cannot conclude that the grant is
exercisable now, because that is a boundary outcome against live
state.
Families. suspension-cause-composition, 16 cases and 5 gates.
lifecycle-legal-regulatory-events, 44 vectors. lifecycle-time-and-
scheduling, 61 vectors. lifecycle-multiple-principals-and-conflict,
92 vectors. lifecycle-outside-the-chain-standing, 22 vectors.
Pidlisnyi Expires 1 April 2027 [Page 133]
Internet-Draft APS September 2026
What this example does not establish. It does not establish a
precedence order among causes, it does not establish that the cause
set it holds is complete, and it does not establish that any release
restored an exercisable state.
9.11.4. A Cross-Org Action Needing Separate Human Approval and One-Time
Admission
A settlement adds a requirement that a named official personally
certify a defined category of transactions, for the life of the
settlement. It touches no existing delegation. LC-B-026 is that
shape: a party outside the principal-agent relationship injects a new
approval gate into an otherwise unmodified, valid chain.
The chain stays valid. A transaction inside the settlement's scope
is no longer sufficient on the chain alone. The lifecycle state is
restricted rather than suspended, because the added gate does not
pause the grant. A gateway that rechecks only the chain keeps
authorizing exactly the transactions the settlement was meant to
catch, because nothing in the delegation changed.
An agent in one organization then submits an action against a target
in another. It emits an action-intent record. The enforcement
boundary evaluates the chain, the applicable policy version, and the
additional evidence its profile requires for that category, and
issues a policy-decision record with verdict permit or narrow. That
record is the consumable approval. Its receipt_id is the consumable
identity, its action_ref is the binding to the exact action, and its
valid_until is the bounded lifetime.
At the next authorization boundary, the boundary verifies the
approval has not expired, atomically consumes its receipt_id,
rechecks time and revocation state, and completes the spend
reservation. An approval already consumed, expired, or failing that
recheck does not admit execution. A deny record is terminal and is
never consumed as an approval. Consumption is what makes the
admission one-time, and an approval that is still cryptographically
valid after consumption does not admit the action a second time.
This document specifies the single-use approval bound to an
action_ref and the rules under which it is consumed. It does not
specify that the approver be a human distinct from the executing
agent, it does not specify a designation of such a requirement
carried inside delegated authority, and it does not specify
preservation of such a designation across narrowing. A deployment
that needs those states them in its profile. [WIMSE-XORG] states
them as requirements on some mechanism and selects no mechanism.
Pidlisnyi Expires 1 April 2027 [Page 134]
Internet-Draft APS September 2026
The trace below has six columns, split into two tables keyed by step
so that each half fits the page width. Columns one to three are the
state before the step, the artifact or event, and the verifier rule
that applies. Columns four to six are the new authority state, the
next action the state permits, and the evidence available afterwards.
+======+============+===================+=========================+
| Step | State | Artifact or event | Verifier rule |
| | before | | |
+======+============+===================+=========================+
| 1 | chain | an externally | illustrative deployment |
| | valid | imposed | outcome, a restriction |
| | | certification | from outside the chain |
| | | requirement, | denying the action |
| | | touching no | while the chain stays |
| | | delegation | valid |
+------+------------+-------------------+-------------------------+
| 2 | restricted | action-intent | intent is not admission |
| | | receipt | |
+------+------------+-------------------+-------------------------+
| 3 | restricted | policy-decision | the decision commits to |
| | | receipt, verdict | the evaluated authority |
| | | permit, issued | state, the policy input |
| | | after the | and the decision |
| | | required evidence | context |
| | | resolved | |
+------+------------+-------------------+-------------------------+
| 4 | approval | consumption at | single use, recheck, |
| | unconsumed | the enforcement | complete the |
| | | boundary | reservation |
+------+------------+-------------------+-------------------------+
| 5 | approval | the same approval | an already consumed |
| | consumed | presented a | approval admits nothing |
| | | second time | |
+------+------------+-------------------+-------------------------+
Table 8: Cross-org action with separate approval and one-time
admission: state before, event, and verifier rule
Pidlisnyi Expires 1 April 2027 [Page 135]
Internet-Draft APS September 2026
+======+===================+===============+======================+
| Step | New authority | Permitted | Evidence afterwards |
| | state | next action | |
+======+===================+===============+======================+
| 1 | restricted | obtain the | none inside APS |
| | | certification | |
+------+-------------------+---------------+----------------------+
| 2 | restricted | seek a | the intent receipt |
| | | decision | |
+------+-------------------+---------------+----------------------+
| 3 | approval exists | present the | the decision receipt |
| | and is unconsumed | approval at | and the resolved |
| | | the boundary | evidence reference |
+------+-------------------+---------------+----------------------+
| 4 | approval consumed | dispatch the | none durable |
| | | exact bound | |
| | | call | |
+------+-------------------+---------------+----------------------+
| 5 | unchanged | obtain a | none |
| | | fresh | |
| | | decision | |
+------+-------------------+---------------+----------------------+
Table 9: Cross-org action with separate approval and one-time
admission: new state, permitted next action, and evidence
afterwards
The cell marked illustrative deployment outcome is one deployment's
outcome and not a rule of this document. Section 9.9 is informative
and states no requirement.
An offline verifier holding the intent, decision and result records,
the chain and the decision evidence can conclude that the decision
commits to the action, the evaluated authority state, the policy
input, the decision context and the decision output, because the
decision reference rebuilds from those and the record's own action
reference. It can conclude that the decision's validity window
closed strictly after the receipt was issued. It cannot conclude
that the approval was consumed once, or consumed at all, because
consumption is boundary state keyed by the approval's receipt_id and
the approval-state axis is not established without access to it. It
cannot conclude that the named official's certification was genuine
unless the evidence reference for it resolves under the rules its
artifact_type names, and a verifier that does not resolve evidence
reports that axis as not attempted, which is indeterminate.
Pidlisnyi Expires 1 April 2027 [Page 136]
Internet-Draft APS September 2026
Families. approval-single-use, 9 presentations and a declared
defective fail set of 3. arap-binding, 12 denial-binding cases, 10
approval cases and 5 enforcement-point fallback cases, candidates
against an unmerged profile. receipt-decision-relation, 7 vectors.
lifecycle-policy-change, 13 presentations. lifecycle-legal-
regulatory-events, 44 vectors.
What this example does not establish. It does not establish that the
approval was consumed once, that the approver was a human, that the
approver was distinct from the executing agent, or that the two
organizations share a trust anchor. It states nothing about whether
any legal rule about human agents applies here.
9.11.5. A Post-Dispatch Unknown That Cannot Be Retried
An approval is consumed, the boundary dispatches, and the target
system returns nothing the boundary can classify. The connection
drops after the request was accepted for processing. The boundary
observed a dispatch and did not observe an outcome.
The action-result record carries status unknown. For unknown, both
effect_ref and error_code are null, because the boundary has no
effect to digest and no stable failure identifier to name. That is
the honest record. Writing status failed would assert a finding the
boundary does not hold, and writing succeeded with an invented
effect_ref would assert one it cannot ground.
The approval is gone. Its receipt_id was atomically consumed at the
admission point, so it cannot admit a second dispatch, and no rule in
this document restores a consumed approval. A retry is a new action,
needing a new intent, a new decision and a new admission, evaluated
against current authority and current policy. Whether the operation
should be retried at all is not an authority question. It depends on
whether the effect is idempotent at the target, and two boundary
cases record why that belongs to the target rather than to the
delegation layer. LC-E-010 is an idempotency-key retry that returns
the original result instead of re-executing. LC-E-011 is a reused
key with changed parameters that errors outright rather than silently
doing either thing.
A valid grant can be unexecutable, which is Section 9.10. Its
verdict does not change when its target, its named executor or its
named capability no longer resolves, and the unresolvable referent
belongs in the record. LC-E-002 is that shape. Unexecutable is an
execution outcome and not a verdict on the artifact.
Pidlisnyi Expires 1 April 2027 [Page 137]
Internet-Draft APS September 2026
The trace below has six columns, split into two tables keyed by step
so that each half fits the page width. Columns one to three are the
state before the step, the artifact or event, and the verifier rule
that applies. Columns four to six are the new authority state, the
next action the state permits, and the evidence available afterwards.
+======+============+=================+========================+
| Step | State | Artifact or | Verifier rule |
| | before | event | |
+======+============+=================+========================+
| 1 | approval | consumption at | single use, recheck, |
| | unconsumed | the enforcement | complete the |
| | | boundary | reservation |
+------+------------+-----------------+------------------------+
| 2 | approval | the call is | holding the input does |
| | consumed | handed to the | not establish that |
| | | effect adapter | dispatch was attempted |
+------+------------+-----------------+------------------------+
| 3 | dispatched | action-result | unknown is an outcome |
| | | receipt, status | and not the absence of |
| | | unknown, effect | one |
| | | reference and | |
| | | error code null | |
+------+------------+-----------------+------------------------+
| 4 | unknown | no event | a reservation is |
| | result | | released only before |
| | held | | dispatch or on trusted |
| | | | evidence that dispatch |
| | | | did not occur |
+------+------------+-----------------+------------------------+
| 5 | unknown | a new action- | a further attempt is a |
| | result | intent receipt | new action needing a |
| | held | for the same | fresh authorization |
| | | effect | decision |
+------+------------+-----------------+------------------------+
| 6 | unknown | separately | an external effect is |
| | result | resolved | never inferred from |
| | held | evidence about | the result record |
| | | the target | |
| | | system | |
+------+------------+-----------------+------------------------+
Table 10: Post-dispatch unknown that cannot be retried:
state before, event, and verifier rule
Pidlisnyi Expires 1 April 2027 [Page 138]
Internet-Draft APS September 2026
+======+=======================+==================+============+
| Step | New authority state | Permitted next | Evidence |
| | | action | afterwards |
+======+=======================+==================+============+
| 1 | approval consumed | dispatch the | none |
| | | exact bound call | durable |
+------+-----------------------+------------------+------------+
| 2 | unchanged | wait for a | none until |
| | | result | a result |
+------+-----------------------+------------------+------------+
| 3 | unchanged | none follows | the three |
| | | automatically | records |
+------+-----------------------+------------------+------------+
| 4 | the reservation stays | obtain | boundary |
| | outstanding | settlement | ledger |
| | | evidence | state only |
+------+-----------------------+------------------+------------+
| 5 | unchanged | a fresh decision | the new |
| | | if policy admits | intent |
| | | one | receipt |
+------+-----------------------+------------------+------------+
| 6 | unchanged, the | settle or | the |
| | external-effect axis | compensate | resolved |
| | moves for the claim | | evidence |
| | the evidence supports | | |
+------+-----------------------+------------------+------------+
Table 11: Post-dispatch unknown that cannot be retried: new
state, permitted next action, and evidence afterwards
Pidlisnyi Expires 1 April 2027 [Page 139]
Internet-Draft APS September 2026
An offline verifier holding the three receipts can conclude that the
result commits to the decision the boundary consumed, because the
result's decision reference equals that decision's and Section 7.6
step 8 recomputes it. Predecessor continuity is not established.
Each record's prev names its predecessor, and neither Section 7.3.3
nor Section 7.6 step 9 requires a verifier to resolve prev or to
report a failure where it does not match, which Section 19.2.16
records as held. It can conclude that the boundary recorded an
unknown outcome at a stated time. It cannot conclude whether the
external effect occurred, because status unknown records the absence
of an observation rather than the absence of an effect, and these are
not the same. It cannot conclude that the effect did not occur. It
cannot conclude what the grant was used for over its whole valid
window from the fact that the grant is valid, which is LC-D-025. It
cannot read an empty window in an evidence store as proof that
nothing happened in it, which is LC-F-027. Resolving the outcome
needs separately resolved evidence about the external system, and
until that resolves the outcome stays not established with the
missing source named, as Section 9.5 states.
Families. action-result-binding, 6 cases. receipt-decision-relation,
7 vectors. runtime-authority-denial-continuity, 9 cases. lifecycle-
evidence-and-record, 12 cases. lifecycle-infrastructure-failure, 30
cases.
What this example does not establish. It does not establish whether
the effect occurred, it does not establish that a retry is safe, and
it does not establish that the boundary's own observation was
complete.
10. Institutional Governance as an Authority-Source Model
This section is informative. Where a rule it describes is normative,
the rule is stated in the section this text cites, and naming a
fixture family sets the normative status of nothing. It describes
how an organization's own authority structures reach the delegation
layer this document specifies. It does not specify wire formats,
lifecycle or semantics for those structures. A profile has to define
each projection and each containment check before monotonic narrowing
can be checked across an institutional structure.
10.1. Charter, Office, Holder, Root Authority Basis, Delegation, Action
Six objects, each constraining the next.
A charter is the instrument that bounds what an organization may
authorize. An office is a named position that carries standing
authority under a charter. A holder is the party occupying an office
Pidlisnyi Expires 1 April 2027 [Page 140]
Internet-Draft APS September 2026
over a stated window. A root authority basis is what a verifier
accepts as the head of a chain for one action. It takes one of three
forms: an APS root delegation whose parent identifier is null,
authority imported from outside APS under an importing profile, or a
trust anchor the verifier's own policy accepts. Under an
institutional model the first form is the ordinary one, issued under
an office's authority, and it is where the delegation layer begins.
Accepting a basis does not establish which principal the authority
represents, which is a separate and currently unanswered question at
Section 19.2.10. This document defines no object for the step from a
principal to a first authority, and nothing in this section depends
on one. A delegation is one narrowing hop. An action is what an
enforcement boundary decides.
The holder is not the office and the office is not the charter.
Three findings that an implementation will be tempted to merge stay
apart. Whether a party currently holds an office. Whether the
office carries the authority the grant claims. Whether the charter
permits the office to carry it.
10.2. Monotonic Projection
An institutional layer reaches the delegation layer by projecting its
authority into the faceted authority vector of Section 4.1 and
applying the component orders at each layer. A charter constrains
offices, an office constrains delegations, and a delegation
constrains actions. Authority decreases at each transfer point and
never increases.
A projection is lossy where the institutional layer carries a
dimension the vector has no facet for. A profile states what it
dropped rather than widening a facet to absorb it, and an
unprojectable dimension makes the projection unsupported rather than
silently absent. A profile that invents a facet value the
institutional instrument does not supply has widened authority at the
projection, which is the failure this subsection names.
This subsection is informative and states no requirement. No family
in this suite exercises the projection itself, which is a fact about
the corpus and not the reason. The component orders and the
containment check a projection would have to satisfy are already
specified in Section 4.6, and no released package projects an
institutional instrument into the authority vector.
Pidlisnyi Expires 1 April 2027 [Page 141]
Internet-Draft APS September 2026
10.3. Departure and Succession
A holder leaving an office is an external event. It is not a
revocation, and it does not by itself remove a dependency, re-parent
authority or create replacement authority. Whether a grant issued
under an office survives the departure of the individual who signed
it is a question the governing authority model answers. Models
differ, and this document does not choose between them.
Where the delegation is bound to an office, turnover moves it and the
new occupant exercises it with nothing reissued. Where it is bound
to an identity, turnover does not move it and the new occupant needs
a fresh chain. Where the terms declare neither and the actor is not
the named subject, the binding mode is not established and a verifier
does not supply a default in either direction.
A successor does not inherit the predecessor's delegation tree. The
successor's grant covers what the successor issues, and a descendant
whose ancestor artifact was revoked stays invalid until a party with
current authority reissues it. A departure is not a revocation, and
where the delegation is bound to the office the turnover moves it
with nothing reissued. This is the rule an implementation gets wrong
most often, because inheriting the tree is the behaviour that keeps
an organization running and it is the behaviour that silently
restores revoked authority.
Informative. This subsection states no requirement, so it carries no
status block and no requirement identifier. Related families:
lifecycle-root-authority-succession, lifecycle-principal-events,
lifecycle-organization-events, lifecycle-fiduciary-succession.
Related implementation: chain verification in agent-passport-system
7.2.0 (TypeScript) and agent-passport-system 4.2.0 (Python). Office-
holder records, vacancy records and binding mode are no released
package.
10.4. Handover
A handover replaces the party responsible for an agent while the
agent keeps its identity. The agent continues. Its old authority
does not survive revocation of the ancestor it depended on, and the
replacement chain stands on its own because it was independently
issued. A handover may require the incoming holder's acknowledgment,
with authority staying with the outgoing holder until that
acknowledgment arrives, rather than an instant at which one party's
authority ends and another's begins.
Pidlisnyi Expires 1 April 2027 [Page 142]
Internet-Draft APS September 2026
Ordering is a deployment choice. A planned handover may accept a
short overlap. A compromised holder may call for revoking first and
accepting a gap. In both cases the old chain must not remain the
basis for continuity, and at the next authorization boundary after
revocation the old grant authorizes no new effect.
Informative. This subsection states no requirement, so it carries no
status block and no requirement identifier. Related families:
sponsor-handover, lifecycle-organization-events. Related
implementation: chain verification in agent-passport-system 7.2.0
(TypeScript) and agent-passport-system 4.2.0 (Python).
Acknowledgment-gated handover is no released package.
10.5. Break-Glass
A party outside the principal-agent relationship can hold standing to
replace authority it never issued. A body appointed over the
principal, a neutral forum holding a disputed root, or a collective
body acting under its own composition rule are three shapes of this.
Such a party issues a replacement grant on terms it supplies. It
does not revive the terminated grant and it does not re-parent the
old chain, so the replacement is new authority with its own scope and
its own record. In this revision such a party ends the dependent
authority by revoking its own ancestor grant where it holds one, or
through a suspension cause under Section 8.3.5. Section 4.5 names
only the issuer for a direct revocation, and direct revocation by a
party other than the issuer is open at Section 19.2.15.
A collective body's own composition is a precondition for the
validity of what it issued. Without the declared composition there
is no body action to evaluate, which is a different finding from a
defective but real action.
Where a root is disputed and held by a neutral forum, its state is
neither valid nor invalid. A verifier reports not established and
does not pick a claimant.
Informative. This subsection states no requirement, so it carries no
status block and no requirement identifier. Related families:
lifecycle-outside-the-chain-standing, lifecycle-fiduciary-succession.
No released package resolves standing held from outside the chain.
Pidlisnyi Expires 1 April 2027 [Page 143]
Internet-Draft APS September 2026
10.6. Re-Rooting
Informative. Replacing the trust root an organization's chains
descend from changes which issuers a verifier accepts, which is a
change to verifier trust policy rather than a lifecycle event on any
artifact. A verifier can stop trusting an issuer with nothing
revoked anywhere. No artifact changes and no revocation occurs. A
verifier that no longer accepts the old root returns the result
Section 4.3 gives for a root a trust policy does not accept, which is
invalid with a root-trust reason at the root's index. That is one
verifier's finding under its own policy at one moment, and a verifier
that still accepts the root returns valid on the same bytes. Those
are two different statements and a record must not merge them.
No family in this suite exercises re-rooting, and no released package
implements it, so this document states no rule for it. A deployment
that re-roots has to decide, and record, whether artifacts under the
old root are reissued, carried by a cross-signature, or left to
expire.
10.7. What This Section Does Not Establish
It specifies no institutional wire format, no charter record, no
office record and no holder registry. It does not say who publishes
an office-holder registry or how a verifier comes to accept one. It
does not resolve office vacancy, and it does not bound what an
outgoing holder may sign before leaving. It makes no claim that a
doctrine of human agency law, corporate law or fiduciary law applies
to an AI agent. Those bodies of material are a source of case shapes
for the questions above and nothing more. Where a case in this
document derives from such material, it is a source of the question,
never a source of the rule.
11. Protocol Bindings
11.1. MCP Binding
APS specifies a binding to MCP [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 5) is configured to evaluate, including any action
whose required scope is non-empty under the Scope rules of
Section 4.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
Pidlisnyi Expires 1 April 2027 [Page 144]
Internet-Draft APS September 2026
deployment precondition of the kind Section 15 describes, not an
unconditional property of the binding.
11.2. Other Bindings
This document does not specify an A2A binding. Section 11.3
specifies a binding for OAuth identity-assertion authorization
grants. Other protocol bindings are not specified here.
11.3. 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 [OAUTH-ID-JAG], 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.
Pidlisnyi Expires 1 April 2027 [Page 145]
Internet-Draft APS September 2026
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.
11.4. Adapter Contracts
An adapter carries APS authority into another protocol's request, or
carries another protocol's authority into an APS chain. Five things
can fail to survive that trip: the principal on whose behalf the
action is taken, the exact action, the authority epoch the decision
was made in, the purpose bound the grant carries, and the evidence
the grant requires before the action is admitted. This section
states what an adapter must do about a dimension that has no carrier
on the far side, and then records, per target protocol, which
dimensions survive and which do not.
The general shape of the failure is silent widening. An adapter that
drops a dimension and emits a request the far side reads as
unconstrained has produced authority the APS side never granted.
Recording the loss is what keeps it visible.
Every binding below fills one loss model, and the model has six
values. *Preserved exactly*, the target representation carries the
semantic with no change. *Transformed with equivalent semantics*, the
representation differs and the set of actions admitted does not.
*Narrowed*, the target representation admits a strict subset of what
the APS side admits. *Omitted and irrelevant to the operation*, the
semantic has no carrier and the adapter has established that the
operation does not depend on it. *Not representable*, the semantic
has no carrier and the operation does depend on it. *Externally
resolved*, the semantic crosses as a reference and the far side
resolves it under rules this document does not state.
Loss of a semantic required by the target operation or by the
applicable profile prevents a valid result. Explicit narrowing may
remain valid where the target representation preserves the narrowed
semantics. Omission of a semantic established as irrelevant to the
operation does not by itself prevent validity. A profile states, for
each APS semantic, which of the six values applies to it, as
Section 6.1 requires.
Pidlisnyi Expires 1 April 2027 [Page 146]
Internet-Draft APS September 2026
11.4.1. What an Adapter Must Do With a Dimension It Cannot Carry
An adapter MUST NOT produce a target-side authority that admits an
action the APS authority it was built from does not admit.
Where an APS dimension has no carrier in the target representation,
the adapter MUST record that dimension as unsupported, and MUST NOT
emit a value that a target-side evaluator reads as the dimension
being satisfied. An unsupported dimension and a satisfied dimension
are different findings and a verifier reports them differently.
An attribute carried across by any transcription scheme satisfies a
target-side predicate only when the target-side authority
independently permits the action. Transcribing an attribute never
supplies a scope, an audience or an actor the target-side authority
does not have.
Where the adapter re-expresses the action in the target's own terms,
the action reference MUST be recomputed from the adapter's own
payload rather than copied from the source record, and a mismatch
MUST fail closed.
Where an adapter carries a commitment that names a stage of a
pipeline, a commitment made at one stage MUST NOT satisfy a check at
another stage, and a stage name outside the closed set MUST fail
rather than default to any member of the set.
An adapter that maps an APS record into another stack's signed
envelope MUST state the canonicalization it applies, and MUST NOT
assume byte agreement with another implementation of the same
canonicalization rule. Agreement on the rule and agreement on the
bytes are separate facts.
This subsection does not establish that any released adapter
satisfies these rules across its whole surface, and it does not
establish a complete list of dimensions. It names five dimensions
that the corpus behind this document repeatedly showed being lost.
Requirements. APS-ADAPT-NO-WIDENING, an adapter produces no target-
side authority that admits an action the APS authority it was built
from does not admit. APS-ADAPT-NO-SILENT-SEMANTIC-LOSS, a dimension
with no carrier in the target representation is recorded as
unsupported and no value is emitted that a target-side evaluator
reads as the dimension being satisfied. APS-ADAPT-RECOMPUTE-ACTION-
REF, where the adapter re-expresses the action, the action reference
is recomputed from the adapter's own payload rather than copied, and
a mismatch fails closed. APS-ADAPT-STAGE-COMMITMENT, a commitment
made at one stage does not satisfy a check at another, and a stage
Pidlisnyi Expires 1 April 2027 [Page 147]
Internet-Draft APS September 2026
name outside the closed set fails rather than defaulting. APS-ADAPT-
CANONICALIZATION-STATED, an adapter states the canonicalization it
applies and does not assume byte agreement with another
implementation of the same rule. APS-ADAPT-STAGE-COMMITMENT is
exercised by k8s-receipt-admission-stage-negatives, whose five
candidate vectors reject a cross-stage digest, a mismatched stage
kind and an unknown stage name. The other four are specified, not
exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: cross-stack, 11 sub-families at the pinned commit.
actionref-canonical, 6 vectors. k8s-receipt-admission-stage-
negatives, 5 vectors. canonical-bytes, 10 vectors. Exercised
requirements: APS-ADAPT-STAGE-COMMITMENT. Implemented requirements:
APS-ADAPT-RECOMPUTE-ACTION-REF. Related implementation surfaces:
agent-passport-system 7.2.0 (npm) for the adapter surfaces, and
agent-passport-system 4.2.0 (PyPI) for the action reference forms
only.
11.4.2. Model Context Protocol
MCP [MCP] carries a tool name and an arguments object. The exact
action survives, because a name and an arguments object are enough to
recompute an action reference over the adapter's own payload.
Nothing else on this list has a carrier defined by the base protocol.
The principal, the authority epoch, the purpose bound and the
required evidence are unsupported unless a profile assigns them keys
in the _meta object, which the specification describes as the general
extension point: "The _meta property/parameter is used by MCP to
allow clients and servers to attach additional metadata to their
interactions."
An adapter that assigns _meta keys carries a further obligation that
is described in Section 11.6: the component that checks the request
and the component that runs it may not receive the same bytes.
The requirement that privileged actions pass through the boundary,
stated in Section 11.1, has no fixture in the conformance suite. The
suite's coverage inventory records it as not exercised, since no
vector asserts which actions were routed through a boundary. It is
restated here as a deployment precondition and not as an exercised
requirement.
Loss model. Exact action: preserved exactly, because the tool name
and the arguments object are enough to recompute an action reference
over the adapter's own payload. Principal, authority epoch, purpose
bound and required evidence: not representable in the base protocol,
Pidlisnyi Expires 1 April 2027 [Page 148]
Internet-Draft APS September 2026
and preserved only where a profile assigns them keys in the extension
object, in which case they are externally resolved by whatever holds
that profile.
This subsection does not establish that a profile assigning _meta
keys is interoperable with any other profile doing the same, and it
does not establish that an MCP server honours a governance key it
does not recognise.
Requirement. APS-ADAPT-MCP-EXTENSION-DECLARED, an adapter that
assigns extension-object keys for APS material states which keys it
uses and does not rely on a server honouring a key it does not
recognise. Specified, not exercised.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: cross-stack (mcp-audit-gateway-v0.6). actionref-
canonical, 6 vectors. Implemented requirements: none. Related
implementation surfaces: agent-passport-system 7.2.0 (npm).
11.4.3. Agent2Agent
This document specifies no A2A [A2A] binding. An Agent Card
describes an agent and its skills. It is not an authority record and
it names no action, so none of the five dimensions crosses at the
card layer. An adapter that derives APS scope strings from card
skills is deriving a vocabulary and not importing authority. Signing
a card establishes who published the description, which is a narrower
fact than it looks. Section 11.5 records what reproducing that
signature across two implementations showed.
Loss model. Not applicable. An Agent Card is not an authority
record and names no action, so none of the five dimensions has a
source value to carry and no cell of the model can be filled.
This subsection is informative. It does not establish that a signed
Agent Card conveys any authority, and it does not establish that
skills declared on a card correspond to actions the agent is
authorized to take.
11.4.4. OAuth Identity-Assertion Authorization Grant
The OAuth identity-assertion grant binding of this document imports a
caller-verified grant. Of the five dimensions, the principal
survives as the grant's subject. The exact action does not cross:
the grant is about access to an audience and a set of scopes, not
about one call with its arguments, so the exact action is constructed
on the APS side after import and is never imported.
Pidlisnyi Expires 1 April 2027 [Page 149]
Internet-Draft APS September 2026
The acting party is indeterminate rather than unsupported, which is a
distinction worth keeping. [OAUTH-ID-JAG] carries an actor token
parameter and then declines to say what it means: "This specification
does not define normative processing requirements for actor_token or
whether an act claim is included in the issued ID-JAG." An importer
therefore cannot read an actor claim as establishing who acted. The
reference implementation reconciles the claim against the chain leaf
literally and marks the result advisory rather than authoritative,
which is the correct handling of a field whose processing the source
specification leaves open.
The authority epoch, the purpose bound and any required-evidence
condition have no carrier in the grant and are unsupported on import.
The spend dimension is the case where the rule is already stated
normatively elsewhere in this document: a spend basis MUST NOT be
invented at import, and an external grant carrying no spend semantics
yields an unsupported projection unless an importing profile supplies
an explicit basis that verifier policy accepts. Scope projection is
lossy, so the binding keeps the grant's authorization details
verbatim beside the projection.
The audience is the one dimension that crosses and then has to be
enforced somewhere else. It is carried in the binding and not
enforced by it, and the relying party at the point of use rejects a
mismatch. The conformance corpus exercises that rule, and it
exercises it on a different object: the vectors are an RFC 8693
[RFC8693] token exchange, where an evaluation of the exchanged token
denies with the family's audience_mismatch reason at the point of
use. No fixture in the corpus carries an identity-assertion grant.
The rule is exercised, the object is not, and the status block below
says so.
The same family pins the attenuation property that the general rules
above state abstractly. A widening exchange is an invalid vector
that a runner must refuse to evaluate rather than a case with a deny
answer, an evaluation of the exchanged token reads only claims
present on it, and an attribute transcribed from the subject token
satisfies a predicate only where the exchanged token's own scope,
audience and actor conditions independently permit the action.
Loss model. Principal: preserved exactly, as the grant's subject.
Audience: preserved exactly in the binding and enforced externally at
the point of use. Exact action: not representable, and constructed
on the APS side after import rather than imported. Acting party:
externally resolved, and the source specification declines to say
what its actor token means, so an importer reads no actor claim as
establishing who acted. Authority epoch, purpose bound and required
evidence: not representable. Spend: not representable, and a spend
Pidlisnyi Expires 1 April 2027 [Page 150]
Internet-Draft APS September 2026
basis is never invented at import, so the projection is unsupported
unless an importing profile supplies an explicit basis that verifier
policy accepts.
This subsection does not establish that an identity-assertion grant
has been imported by any tested implementation, and it does not
establish that the separation of the source grant reference from the
delegation chain root has a fixture. The suite's coverage inventory
records that separation as not exercised.
Requirement. APS-ADAPT-NO-INVENTED-SPEND-BASIS, a spend basis is not
invented at import, and an external grant carrying no spend semantics
yields an unsupported projection unless an importing profile supplies
an explicit basis that verifier policy accepts. This restates a
requirement of Section 11.3 and adds nothing to it. Specified, not
exercised: the suite's coverage inventory records the corresponding
requirement as partial and its vectors are an RFC 8693 token exchange
rather than an identity-assertion grant.
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Its one
requirement identifier is an exception: APS-ADAPT-NO-INVENTED-SPEND-
BASIS restates a requirement of Section 11.3 in the closed core, and
Appendix D carries it as a Core restatement rather than as part of
this feature. Related fixture families: cross-stack (token-exchange-
attenuation-v0), 12 cases, on an RFC 8693 token exchange rather than
on an identity-assertion grant. Implemented requirements: APS-ADAPT-
NO-INVENTED-SPEND-BASIS. Related implementation surfaces: agent-
passport-system 7.2.0 (npm).
11.4.5. Authorization API
Loss model. Verdict: narrowed to the point of loss in the outward
direction, because a three-valued verdict collapses onto a boolean
and collapsing narrow to true widens the decision. Constraints,
effective authority reference, expiry and single-use semantics: not
representable in the decision object. Inward, a decision obtained
through that API is an input to admission and not an APS policy-
decision record.
This subsection is informative. No fixture family in the conformance
corpus exercises a mapping to or from the Authorization API, so
nothing here is stated as a requirement.
The direction that matters is inward, and it is narrow. An
Authorization API decision [AUTHZEN] is a boolean with optional
context: "Decision is an object that contains a REQUIRED decision key
with a boolean value, and an OPTIONAL context key with an object
Pidlisnyi Expires 1 April 2027 [Page 151]
Internet-Draft APS September 2026
value." An APS policy-decision record is not that shape. It carries
a three-valued verdict, the constraints a narrow verdict imposes, a
reference to the exact effective authority admitted, an expiry, and
single-use semantics at the next authorization boundary. None of
those four has a defined carrier in the decision object, so a
decision obtained through that API is an input to admission and not
an APS policy-decision record. Treating it as one would supply an
approval with no expiry, no binding to an exact action, and no
consumption point.
Outward, an APS verdict maps onto the boolean with loss. A narrow
verdict and its constraints have nowhere to go, and collapsing narrow
to true widens the decision.
This subsection does not establish that any implementation performs
this mapping, and it does not establish what a profile that assigned
the missing fields to the optional context object would have to
specify.
11.4.6. Workload and Agent Identity Credentials
Loss model. Not applicable in either direction. There is no
credential format on the far side of this adapter, so no APS semantic
has a carrier to be measured against and no cell of the model can be
filled.
This subsection is informative. No fixture family exercises a
mapping to a WIMSE credential format, and there is a plain reason for
that: [WIMSE-XORG] is a problem statement, and it says so in its own
abstract, "It does not specify a solution." There is no credential
format on the far side of this adapter yet, so there is nothing to
map into and no requirement to state.
What that document does carry is a requirement list, and one of its
requirements is the admission rule this document arrives at from the
evidence side. It requires evidence "bound to the specific action,
including its arguments, its target resource, and the on-behalf-of
principal", relied on at most once, and it requires that an
unrecognized designation be treated as unauthorized: "A relying party
that does not recognize a designation MUST treat the designated
action as unauthorized." The convergence is worth recording. It is
not adoption and it is not a claim that either document influenced
the other.
This subsection does not establish that APS satisfies any requirement
in that list, and it does not establish that a future credential
format in that space will carry any of the five dimensions.
Pidlisnyi Expires 1 April 2027 [Page 152]
Internet-Draft APS September 2026
11.4.7. Transparency Service Carriage
Loss model. All five dimensions: preserved exactly, because the
record travels whole rather than being re-expressed. Signer
authority: externally resolved, and registration establishes nothing
about it.
This subsection is informative. No fixture family exercises carriage
of an APS record as a signed statement to a transparency service, so
nothing here is stated as a requirement.
Carriage preserves all five dimensions, because the record travels
whole rather than being re-expressed. What carriage adds is
inclusion evidence, and what it does not add is anything about the
signer's authority to make the statement. [RFC9943] states the limit
directly: "Issuers can make false Statements either intentionally or
unintentionally; registering a Statement only proves it was produced
by an Issuer."
That maps exactly onto the separation this document already keeps
between cryptographic integrity, signer authority and external truth.
A receipt from a transparency service raises confidence that a record
was registered and has not been altered since. It moves nothing on
the authority question. An adapter that presents a transparency
receipt as evidence of authority has crossed the two axes.
This subsection does not establish that any APS record has been
registered with a transparency service, and it does not establish a
mapping from the APS receipt envelope described in Section 7.1 into a
COSE signed statement.
11.5. A2A Agent Card Signing
This section is informative. It records a cross-implementation
failure class that two independent signing implementations of the
same specification reached, and what the canonicalization vectors in
the conformance corpus do and do not cover against it.
The failure class sits above the canonicalization algorithm. Two
implementations can both apply [RFC8785] correctly, byte for byte,
and still fail to check each other's signatures, because one of them
removed a field the other signed. Canonicalization pins the bytes
for a given document. It says nothing about which document you had.
Pidlisnyi Expires 1 April 2027 [Page 153]
Internet-Draft APS September 2026
11.5.1. What Was Observed
The A2A specification requires a card to be canonicalized under
[RFC8785] before signing, and it states a field-presence rule that
runs first. Fetched from the specification repository on 2026-09-24
at commit 43e0c874d3baba68ed84b98678d7f2268438e69f, section 8.4.1:
"Fields marked with REQUIRED MUST always be present, even if the
field value matches the default."
Two implementations of that rule diverge in opposite directions, and
each divergence originates in its own language's object-to-JSON
mapping rather than in its canonicalizer. Reproduced locally on
2026-09-23 against a2a-go pull request 441 at commit
bb750f5c7913b967d8dcbe3d24537a8a84dd1a61 and a2a-python at commit
f3ac82489dd84ce9dcd3802357cb4e987ffdbb74, using only each
implementation's own public construction, serialization and signing
interfaces and one shared Ed25519 key. Six single-field cases were
built on an otherwise identical card. Of the six, three failed one
direction: an explicitly empty description, an explicitly empty
skills list, and an explicitly empty tags list on the first skill.
In each of the three the Go side kept the field in the bytes it
signed and the Python side rebuilt the card from those bytes for
verification, dropping the field again, and verified a different
payload than the one that was signed. The card was never altered in
transit. The reverse direction passed on all six, and the control
case with no empty or default values produced byte-identical
canonical payloads on both sides.
The pull request was open at the time of that run. Fetched on
2026-09-24, it is merged, and the maintainer's response to the report
reads the same way this document does about where the divergence
sits: "This is unfortunate, but python behaviour is not spec-
compliant here."
A report of the Python side of the divergence was filed by this
document's author as issue 1278 on the a2a-python repository.
Fetched on 2026-09-24, it is open, and its title names the class:
"Signing/verification canonicalization drops REQUIRED fields at their
default value, breaks cross-SDK Agent Card signature verification."
The later merge and the earlier reproduction are separate records.
The merge does not rewrite what was observed at the earlier commits.
This subsection does not establish that either implementation is
defective in general, that the divergence affects deployments in
practice, or that the merged state of the Go pull request changes the
Python side. It records six cases at three named commits.
Pidlisnyi Expires 1 April 2027 [Page 154]
Internet-Draft APS September 2026
11.5.2. What the APS Canonical-Bytes Vectors Cover
The canonical-bytes family pins the byte contract of [RFC8785] across
implementations. Ten vectors, each naming the rule it exercises,
cover the places a canonicalizer diverges without meaning to: the
decimal-to-exponential threshold and how the exponent is spelled,
negative zero, integers above the exactly-representable range and
above signed 64-bit range, key ordering by UTF-16 code unit rather
than code point, keys used exactly as given without Unicode
normalization, and recursive sorting with array order preserved. The
family runs the same ten vectors through four canonicalizers in four
languages and publishes where the bytes and the digests agree or
differ. A result there is a byte diff on ten cases and not a verdict
on any implementation.
Running those ten vectors through the Go implementation's
canonicalization entry points on 2026-09-23 produced ten matches
under both decode paths, twenty comparisons in total. The same run
against the A2A project's own canonicalization corpus separated two
further findings that are worth keeping apart from the field-presence
class: three of the eight scorable must-reject vectors were rejected,
and five unpaired surrogate vectors were not, because the decoder
substitutes the replacement character rather than refusing. That is
a decode-layer finding, upstream of canonicalization.
The actionref-canonical family covers the adjacent APS-native
property, where the action reference is a digest over the
canonicalization of a fixed four-field tuple with each scope
normalized to NFC and the scope array sorted by code point. Its
vectors include the case where code-point order and code-unit order
disagree, and two negatives on duplicate scopes, one raw and one that
collides only after normalization.
Neither family covers the failure class above. Both take a document
and pin its bytes. Whether a field was in the document is decided
before either family's first vector runs, and no vector in either
family asserts field presence against a schema's required-field rule.
Stating that gap is the point of this subsection.
This subsection does not establish that a passing canonical-bytes run
means two implementations will verify each other's signatures.
11.6. Gateway Extension Processors
This section is informative. It records one seam that an adapter
carrying APS material through a third-party MCP gateway has to
account for, and it is the concrete case behind the obligation named
in Section 11.4.2.
Pidlisnyi Expires 1 April 2027 [Page 155]
Internet-Draft APS September 2026
An MCP-aware gateway can call out to an external processor before
forwarding a call, so that the processor can allow, deny or rewrite
it. In one such interface, fetched on 2026-09-24 at commit
25702c3b561a0bc2130da75427e3debbd5b13918, the field carrying the call
to the processor is described as "JSON-RPC params as raw JSON bytes;
absent when the method has none", and the rewrite result is described
as replacing those same params, with the note that "The gateway does
not re-run other RBAC on the mutated request."
The seam is that the bytes the processor sees and the bytes the tool
sees are not the same bytes. A local reproduction on 2026-09-23,
against that same commit with a stub processor and a hand-written
upstream server that logs its raw input, sent one tool call whose
params carried a _meta member. The three captured surfaces are
below, verbatim from that run. A backslash at the end of a line is a
continuation inserted here to fit the page width and is not part of
the captured bytes. First, the client's exact request body:
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":\
{"name":"echo","arguments":{"x":1},"_meta":{"probe":1}}}
what the external processor received as the call under check:
{"name":"echo","arguments":{"x":1}}
and what the upstream server received on its own input:
{"jsonrpc":"2.0","id":2,"method":"tools/call","params":\
{"_meta":{"probe":1},"name":"echo","arguments":{"x":1}}}
The _meta member reached the tool and did not reach the check. For
an adapter that carries a passport reference, a delegation reference
or an approval reference in _meta, that is the whole problem: the
component asked to decide cannot see the material the decision
depends on, and the component that runs the call can. An adapter in
this position either carries its material where the processor can see
it, or treats the processor as unable to decide and denies rather
than defaulting.
The interface also rewrites. A processor that replaces the params
has changed the exact action, and the gateway does not re-run its
other access checks on the replacement. An adapter that recomputes
the action reference after a rewrite gets a different value than one
computed before it, which is the general recomputation rule in
Section 11.4.1 applied to a specific seam.
Pidlisnyi Expires 1 April 2027 [Page 156]
Internet-Draft APS September 2026
This section does not establish that this behaviour holds at any
other commit of that gateway, that other MCP gateways behave the same
way, or that the behaviour is a defect. It records what one pinned
build did with one call on one date. It also does not establish what
a profile assigning _meta keys for APS material should do about it,
which stays open.
12. Enforcement Gateway Reference Architecture
This section is informative. It describes one arrangement of an
enforcement boundary that runs the checks this document specifies,
taken from the open-source Agent Passport Gateway. It is a
description, not a conformance target. An implementation that
arranges these functions differently is not for that reason non-
conforming, and nothing in this section adds a requirement to the
ones stated elsewhere in this document. Deployment topology, network
interfaces and operator configuration are out of scope here.
This section does not establish that any deployment is arranged this
way, that the described arrangement is safe, or that the reference
implementation is free of defects.
12.1. Judge and Executor
In this arrangement the boundary both decides and performs. The
acting agent sends a signed request naming a tool and its arguments.
The boundary evaluates the request, calls the target itself, and
writes the record of what happened. The agent never constructs that
record. The reference implementation states the reason in its own
source: without the boundary holding execution, the library is
optional and the agent can route around it.
A policy decision point may be a separate service. Only the
enforcement boundary admits an action to dispatch. Where a decision
point is separate, it computes the decision and the boundary is the
issuer of the aps:policy-decision:v1 record that carries it, as
Section 7.3.2 requires. Approval consumption, the reservation,
dispatch and the external effect are four steps and are not one
atomic transaction in this revision. A verdict arriving from a
separate decision point is an input to admission, in the same class
as a revocation answer or a freshness answer, and it is not itself
admission. The Authorization API [AUTHZEN] draws the same line from
the other side, placing the decision point's internals outside its
own scope: "The policy language, architecture, and state management
aspects of a PDP are beyond the scope of this specification." Its
response object is correspondingly thin: "Decision is an object that
contains a REQUIRED decision key with a boolean value, and an
OPTIONAL context key with an object value."
Pidlisnyi Expires 1 April 2027 [Page 157]
Internet-Draft APS September 2026
The arrangement assumes there is no alternate privileged credential
path to the same target. If the target accepts a credential the
agent holds directly, the boundary governs one path and the other
path is ungoverned. The MCP binding in this document already states
that exclusivity as a deployment precondition rather than a property
of the binding. The assumption is load bearing and it is worth
naming plainly: an APS record establishes that a governed path was
valid, and it does not establish that no ungoverned path existed. A
verifier that cannot establish that the boundary implements the
grant's declared scope reports the wider reachable scope or reports
that the narrower scope is not established.
This subsection does not establish that the boundary is the only path
to the target, and it does not establish that a separate decision
point and the boundary evaluated the same inputs.
12.2. Admission, Consumption, Reservation and Settlement
The boundary checks before the effect, not only before the approval.
In the reference implementation the order at the next authorization
boundary after an approval is: confirm the approval is unconsumed and
unexpired, confirm the agent and the delegation still exist, recheck
revocation and status against current state rather than the state
read at approval time, recheck the governance version the approval
was granted under, recheck any cross-context permit that the approval
relied on, recheck the authority tier against the current reputation
state, mark the approval consumed, and only then call the target.
Consumption is atomic against concurrency and not only against
sequence. The reference implementation serialises execution per
agent and re-tests the consumed flag inside the serialised section,
because the test that runs before the lock lets two concurrent calls
on the same approval both pass it and both reach the tool.
Where a budget must be held rather than spent, the boundary reserves.
A hold is checked against the delegation's limit less the sum of live
holds before it is granted, and it is released on fulfilment or on
expiry. Where the budget is spent at admission instead, the
reference implementation increments the used amount inside the same
transaction that records the permit, so a permit and its charge
cannot come apart.
Settlement comes after the result. Settlement records are assembled
from recorded contributions over a closed period. They are not
produced at admission and they are not an input to it.
Pidlisnyi Expires 1 April 2027 [Page 158]
Internet-Draft APS September 2026
The cross-organizational delegation requirements in [WIMSE-XORG]
state the same ordering as a requirement on any solution in that
space: "Consumption of the reliance unit occurs only upon admission:
evaluation, exact-action matching, and refusal at any stage MUST NOT
consume it".
Two things are worth separating here, because the ordering above is
one implementation's and the obligation is this document's. The
protocol requirement is the one stated at Section 7.3.2 and
Section 5.3: at the moment the approval is consumed to admit
dispatch, the boundary verifies the approval has not expired,
atomically consumes its identity, rechecks time and revocation state,
and completes any spend reservation. This document requires no
particular order among the other checks the reference implementation
runs, and it requires none of them. It also does not make
consumption, reservation, dispatch and the external effect one atomic
transaction, and Section 9.8 states what that leaves to a deployment.
This subsection does not establish that a reservation released on
failure was released before any external effect, and it does not
establish what happens to work already in flight when authority
changes during execution.
12.3. Evidence the Boundary Produces
What the reference implementation does. A denial and a permit both
produce a record, so a refusal is evidence rather than an absence of
it. The implementation signs the denial record under the boundary's
own key. For a permit it stores what its own source calls a permit
record, with a content hash and no signature. That object is not a
receipt in the sense of Section 7.1, it is not an aps:policy-
decision:v1 record, and this document names no such object. The
implementation's source gives its reason directly: a denial is signed
as proof of restraint, a permit is treated as routine. The
structural reading is that a refusal leaves no other artifact
anywhere, so a record nobody signed is the only trace it has, while a
permitted action goes on to produce a separately signed result record
at the next stage.
What this document requires, separately. The boundary records the
policy decision, permit, narrow or deny. That record is not evidence
of admission (Section 2.2, Section 19.2.11). Section 7.3.2 defines
the signed policy-decision record and makes the boundary its issuer,
for permit, narrow and deny alike. This document states no
requirement about an additional internal permit object, defines no
wire shape for one, and places no signing obligation on one, because
it defines no such object at all. An implementation that keeps one
is keeping deployment state, not producing an APS record.
Pidlisnyi Expires 1 April 2027 [Page 159]
Internet-Draft APS September 2026
The cost of that choice belongs beside the choice. An unsigned
permit record is not attributable to the boundary by a third party.
It can be checked for integrity against its own hash by a party who
already trusts the store that holds it, and that is a different and
weaker property. A deployment that needs a permit to be presentable
as boundary-attributable evidence has to sign permits too.
This subsection does not establish that the store holding an unsigned
permit record is honest, and it does not establish that a signed
denial record was the only decision reached for that action. It does
not establish that the reference implementation's permit record and
the policy-decision record of this document are the same object, and
they are not.
12.4. Ancestor Revocation at the Boundary
At each authorization boundary the reference implementation walks the
bound chain of the delegation it selected, following each record's
stored parent link rather than re-resolving whatever parent is
current. A revoked or suspended member anywhere on that walk ends
the leaf's authority, up to and including the terminal grantor, even
when the leaf's own record still reads as active. The walk fails
closed, so a leaf whose bound chain is dead is denied even where some
other chain the same agent holds would still be live. This is the
boundary-side form of the core invariant that a chain is rejected
when any member is revoked, stated in Section 4.6.
The same walk runs a second time inside the write transaction when a
new delegation is granted under an existing one, because the first
read happens outside the lock and a revocation can commit between the
two.
Enumerating descendants is a reporting and cleanup tool in this
arrangement. It is not what makes a chain-verifiable descendant
invalid. Where a credential carries no chain a verifier can walk,
such as an opaque bearer token, an issuer-side revocation mechanism
is still needed.
This subsection does not establish that revocation state was fresh at
the moment of the walk, and it does not establish that a credential
issued outside the chain was reached at all.
12.5. What the Gateway Does Not Do
It does not decide truth about the world outside it. It records what
it evaluated and what the target returned. Whether the external
effect matched the returned result is a separate finding with
separate evidence.
Pidlisnyi Expires 1 April 2027 [Page 160]
Internet-Draft APS September 2026
It does not classify content and it does not judge whether an action
was a good idea. A permitted action is an action the presented
authority and the configured policy admitted.
Settings that identify an operator are reconciliation and not a
revocation mechanism. Removing such a setting later does not remove
a role already held.
Blast-radius preview before a revocation is read-only. It changes
nothing and it is not a revocation.
It is not a transparency service. On its own it gives no third party
the ability to detect that it presented different histories to
different parties. The reference implementation's own research notes
list an append-only log with consistency proofs, and separating the
receipt signer from the executor, as directions rather than as
present behaviour.
This subsection does not establish a complete list. It names the
limits that the corpus behind this document repeatedly turned up.
13. Conformance
An implementation of this document is not one thing. A party that
issues delegations, a party that verifies them, a party that admits
actions at the boundary and a party that reads receipts have
different obligations, and an implementation that does all four is
rare. This section defines the classes a claim is made in, the
identifiers a claim cites, the form of the claim, and the three
results an implementation reports per vector.
The executable corpus this section refers to is the APS conformance
suite [APS-CONFORMANCE], which is work by this document's author.
Nothing in this section is a statement that any implementation has
passed anything, and the corpus issues no verdicts.
13.1. Conformance Classes
An implementation claims conformance in one or more of the following
classes. A claim MUST name its classes. An implementation MUST NOT
claim a class whose obligations it does not implement, and MUST NOT
present a claim in one class as covering another.
Authority issuer. Mints delegation records. Verifies the parent
Pidlisnyi Expires 1 April 2027 [Page 161]
Internet-Draft APS September 2026
signature and temporal validity before signing a child, refuses to
issue under an expired, not-yet-valid or revoked parent, and never
issues a record whose invalidity is left for a later verifier to
find. Related fixture families: issuance-refusal-expiry,
lifecycle-conferral-without-authority.
Delegation verifier. Reads a root-to-leaf chain and returns valid,
invalid, indeterminate or unsupported. Applies the component
orders, selects one chain per action, takes no union across
chains, resolves keys at the artifact's own issuance time, and
never collapses indeterminate or unsupported into valid. Related
fixture families: chain-selection-no-union, single-chain-
selection, key-rotation-historical, ancestor-revocation-chain and
revocation-resolution-forward-compat.
Lifecycle and status verifier. Answers what is currently established
about an authority whose records are unchanged but whose
surroundings have moved. Reads status sources with a stated
freshness, reports a conflict between sources rather than picking
one silently, and distinguishes an answer that is false from one
that is not established. Related fixture families: conflicting-
status-sources, authority-epoch-rollback, activation-not-
established, suspension-cause-composition, cached-authorization-
revocation and the lifecycle families named in Appendix D.
Receipt verifier. Recomputes a receipt identifier before verifying
any signature, checks the stage and its closed result object,
resolves referenced evidence or reports it unresolved, and reports
cryptographic integrity, signer authority, referenced-artifact
resolution and policy semantics on separate axes. Related fixture
families: accountability-record, receipt-decision-relation,
action-result-binding, read-fidelity-receipt, merkle-root-parity
and instruction-provenance.
Enforcement boundary. The next authorization boundary an action
reaches after a decision. Re-validates what can have changed
since the decision was issued, consumes a single-use approval
atomically, reserves spend against every bounded ancestor, and
refuses an approval that is expired, already consumed, or
terminal. Related fixture families: approval-single-use, runtime-
authority-denial-continuity. The corpus records the remaining
boundary obligations as untested in receipt-decision-relation's
own verifier header.
Profile implementation. Holds a profile as defined in Section 6.1
Pidlisnyi Expires 1 April 2027 [Page 162]
Internet-Draft APS September 2026
and supplies its constructions to the classes above. Reports a
record naming a profile it does not hold as unsupported. Related
fixture families: key-rotation-historical, capability-binding-
drift, each of which defines its own test profile and says so.
Protocol adapter. Carries APS records or concepts over another
protocol. Records, for every concept, whether it survives the
mapping, becomes unsupported, or becomes not established, and
never widens a concept silently to fit the external construct.
Related fixture families: arap-binding and the cross-stack
families.
A requirement identifier applies to one or more of these classes,
through its area. The table below maps each area of Section 13.2 to
the classes in which a requirement carrying that area is mandatory
for a Core requirement and claimable for a Candidate one. Three
areas carry no identifier in this revision and are listed for
completeness of the taxonomy.
Pidlisnyi Expires 1 April 2027 [Page 163]
Internet-Draft APS September 2026
+=======+========================================+
| Area | Classes |
+=======+========================================+
| ID | delegation verifier, receipt verifier. |
| | No identifier in this revision |
+-------+----------------------------------------+
| PRIN | lifecycle and status verifier |
+-------+----------------------------------------+
| AUTH | delegation verifier |
+-------+----------------------------------------+
| LC | lifecycle and status verifier |
+-------+----------------------------------------+
| POL | enforcement boundary. No identifier |
| | in this revision |
+-------+----------------------------------------+
| ENF | enforcement boundary |
+-------+----------------------------------------+
| REC | authority issuer, receipt verifier |
+-------+----------------------------------------+
| EVID | receipt verifier, lifecycle and status |
| | verifier |
+-------+----------------------------------------+
| PROF | profile implementation |
+-------+----------------------------------------+
| ADAPT | protocol adapter |
+-------+----------------------------------------+
| GOV | no class in this revision, and no |
| | identifier |
+-------+----------------------------------------+
| CONF | every class, in whichever classes the |
| | claim names |
+-------+----------------------------------------+
Table 12: Identifier area to conformance class
The classes are not a maturity ladder and are not ordered. An
implementation in one class is not a partial implementation of
another. A Core requirement outside every class an implementation
claims is not an obligation on that implementation, and a claim that
omits a class is not a claim that the class was met.
What this subsection does not establish. It does not establish that
the seven classes partition the obligations of this document without
gap or overlap, that a family named against a class covers that
class, or that passing every family named against a class makes an
implementation conforming in it. The families named are the ones
that reach some obligation of the class, and the coverage each
reaches is recorded in Appendix D.
Pidlisnyi Expires 1 April 2027 [Page 164]
Internet-Draft APS September 2026
Requirement. APS-CONF-CLASS-NAMED, a claim names its classes, an
implementation does not claim a class whose obligations it does not
implement, and a claim in one class is not presented as covering
another. Specified, not exercised.
Status: Core, document requirement, specified, not exercised. APS-
CONF-CLASS-NAMED binds every conformance claim made under this
document, in every class, and is not gated by a feature a claimant
can decline. It is a requirement on a claim document rather than a
runtime check a verifier performs, of the same kind as the profile
requirements of Section 6.1, so no runtime vector reaches it and a
static claim fixture is needed before it is recorded as exercised. A
claim is the one artifact whose form this document fixes for every
claimant, because a claim that need not name its classes cannot be
read at all. Related fixture families: issuance-refusal-expiry,
lifecycle-conferral-without-authority, chain-selection-no-union,
single-chain-selection, key-rotation-historical, ancestor-revocation-
chain, revocation-resolution-forward-compat, conflicting-status-
sources, authority-epoch-rollback, activation-not-established,
suspension-cause-composition, cached-authorization-revocation,
accountability-record, receipt-decision-relation, action-result-
binding, read-fidelity-receipt, merkle-root-parity, instruction-
provenance, approval-single-use, runtime-authority-denial-continuity,
capability-binding-drift, arap-binding, cross-stack. Implemented
requirements: none. Related implementation surfaces: agent-passport-
system 7.2.0 (npm) and agent-passport-system 4.2.0 (PyPI) for the
authority issuer, delegation verifier and receipt verifier classes.
No released package for the enforcement boundary, the profile
implementation or the protocol adapter classes.
13.2. Requirement Identifiers
This subsection is informative. It describes the identifier scheme
this document uses, so that a claim can cite a requirement without
quoting it.
A requirement identifier has the form APS-<AREA>-<SEMANTIC-SLUG>.
The area is one of twelve fixed values: ID, PRIN, AUTH, LC, POL, ENF,
REC, EVID, PROF, ADAPT, GOV and CONF. The slug names the proposition
the requirement states, in uppercase words joined by hyphens. An
identifier names what a requirement says rather than where it sits,
so it never changes because a section moves, and it is never reused.
Renumbering this document moves no identifier, and an identifier
retired with its requirement stays retired.
Pidlisnyi Expires 1 April 2027 [Page 165]
Internet-Draft APS September 2026
Five identifiers from Appendix D show the shape: APS-PRIN-SILENCE-
NOT-CONSENT, APS-AUTH-CHAIN-NO-UNION, APS-LC-NO-RESURRECTION, APS-
ENF-COMPLETE-AT-ADMISSION and APS-EVID-EFFECT-NOT-FROM-RESULT. Each
reads as a proposition, which is what makes it citable without the
surrounding text.
Each identifier belongs to a conformance class through its area,
under the map in Section 13.1, and a claim cites an identifier in the
class it applies to.
Appendix D is the sole authority for which requirements an exact
vector exercises. It records one of two coverage states per
requirement. Exercised means a named vector plus a runner assertion
that fails when the requirement is violated. Specified, not
exercised means no such vector exists, whatever related fixture
material does exist. A requirement whose violation no input produces
is specified and not exercised even where a validator carries the
check, because a check no input reaches is not coverage.
The conformance suite's own inventory identifiers for draft-
pidlisnyi-aps-03 appear in this document in Appendix D.2 and nowhere
else. They are section-derived and bound to that revision, and they
are reproduced there as a legacy mapping rather than as a scheme a
claim against this revision uses.
What this subsection does not establish. It does not establish that
the identifiers cover every obligation of this document, since an
obligation stated across two sentences, or stated in the closed core
with no restating subsection, carries no identifier. It does not
establish that a fully exercised matrix would mean an implementation
is correct.
This subsection is informative and carries no requirement identifier.
13.3. Core and Candidate
Every normative subsection of this document outside the closed core
carries a status of Core or Candidate.
Two places are outside that scheme. The BCP 14 sentences carried
from -03 in Section 15 and Section 16 are closed-core carryover.
They keep the force they had in -03, they carry no status block and
no requirement identifier, and Appendix D does not list them, because
that appendix records what this revision states outside the closed
core.
Pidlisnyi Expires 1 April 2027 [Page 166]
Internet-Draft APS September 2026
Core means the requirement is mandatory for an implementation
claiming the conformance class to which the requirement applies,
under the area-to-class map in Section 13.1. Candidate means the
requirement belongs to an opt-in feature. A Candidate requirement is
normative for an implementation that claims that feature and is not a
requirement of APS Core conformance. Candidate is not weaker
normative language and not a lower grade of Core, and it is not a
promise that the requirement will become Core.
A claim therefore names the classes it claims and the Candidate
features it claims, in the form "APS Core in the named classes, plus
named features", and Section 13.4 states what else a claim carries.
Lifecycle Core is an informative grouping name and not a claimable
base. It names the propositions in Section 8 that restate a
requirement of the closed core, carried by six requirement
identifiers drawn from six of the twelve continuity rules. L1 is in
it whole. One identifier each comes from L3, for irreversibility,
from L5, for one chain per action with no union, from L6, for the
recheck at the moment of consumption, from L7, for an unknown
revocation state not being active, and from L9, for historical key
selection with its issuer-claim timestamp and indeterminate signing
instant. Section 8 lists the six with the core sections they
restate. Everything else in that section, including the rest of L3,
L5, L6, L7 and L9, is one or more Candidate features.
The Candidate features an implementation can claim in this revision
are: the revocation record format of Section 4.5.2, the evidence
model of Section 2.3 and Section 2.4, the profile model of Section 6,
the lifecycle continuity rules outside Lifecycle Core together with
the material in L3, L5, L6, L7 and L9 outside their Core
propositions, each lifecycle mechanism of Section 8.3 named as its
own feature, the decision-to-effect model of Section 9, the adapter
contracts of Section 11.4, and the per-vector result vocabulary of
Section 13.5. A claim that names no feature is a claim of APS Core
alone.
The claim rules of Section 13.1 and Section 13.4 are not a Candidate
feature. They bind every claim made under this document, whatever
classes and features the claim names, because they are the form in
which a claim is legible rather than a behavior an implementation
opts into. They are document requirements of the same kind as
Section 6.1 states for a profile, so no runtime vector reaches them
and Appendix D marks all three specified and not exercised.
The corpus carries its own label with a similar name and a narrower
meaning. A family labelled candidate_against_proposed states that a
runnable case exists against proposed text at one commit of one
repository. That label is a statement about the family, and this
Pidlisnyi Expires 1 April 2027 [Page 167]
Internet-Draft APS September 2026
document's Candidate is a statement about a requirement. The two are
recorded separately and neither implies the other. The corpus itself
records that the label spelling is not yet uniform across families
and that two families carry the shorter spelling on their per-vector
records while stating the longer one at the family level.
What this subsection does not establish. It does not establish that
a Candidate requirement is correct, that the boundary between Core
and Candidate is drawn the same way by any other document, or that a
family passing means the rule it tests is the right rule. A pass
establishes that a boundary implementing the stated reading reaches a
stated verdict on stated bytes.
This subsection is informative and carries no requirement identifier.
13.4. Conformance Claims
A claim is APS Core in the classes it names, plus the Candidate
features it names. It carries no other base.
The requirements in this subsection bind a claim document. Like the
profile requirements of Section 6.1, they are not runtime checks and
no vector exercises them.
A conformance claim MUST state all of the following.
Implementation. The name of what was tested and enough of a
reference to fetch exactly that, which means a repository and
commit, or a package and version.
Classes. The classes of Section 13.1 claimed, and no others.
Requirements. The requirement identifiers claimed, each under the
semantic scheme of Section 13.2. An identifier does not move
between revisions, so a claim names the revision it was tested
against for the text of each requirement rather than to resolve
the identifier.
Corpus. The tag or commit of the corpus run against.
Per-vector results. One result per vector under Section 13.5, not a
summary and not a percentage.
Commands and output. The commands run and their output, uncut.
Environment. Language, runtime version and operating system.
Who ran it. The party that ran it, and whether that party authored
Pidlisnyi Expires 1 April 2027 [Page 168]
Internet-Draft APS September 2026
the vectors, the claim inputs, or the implementation whose output
supplies the recomputation. A claim MUST NOT be presented as
independent where any of those three is the claiming party's own
work.
Profiles. Every profile the implementation holds, by identifier and
version.
A claim MUST NOT be stated as a verdict issued by this document, by
the corpus, or by any party other than the claimant. A claim is a
record of what one party observed on stated inputs. A later claim by
another party is appended as a new record and does not alter or
replace an earlier one, and a later finding does not rewrite what an
earlier record states.
What this subsection does not establish. It does not establish that
a complete claim is correct, that a claim covering every requirement
means the implementation is safe, or that any registry of claims
exists. It does not define a machine-readable claim format.
Requirements. APS-CONF-CLAIM-CONTENT, a claim states every item in
the list above. APS-CONF-CLAIM-NOT-VERDICT, a claim is not stated as
a verdict issued by this document, by the corpus, or by any party
other than the claimant, and a later claim is appended as a new
record rather than replacing an earlier one. Both are specified, not
exercised, and no fixture exists for a requirement on a claim
document.
Status: Core, document requirement, specified, not exercised. APS-
CONF-CLAIM-CONTENT and APS-CONF-CLAIM-NOT-VERDICT bind a claim
document and not a runtime verifier, so no runtime vector reaches
them. A static claim fixture is required before either is recorded
as exercised, and none exists. Related fixture families: none.
Implemented requirements: none. Related implementation surfaces: no
released package.
13.5. Per-Vector Results
An implementation reports one of exactly three results per vector.
pass The implementation reached the vector's declared outcome. For
a negative vector this means the implementation rejected the input
for the reason the vector declares, not merely that it rejected
the input.
fail The implementation reached a different outcome, or reached the
declared outcome for a different reason.
Pidlisnyi Expires 1 April 2027 [Page 169]
Internet-Draft APS September 2026
not_supported The implementation has no surface on which the
vector's question can be asked. The concept the vector exercises
is absent from the implementation, so there is nothing to run and
nothing to reject.
An implementation MUST NOT report not_supported as pass, and MUST NOT
report a vector it did not run at all. not_supported and fail are
different findings. A fail says the implementation answered and was
wrong. A not_supported says it could not be asked.
A count of not_supported results MUST NOT be presented as a coverage
score, a completeness percentage, or a comparison between
implementations. The reason is arithmetic rather than editorial.
The unit a family records differs by family, because the question
differs. Some families record one row per named claim, some one row
per verification layer, some a count of reachable exports, and some
commit no per-vector record at all and print it on demand. Rows from
different units do not add, and a total over them is an artifact of
how each family chose to write its record. A family's own record is
authoritative for that family and for nothing else.
A not_supported result is also not a defect report about the package
it names. It states what a fixture could and could not get from a
published package at a pinned version, which is a statement about
that package's surface at that version.
What this subsection does not establish. It does not establish that
the three results are exhaustive for every verification model, that
the boundary between fail and not_supported is unambiguous in every
case, or that two implementations reporting the same tallies are
equally correct. It does not establish any suite-wide number.
Requirements. APS-CONF-THREE-RESULTS, an implementation reports one
of exactly three results per vector, reports no not_supported as
pass, and reports no vector it did not run. APS-CONF-NOT-SUPPORTED-
NOT-SCORE, a count of not_supported results is not presented as a
coverage score, a completeness percentage, or a comparison between
implementations. Both are specified, not exercised.
Pidlisnyi Expires 1 April 2027 [Page 170]
Internet-Draft APS September 2026
Status: Candidate feature. Normative for an implementation claiming
this feature, not a requirement of APS Core conformance. Related
fixture families: activation-not-established, lifecycle-credential-
events, lifecycle-multiple-principals-and-conflict, lifecycle-
outside-the-chain-standing, lifecycle-legal-regulatory-events,
lifecycle-identifier-reuse-and-rename, lifecycle-principal-events.
Implemented requirements: none. Related implementation surfaces:
agent-passport-system 7.2.0 (npm) and agent-passport-system 4.2.0
(PyPI) are the packages whose surface those families probe. No
released package emits a per-vector result record.
13.6. What a Passing Run Does Not Establish
This subsection is informative.
A passing run does not establish a rule. It establishes that a
boundary implementing the reading under test reaches a stated verdict
on stated bytes, and that the named defective boundaries diverge on
exactly their declared sets.
It does not establish that the reading under test is the correct one.
For a Candidate requirement the reading is this document's, and a
family that runs it does not confirm it.
It does not establish that the reference runners are independent
implementations. Both were written for the corpus by this document's
author.
It does not establish liability or any accountability outcome. Where
a family touches an accountability record, that family states its own
limit.
It does not establish that any legal doctrine applies to AI agents.
The corpus uses scenarios drawn from how institutions handle
authority as a source of cases, and each family that does so says so.
A case is a source of a test, never a source of a rule.
It does not establish adoption, endorsement or production use by any
party whose artifacts the corpus carries. Admission of an external
family means the vectors were deterministic, in scope and correctly
labelled.
This subsection is informative and carries no requirement identifier.
Pidlisnyi Expires 1 April 2027 [Page 171]
Internet-Draft APS September 2026
14. 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. Documents are cited by their series name and revision,
which is how documents sharing a title are distinguished. A document
that had expired at the time of writing is marked as expired where it
is cited, and is retained as prior art rather than dropped.
PEDIGREE [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 Section 4.6; PEDIGREE applies it
to scope, lifetime, and depth, while APS applies it across the seven
constraint dimensions of Section 4.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. [OAUTH-CHAIN-DEL] 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 [OAUTH-AUTHZ-EV] 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: [OAUTH-CHAIN-DEL] makes
descendants of a revoked root invalid by rule, with Resource Servers
Pidlisnyi Expires 1 April 2027 [Page 172]
Internet-Draft APS September 2026
required to confirm the root authorization remains valid at the time
of use, while APS keeps the authority result for a chain separate
from the state of the evidence recording a revocation's processing,
so that cascade evidence, where produced, records processing without
being what makes a descendant chain invalid (Section 4.5.1).
The same author set frames these as parts of one flow. An
integration framework [OAUTH-INTEGRATION] 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 [OAUTH-REGO] 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 specify one form of such a record.
A further cluster of individual proposals works the same problem from
the actor claim of [RFC8693], which expresses that delegation has
occurred and identifies the acting party to whom authority has been
delegated. [OAUTH-ACTOR-CHAIN] defines six actor-chain profiles for
Token Exchange on the stated ground that the claim permits nested
prior actors but defines no interoperable rules for preserving,
extending, disclosing and validating a delegation path across
successive exchanges, and its verified profiles add actor-signed step
proofs with cumulative commitment state. [OAUTH-ACTOR-PROFILE]
profiles the same claim differently, extending it with a sub_profile
member for entity-type classification across JWT assertion grants,
JWT access tokens and transaction tokens, and states that the
policies deciding whether a given actor may act for a subject stay
deployment-specific. [OAUTH-REQ-DEL-CHAIN] moves the question
earlier, carrying a signed authorization request delegation chain as
an authorization_details object under Rich Authorization Requests
[RFC9396] so that an upstream Authorization Server can apply policy
to the visible delegation path before it issues a token. None of the
three is a working group document, and they have not converged on one
representation. APS is not a token profile: it specifies standalone
signed records evaluated at an enforcement point, and Section 11.3
defines the single OAuth grant binding this document carries.
Closest of that cluster to Section 4.5.1 is [OAUTH-REVOC-CLOSURE],
which starts from the observation that invalidating a credential does
not establish that every path from the revoked authority to a
consequential effect has been closed. It models authority as a
directed graph and holds a revocation cut set valid only if every
declared path from the revoked root to a consequential sink
intersects it, and it requires that where an implementation cannot
Pidlisnyi Expires 1 April 2027 [Page 173]
Internet-Draft APS September 2026
establish that the revoked authority can no longer create authority-
bearing edges bypassing that cut set, closure is reported as unknown,
partial or failed rather than closed. It defines no encoding for the
resulting closure receipt. This document approaches the same
question from the record side. Both bound what a record may assert
by the coverage its emitter declares. That draft requires a closure
claim to identify the enforcement scope it applies to and not to
imply closure of unknown or out-of-scope systems, and Section 4.5.1
requires a party emitting a cascade-completion record to be able to
state the basis on which the processed set was complete.
A best-practices framework [AIMS] 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 rather than defining new protocols it describes how
existing and widely deployed standards can be applied or extended,
and identifies gaps to guide future standardization. Its policy
model and document format are declared out of scope and are not
recommended there as a target for standardization. The framework was
adopted by the WIMSE working group after this document's previous
revision, where it is titled AI Identity Management System and
defines the term Agent Identity Management System (AIMS) as a
conceptual model describing the set of functions required to
establish, maintain and evaluate the identity and permissions of an
agent workload. That document states that AIMS does not refer to a
single product, protocol or deployment architecture. It is the one
agent-specific document in that working group at the time of writing.
APS specifies mechanisms in part of the space that framework surveys:
the transfer-time narrowing rule across the seven constraint
dimensions of Section 4.1, and the signed admission and outcome
records evaluated at an enforcement point.
Two transparency specifications were published in June 2026 and were
not cited in the previous revision. [RFC9943] defines an
architecture for single-issuer signed statement transparency, in
which registration is the process of submitting a signed statement to
a Transparency Service, applying that service's registration policy,
adding it to a verifiable data structure and producing a receipt, and
a Transparency Service is the entity that maintains and extends that
structure and endorses its state. [RFC9942] defines the receipt
encoding, where a receipt proves properties of a verifiable data
structure to a verifier. Three individual drafts profile that
architecture for agent actions [SCITT-CAPSULE] [SCITT-AGENT-RECEIPT]
[SCITT-ACTION-CAPSULE]. One of them, [SCITT-AGENT-RECEIPT], states
the property at stake. Registration obtains a Transparency Service's
signed proof that the statement was registered in its log, which that
draft calls a property a self-signed chain cannot provide alone.
Pidlisnyi Expires 1 April 2027 [Page 174]
Internet-Draft APS September 2026
The ReceiptV1 envelope of Section 7.1 stays a standalone signed
record and is not a profile of that architecture in this revision.
The reason is the dependency rather than the encoding. A
registration receipt is a statement about a log that a Transparency
Service maintains, so what a relying party gets from it is bounded by
that service and by the monitoring the relying party performs. The
records of Section 7 are evaluated at an enforcement point at the
time of the action, and this document states, per record class, what
each record proves and what it does not, without requiring a
Transparency Service to be reachable at that moment. The two are
composable rather than alternative. A ReceiptV1 record is a
candidate payload for a signed statement, and registering one would
add transparency properties that Section 7 does not claim.
Specifying that carriage is future work (Section 20).
The Delegation Receipt Protocol [DRP] 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 [AGENT-ID-FW] 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 Section 4.1 and signs the
admission decision and the outcome as separate records at each
action.
[ACTION-REF] 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
Pidlisnyi Expires 1 April 2027 [Page 175]
Internet-Draft APS September 2026
Section 5.2 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 7) 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 [AGENT-ID-ARCH] 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. That document also
specifies narrowing-only delegation, stated at the architecture level
rather than as a token or record format, and its human identity root
corresponds to the principal that APS keeps visible through the
principal binding of Section 3.3. The record formats, signature
scheme, and enforcement-point evaluation that the architecture leaves
open are what this document specifies.
Pidlisnyi Expires 1 April 2027 [Page 176]
Internet-Draft APS September 2026
Three independent drafts each titled Agent Identity Protocol specify
different layers under the same name, and are distinguished here by
series name. [AIP-DELEGATION] 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
revocation evidence. [AIP-ENFORCEMENT], which had expired at the
time of writing and is retained here as prior art, 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. The third [AIP-IBCT]
binds identity, authorization, scope constraints and provenance into
invocation-bound capability tokens, in a compact JWT mode and a
chained mode with append-only blocks and Datalog policy evaluation,
under a rule that at each delegation step scope can only narrow or
stay equal and never widen. That rule also specifies narrowing-only
delegation, reached over a token format rather than over standalone
records.
A parallel set of individual Internet-Drafts develops the surrounding
problem space as requirements and evidence-layer documents. A
problem statement [WIMSE-XORG] enumerates ten requirements for cross-
organizational agent delegation, among them recursive attenuation,
bounded-staleness revocation, and tamper-evident composable audit,
and it specifies no solution. Its tenth requirement, added after
this document's previous revision, is that classes of actions be
designatable as requiring, at execution time, evidence of an
authorization decision made by an accountable human approver distinct
from the executing agent, bound to the specific action and relied
upon at most once. The overlap is partial. Section 5.3 and
Section 7.6 of this document specify a single-use approval bound to
an action_ref and the rules under which it is consumed. This
document specifies no requirement that the approver be a human
distinct from the executing agent, no designation of such a
requirement carried in delegated authority, and no preservation of
such a designation across narrowing. A companion set specifies
pieces of an evidence layer above individual record formats. One
Pidlisnyi Expires 1 April 2027 [Page 177]
Internet-Draft APS September 2026
defines a transport-agnostic composition object and a fail-closed
evaluation algorithm that returns satisfied or unsatisfied together
with a replayable evaluation record [EP-AEC]. A second introduces
and rotates an organization's evidence-issuing keys through a signed,
hash-chained sequence, and records the authority a subject held at a
registry snapshot, including role, action scope, material limits,
policy binding, validity and revocation status [EP-AUTHINTRO]. A
third binds named-human authorization evidence into an action record
in a host-agnostic way [EP-HUMANAUTH]. A fourth binds per-action
authorization and memory provenance into an action capsule
[SCITT-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 Section 4.1 and
Section 4.2, revocation evidence with Section 4.5.1, and tamper-
evident audit with the signed records of Section 7. 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.
Two lines of work outside the IETF bear on the boundary the MCP
binding of Section 11.1 sits on. Inside MCP's specification-
enhancement process, one proposal defines a signed tool-call
attestation envelope, on the stated ground that MCP has no standard
mechanism to prove cryptographically which agent called which tool,
with what arguments and for what purpose [MCP-SEP-2787]. A second
carries client-asserted invocation audit context and states that its
fields are explicitly not authorization evidence [MCP-SEP-2817]. A
third defines a canonical byte form and an append-only hash chain for
audit records, with admission, runtime-security and caller-governance
context attached under one digest [MCP-SEP-3004]. A fourth, a
server-side signed execution record, was withdrawn by its author, who
continued the work as an Internet-Draft [MCP-SEP-2828]
[VAARA-RECEIPT]. The first and third were closed in September 2026
under a maintainer decision that new proposals be developed with a
working group, which is a disposition of process and not of content.
The resulting split between an attestation of the request, an audit
context, and a separately chained record tracks the three-record
policy chain of Section 5 and Section 7, and the server-authoritative
record of a decision and its outcome, which left that process when
the fourth proposal was withdrawn, is what Section 7.3.2 and
Section 7.3.3 specify.
The Authorization API [AUTHZEN], final in January 2026, standardizes
the exchange by which Policy Decision Points and Policy Enforcement
Points communicate authorization requests and decisions without
Pidlisnyi Expires 1 April 2027 [Page 178]
Internet-Draft APS September 2026
requiring knowledge of each other's inner workings. That API and
this document address different halves of one boundary. The API
specifies how a decision is asked for and returned at the time of the
request, while Section 7.3.2 specifies a signed record of the
decision that a party other than the two endpoints can evaluate
afterwards, and Section 7.4 binds the inputs the decision was made
against into that record.
In the Coalition for Secure AI's agentic-systems workstream, three
open proposals touch this document. One specifies a signed, pre-
execution declaration layer for agentic systems [COSAI-149]. A
second asks what a verifier may conclude when evidence is absent,
stating that a verifier finding no evidence for a property has three
possible answers while most systems implement only two [COSAI-189].
A third defines decommissioning as a lifecycle phase that ends an
agent's authority to act, under which the same agent identity cannot
resume once the phase is complete [COSAI-205]. The second restates,
for a general evidence layer, the distinction Section 4.3,
Section 7.5 and Section 7.6 already draw between a negative result
and a result that could not be established, and this document keeps
its own outcome vocabulary rather than renaming it against an
unadopted proposal. The third is adjacent to the irreversibility of
revocation in Section 4.5 and covers a broader lifecycle event than
this document specifies. All three were open and unadopted at the
time of writing.
Two artifacts maintained by this document's author are named here as
follow-on work rather than as independent corroboration. An
authority lifecycle document [APS-LIFECYCLE] records invariants about
what happens to an agent's authority when the people, keys, approvals
and roles around it change, each carrying a status label that
separates what this document specifies, what a runnable case
exercises, what an implementation ships, and what is only proposed.
A public conformance suite [APS-CONFORMANCE] holds the vectors those
labels point at. Neither is normative here. The questions that
document lists as open, among them completeness of a teardown,
release from multiple concurrent suspensions, and authority state
restored from a backup, are outside the scope of this revision.
14.1. Capability Map
The two tables below set every document cited above against fourteen
dimensions. They are one table, split at dimension h so that each
half fits the page width, and every row appears in both. A cell
records what the cited document states about that dimension. It does
not record agreement with this document, and it does not rank the
documents.
Pidlisnyi Expires 1 April 2027 [Page 179]
Internet-Draft APS September 2026
Cell values. S, specifies, means the document states a rule for that
dimension in its own normative text. D, describes, means the
document states a model or a survey finding for that dimension
without stating a rule. R, requires, means the document states the
dimension as a requirement on some other mechanism. O, out of scope,
means the document states that the dimension is outside what it
defines. A blank cell means this document records no finding for
that dimension from the cited text. A blank is not a finding that
the dimension is absent from that document.
Column keys.
a: identity
b: represented principal
c: initial grant
d: recursive attenuation
e: resource and purpose bounds
f: lifecycle and status
g: revocation freshness
h: exact-action binding
i: decision record
j: atomic admission
k: effect evidence
l: transparency
m: adapters
n: executable conformance
+========================+===+===+===+===+===+===+===+
| document | a | b | c | d | e | f | g |
+========================+===+===+===+===+===+===+===+
| [PEDIGREE] | S | | | S | | | S |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-CHAIN-DEL] | | | | S | | | S |
+------------------------+---+---+---+---+---+---+---+
| [RFC8693] | S | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [RFC9396] | | | | | S | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-AUTHZ-EV] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-INTEGRATION] | D | D | | D | | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-REGO] | | | | | S | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-ACTOR-CHAIN] | | | | S | | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-ACTOR-PROFILE] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
Pidlisnyi Expires 1 April 2027 [Page 180]
Internet-Draft APS September 2026
| [OAUTH-REQ-DEL-CHAIN] | | | | S | | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-REVOC-CLOSURE] | | | | | | S | S |
+------------------------+---+---+---+---+---+---+---+
| [AIMS] | D | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [RFC9943] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [RFC9942] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [SCITT-CAPSULE] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [SCITT-AGENT-RECEIPT] | | S | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [SCITT-ACTION-CAPSULE] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [DRP] | | S | S | S | S | | S |
+------------------------+---+---+---+---+---+---+---+
| [AGENT-ID-FW] | S | | S | | S | | |
+------------------------+---+---+---+---+---+---+---+
| [ACTION-REF] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [AGENT-ID-ARCH] | | D | | D | | | D |
+------------------------+---+---+---+---+---+---+---+
| [AIP-DELEGATION] | S | | | S | S | | |
+------------------------+---+---+---+---+---+---+---+
| [AIP-ENFORCEMENT] | S | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [AIP-IBCT] | S | | | S | S | | S |
+------------------------+---+---+---+---+---+---+---+
| [WIMSE-XORG] | R | R | | R | | | R |
+------------------------+---+---+---+---+---+---+---+
| [EP-AEC] | | | | | O | | |
+------------------------+---+---+---+---+---+---+---+
| [EP-AUTHINTRO] | S | | | | S | S | |
+------------------------+---+---+---+---+---+---+---+
| [EP-HUMANAUTH] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [MCP-SEP-2787] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [MCP-SEP-2817] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [MCP-SEP-2828] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [MCP-SEP-3004] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [VAARA-RECEIPT] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
Pidlisnyi Expires 1 April 2027 [Page 181]
Internet-Draft APS September 2026
| [AUTHZEN] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [COSAI-149] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [COSAI-189] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [COSAI-205] | | | | | | D | |
+------------------------+---+---+---+---+---+---+---+
| [APS-LIFECYCLE] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [APS-CONFORMANCE] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
Table 13: Documents cited above against dimensions
a to g
+========================+===+===+===+===+===+===+===+
| document | h | i | j | k | l | m | n |
+========================+===+===+===+===+===+===+===+
| [PEDIGREE] | | | | S | | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-CHAIN-DEL] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [RFC8693] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [RFC9396] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-AUTHZ-EV] | | S | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-INTEGRATION] | | D | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-REGO] | | S | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-ACTOR-CHAIN] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-ACTOR-PROFILE] | | O | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-REQ-DEL-CHAIN] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [OAUTH-REVOC-CLOSURE] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [AIMS] | | O | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [RFC9943] | | | | | S | | |
+------------------------+---+---+---+---+---+---+---+
| [RFC9942] | | | | | S | | |
+------------------------+---+---+---+---+---+---+---+
| [SCITT-CAPSULE] | | S | | | | | |
Pidlisnyi Expires 1 April 2027 [Page 182]
Internet-Draft APS September 2026
+------------------------+---+---+---+---+---+---+---+
| [SCITT-AGENT-RECEIPT] | | S | | O | S | | |
+------------------------+---+---+---+---+---+---+---+
| [SCITT-ACTION-CAPSULE] | | S | | S | S | | S |
+------------------------+---+---+---+---+---+---+---+
| [DRP] | | | | | S | | |
+------------------------+---+---+---+---+---+---+---+
| [AGENT-ID-FW] | | | S | | | | |
+------------------------+---+---+---+---+---+---+---+
| [ACTION-REF] | S | S | | S | | | S |
+------------------------+---+---+---+---+---+---+---+
| [AGENT-ID-ARCH] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [AIP-DELEGATION] | | | | | | | S |
+------------------------+---+---+---+---+---+---+---+
| [AIP-ENFORCEMENT] | S | S | | | S | | |
+------------------------+---+---+---+---+---+---+---+
| [AIP-IBCT] | S | | | | | S | |
+------------------------+---+---+---+---+---+---+---+
| [WIMSE-XORG] | R | R | R | | R | R | |
+------------------------+---+---+---+---+---+---+---+
| [EP-AEC] | S | S | O | O | | | |
+------------------------+---+---+---+---+---+---+---+
| [EP-AUTHINTRO] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [EP-HUMANAUTH] | S | S | O | | | | |
+------------------------+---+---+---+---+---+---+---+
| [MCP-SEP-2787] | S | S | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [MCP-SEP-2817] | | O | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [MCP-SEP-2828] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [MCP-SEP-3004] | | S | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [VAARA-RECEIPT] | | S | | S | | | S |
+------------------------+---+---+---+---+---+---+---+
| [AUTHZEN] | | S | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [COSAI-149] | | D | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [COSAI-189] | | D | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [COSAI-205] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [APS-LIFECYCLE] | | | | | | | |
+------------------------+---+---+---+---+---+---+---+
| [APS-CONFORMANCE] | | | | | | | |
Pidlisnyi Expires 1 April 2027 [Page 183]
Internet-Draft APS September 2026
+------------------------+---+---+---+---+---+---+---+
Table 14: Documents cited above against dimensions
h to n
Two rows carry no cells. [APS-LIFECYCLE] and [APS-CONFORMANCE] are
maintained by this document's author, the prose above states what
they are, and this table records external documents.
[MCP-SEP-2828] carries no cells. Its author withdrew it and
continued the work as [VAARA-RECEIPT], which has its own row.
What this table does not establish. It does not establish that a
document without a cell in a dimension states no rule for it, because
the reading behind each row was bounded to the text that row cites.
It does not establish that two documents marked S in one column state
the same rule, and the prose above is where the differences are
stated. It does not establish that any document in it has been
implemented, has been adopted, or has run a vector from any suite.
It is not evidence about which document stated a dimension earlier.
15. Security Considerations
Protocol properties that depend on mediation hold only when all
privileged effects pass through the enforcement gateway described in
Section 12. 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 what this document specifies.
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 3.1), defines historical and external signer resolution
(Section 3.4 and Section 3.5), defines separately signed principal
bindings and claim levels (Section 3.3), and keeps attestation
provenance separate from verification status (Section 3.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 20).
Pidlisnyi Expires 1 April 2027 [Page 184]
Internet-Draft APS September 2026
This epistemic boundary extends to signed receipts. The gap between
what a cryptographic governance protocol can prove and what it cannot
is analyzed in [APS-EVIDENCE-GAP]. 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 10); 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 5.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 5.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 Section 5.1 and Section 5.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 7) or from an
independently held copy, not from the reference itself.
An imported external chain root (Section 11.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
Pidlisnyi Expires 1 April 2027 [Page 185]
Internet-Draft APS September 2026
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.
An activation condition of Section 8.3.1 is enforced only at a
boundary that claims that feature. A delegation gated by a
recorded_event condition verifies as valid at a boundary that does
not claim it, because the condition is a separate record the chain
does not carry and chain verification never reads. An issuer that
needs a gate applied by every verifier has only the time facet of
Section 4.1, whose not_before every chain verifier applies.
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.
15.1. Corpus Failure Classes and the Assumptions They Defeat
The considerations above are attacker classes. The classes below are
failure shapes drawn from the case corpus this document is written
against. Each one is stated with the deployment assumption it
defeats and with what in the conformance suite exhibits it. Naming a
fixture family means the suite carries executable cases of that
shape. It does not mean the class is closed, and several classes
have no family at all, which is recorded where it is true.
Principal substitution
An authority path depends on an identifier no party in the
delegation graph controls, such as a mail domain a recovery flow
delivers to or a namespace a reference resolves. The string is
unchanged and the party behind it is not. Assumption defeated:
the identifier an authority path depends on is still held by the
party it was issued to. Exhibited by: lifecycle-identifier-reuse-
and-rename, and by the case in action-result-binding where one
record names two different acting agents.
Pidlisnyi Expires 1 April 2027 [Page 186]
Internet-Draft APS September 2026
Ambient bypass
A credential reaches the target by a path that never passes the
enforcement boundary. Every record the boundary holds is valid
and none of them is about the effect that occurred. Assumption
defeated: all privileged effects pass the boundary. This is the
mediation assumption of Section 9.3 and it is load bearing.
Exhibited by: the interop record cosai-ws4-149-decision-to-effect,
whose bypass cases settle negatively on an observed alternate path
and stay unsettled without a coverage premise. No fixture family
establishes coverage over the paths to an effect, and the
boundary-case corpus keeps the incident shapes for this class
outside the lifecycle model as security-control cases.
Stale approval after an epoch change
A restored snapshot or a lagging replica presents authority state
from before a reauthorization, succession or re-root, and an
approval evaluated under the earlier state is admitted under the
later one. Assumption defeated: no party can present pre-change
state as current, and a write-fencing holder from the earlier
epoch cannot publish. Exhibited by: authority-epoch-rollback.
Approval burned before admission
An approval is consumed once and then presented again, or
presented after its window closed. Assumption defeated:
consumption is atomic at the boundary and the expiry is enforced
at consumption rather than only at issuance. An expiry that is
carried and not enforced is equivalent to no expiry. Exhibited
by: approval-single-use, including the already-consumed, expired
and deny-not-consumable cases.
Replay after admission
Two presentations of one approval race at the boundary and both
are admitted, or one approval admits a second call whose action
reference differs from the one it approved. Assumption defeated:
the boundary serializes consumption and compares the action
reference at the moment of consumption. Exhibited by: approval-
single-use, whose race pair admits the first presentation and
refuses the second, and whose action-binding case refuses a call
the approval does not name.
Stale revocation
A revoked grant continues to admit calls because a session, a
warmed cache or a second worker never re-resolved status, or
because a resolver answer the implementation did not recognise was
read as active. Assumption defeated: a revocation answer reaches
the boundary before the next authorization boundary, and a cache
does not outlive its declared freshness bound. Exhibited by:
cached-authorization-revocation, revocation-resolution-forward-
Pidlisnyi Expires 1 April 2027 [Page 187]
Internet-Draft APS September 2026
compat, ancestor-revocation-chain. The corpus also records a
cache whose configured lifetime drifts past its declared freshness
policy as a configuration defect rather than an authority finding.
Partial teardown
A revocation cascade processes the descendants it knew about. A
descendant issued locally, or signed after the revocation under a
chain that still verifies, was never in that set. Assumption
defeated: the set a teardown processed was every authority
descendant at the relevant boundary. Signed lineage establishes
structure and does not establish that a descendant was accepted
authority when the revocation took effect. Exhibited by:
ancestor-revocation-chain and the history-reconciliation cases of
lifecycle-infrastructure-failure. No family establishes
completeness, and completeness is an open question, not a settled
rule.
Successor and rollback resurrection
A successor to an office or a sponsor is treated as holding the
predecessor's whole delegation tree, or a restore brings back
authority that had ended. Assumption defeated: a successor does
not inherit the tree, and continued operation after a handover
runs on the replacement chain rather than on the old one.
Exhibited by: sponsor-handover, lifecycle-root-authority-
succession, authority-epoch-rollback.
Concurrent suspension release
Three causes from three sources pause one grant. One is released
and the grant is treated as usable. Assumption defeated: release
is per cause, and a grant stays paused while any cause is live.
Exhibited by: suspension-cause-composition.
Adapter semantic loss
An adapter carries an authority artifact into another stack and
the dimensions that stack has no member for are dropped rather
than reported as unsupported. The result is silently wider than
what was granted. Assumption defeated: an adapter that cannot
carry a dimension says so. Exhibited by: the cross-stack
families, which record what each external format carries and what
it does not.
Trust-root substitution
The root a verifier begins at is not the one the deployment
intended. The imported-root case is covered above: APS signature
verification begins at the first APS-signed hop and the standing
of everything above it rests on the importing party. Assumption
defeated: the verifier and the deployment agree on where
verification begins. The corpus also carries a shape that sits
Pidlisnyi Expires 1 April 2027 [Page 188]
Internet-Draft APS September 2026
upstream of any chain check, where the constants the verification
arithmetic itself relies on were substituted in a build. No
fixture family exercises that shape, and the corpus records it as
a build-integrity case outside the authority model.
Accidental chain union
One agent holds more than one independently rooted chain and a
verifier reads the union of their scopes or budgets. Neither
chain granted what the union grants. Assumption defeated: each
action is decided against one root-to-leaf chain. Exhibited by:
chain-selection-no-union, single-chain-selection.
Indeterminate post-dispatch retry
An action-result record carries status unknown and the deployment
retries. Where the effect cannot be undone, the retry risks a
second effect while the record of the first says nothing about
whether it occurred. Assumption defeated: a retry after an
unknown result cannot produce a second effect that no compensating
action reaches. Exhibited by: the unknown-status surface of
action-result-binding, the no-retry cases of runtime-authority-
denial-continuity, and the effect cases of the interop record
cosai-ws4-149-decision-to-effect. This document states no
normative retry rule for the irreversible case, as Section 9.7
records, and the corpus keeps deduplication mechanisms such as
idempotency keys and at-least-once delivery as execution behaviour
rather than as authority findings.
Two of these classes have no fixture family at all, ambient bypass on
the coverage side and the build-integrity half of trust-root
substitution. None of the thirteen is closed. A family exhibits a
shape and closes nothing, so a reader treating the list as a
checklist a deployment works through is reading it as something it is
not. None of the cases behind any class is a source of rules for AI
agents, and nothing here states that a legal doctrine applies to one.
16. 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 [RFC6973]. 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
Pidlisnyi Expires 1 April 2027 [Page 189]
Internet-Draft APS September 2026
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.
17. 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.
18. 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 (Section 4 and
Section 5).
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 resolves the claim level of a principal
binding and reports it as self_asserted, principal_attested, or
externally_verified_principal under Section 3.3. Whether the
principal that binding names is the principal the accepted
authority lineage represents is profile and trust-policy dependent
and may remain not established, which is the open question at
Section 19.2.10.
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.
Pidlisnyi Expires 1 April 2027 [Page 190]
Internet-Draft APS September 2026
The mechanisms in this document resolve the authority axis from the
selected chain, and resolve the claim level of the principal axis
from the binding material, where that material is available.
Associating that principal with the accepted authority lineage is
profile and trust-policy dependent and may remain not established
(Section 19.2.10). 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.
19. Limits and Open Questions
This section is informative and has two parts. The first states five
limits of what this document specifies. A limit is a property of the
protocol and not a question waiting on an answer. The second states
the open design questions, each with what is unresolved, why the
current evidence does not settle it, what this document requires
until it is settled, and whether it touches APS Core or a Candidate
feature.
Nothing in either part is a defect report about this revision. A
limit is a boundary a later revision does not move by adding a record
type. An open question is a place where this document states less
than an implementation already does, or less than a deployment needs.
19.1. Known Protocol Limits
This subsection is informative. The five limits below are properties
of what this document specifies. They are not questions awaiting an
answer, and no later revision closes them by adding a record type.
No external truth.
A signature establishes that an authorized signing key attested to
canonical bytes. It establishes nothing about the world the bytes
describe. A valid chain, a valid receipt and a resolved evidence
reference together establish what parties said and how their
records relate, and never that an external event occurred. This
is why Section 7.6 keeps external truth on its own axis and why
Section 9.4 refuses to report an effect from a result record.
Pidlisnyi Expires 1 April 2027 [Page 191]
Internet-Draft APS September 2026
The mediation assumption.
Everything here rests on the deployment routing privileged effects
through the enforcement boundary. That assumption is load bearing
and it is not self-checking. Where a target system accepts a
credential that never passes the boundary, the records defined
here describe the governed path and are silent about the rest.
Section 2.5 states it and Section 9.3 states what a verifier may
conclude without it.
Live state is not in a signed record.
A signature fixes static limits. Current revocation state, the
current cumulative spend total and whether an approval has been
consumed are enforcement-boundary state. A verifier without
access to that state reports the corresponding axis as not
established and can reach no further, however complete the records
it holds.
Unsupported profile semantics.
This document leaves constructions to profiles, and an
implementation that does not hold a profile a record names reports
unsupported. Unsupported is not a narrower reading and it is not
valid. Two implementations holding different profiles can both be
conforming and reach different results on the same bytes.
No proof of absence.
Nothing here establishes that a record does not exist, that a path
was not used, or that a set was complete. An empty result over an
interval inside a declared delivery lag is delivery lag rather
than absence. A verifier that reports absence from silence has
reported a finding nobody made.
What this subsection does not establish. It does not establish that
the five are the only limits of this document, and it does not
establish that a deployment holding all five in mind is safe.
19.2. Open Design Questions
This subsection is informative. It lists the questions this document
does not answer, so that the rest of the document is not read as a
claim about them. Each question states four things: what is
unresolved, why the current evidence does not settle it, what this
document requires until it is settled, and whether it touches APS
Core or a Candidate feature. A question that touches Core is one an
implementation cannot opt out of by declining a feature.
Nine of these come from the authority lifecycle document
[APS-LIFECYCLE]. Three are transitions in Section 2.6 that no
section of this revision establishes. Two were drafted as candidate
Pidlisnyi Expires 1 April 2027 [Page 192]
Internet-Draft APS September 2026
lifecycle extensions and are carried here instead, because the
strongest counterexample against each is unresolved and a candidate
with an unresolved counterexample is a question rather than an
extension. One is the distance between the lifecycle standing of
Section 8.1 and the issuer-only revocation of Section 4.5.
Each item names the cases in Appendix C that force it, where a case
does, and the fixture families whose vectors touch it. None of those
closes the question. A family's vectors are candidates against
proposed text rather than conformance results, and naming one is not
a conformance claim.
19.2.1. Teardown Completeness
A list of processed descendants does not establish that the list was
every authority descendant at the relevant boundary. Delegation can
be issued locally, so a descendant can exist that the teardown
process never saw, and a descendant can be signed after the
revocation with a valid parent chain. Signed lineage establishes
structure. It does not establish that the descendant was accepted
authority when the revocation took effect.
Three things a completeness claim needs are unsettled. What set a
boundary claims to have accepted at a given moment. What prevents
something from entering that set afterwards while still counting as
earlier authority. What public commitment can establish closure over
that set without exposing private state. This is why the revocation
evidence rules of this document require a party emitting a cascade-
completion record to be able to state the basis on which its set was
complete, and define no such basis. See also Section 8.2.12 and
Section 4.5.2.
*What is unresolved.* What basis makes a completeness claim over a
set of descendants checkable, and what prevents an addition to that
set afterwards that still counts as earlier authority.
*Why the current evidence does not settle it.* Every family named
above exercises what happens to one artifact or one chain. None of
them presents a boundary asserting a set and a second party checking
that assertion, because no record shape carries the basis on which
the set was closed.
*What this document requires until it is settled.* A claim that a set
is complete states the basis on which it is complete, under APS-LC-
COMPLETENESS-BASIS. A verifier that cannot establish that basis
reports not established with the coverage limb named, and does not
read an incomplete teardown as a finding that the descendants the
record does not name are valid.
Pidlisnyi Expires 1 April 2027 [Page 193]
Internet-Draft APS September 2026
*Scope.* Candidate. It touches the lifecycle continuity rules and no
requirement of APS Core conformance.
Cases. LC-B-022, a legal-claims exception as an actual basis for
retention. LC-B-023, preservation triggered by anticipated
litigation, earlier than formal process. LC-D-003, a believed
inventory standing in for a verified one. LC-D-025, what a grant was
used for as a different completeness claim from whether it is valid.
LC-F-027, an empty audit window as delivery lag rather than absence.
Candidates. BROAD-L7, whose coverage limb is a rule for reading a
state claim rather than a duty to establish coverage. CAND-02, which
keeps a later completeness finding as a new record rather than a
rewrite. Neither closes it.
Families. lifecycle-legal-regulatory-events, 44 vectors. lifecycle-
credential-events, 42 cases. lifecycle-infrastructure-failure, 30
cases. LC-B-023 has no family, because no record set decides it.
This does not establish that a complete teardown is unachievable. It
establishes that this document states no basis on which a party could
assert one.
19.2.2. Work in Flight
When authority is revoked while a workflow is running, the old grant
cannot authorize a new effect at the next authorization boundary.
What happens to the operation itself, whether it resumes under new
authority, restarts, compensates or stops, depends on the kind of
effect. There is no general model for it here.
*What is unresolved.* Whether an operation already running resumes,
restarts, compensates or stops after the authority it ran under
changes.
*Why the current evidence does not settle it.* The families carry
timelines in which authority changes mid-operation and record the
authority result at each boundary. None of them decides what the
operation does next, because that decision belongs to the effect and
not to the authority record.
*What this document requires until it is settled.* The old grant
authorizes no new effect at the next authorization boundary, under
APS-LC-RECHECK-AT-ADMISSION. Effects already completed stand. A
consumed approval admits no further dispatch, and a later attempt
needs a fresh authorization decision, under APS-ENF-RETRY-NEW-
DECISION.
Pidlisnyi Expires 1 April 2027 [Page 194]
Internet-Draft APS September 2026
*Scope.* Candidate. It touches the lifecycle continuity rules and
the decision-to-effect feature.
Cases. LC-B-029, a receiving institution's acceptance as a terminal
boundary a later change does not reach. LC-C-006, an ancestor found
invalid long after the fact. LC-E-008, which policy version a long-
running instance resolves its remaining steps against. LC-E-013,
invalidation arriving mid-run rather than at the next gateway check.
LC-E-020, dormant scheduled authority whose creator is gone.
Candidates. BROAD-L6, the decision at each boundary is fresh. CAND-
12, completed effects stand. CAND-16, when a recorded change becomes
effective. None of them says whether the operation resumes,
restarts, compensates or stops.
Families. lifecycle-organization-events, 35 cases. lifecycle-
multiple-principals-and-conflict, 92 vectors. lifecycle-time-and-
scheduling, 61 vectors. cached-authorization-revocation, 9 cases.
This does not establish that completed effects are unaffected by
every kind of later finding. It states that this document bounds
future effects and says nothing about the in-flight operation.
19.2.3. Release from Suspension
Lifting one suspension should not clear another, bypass a revocation
recorded while the agent was suspended, or recreate rights that
changed in the meantime. Multiple suspension causes need to compose,
with each one released separately. That composition is stated as a
candidate and no precedence order among causes is defined.
*What is unresolved.* Which cause is read first where two releases
point in opposite directions, and whether releasing a cause can
restore the shape authority had before the cause was imposed.
*Why the current evidence does not settle it.* The composition family
exercises independent release per cause. It carries no case in which
two releases conflict, because the rule it tests defines no
precedence and a fixture cannot test an order that does not exist.
*What this document requires until it is settled.* Causes are a set,
each release is decided independently under APS-LC-RELEASE-PER-CAUSE,
and authority stays inactive while any suspension cause remains.
Where a standing resolver cannot say, the state is not established
rather than released.
*Scope.* Candidate. It touches the suspension mechanism and no
requirement of APS Core conformance.
Pidlisnyi Expires 1 April 2027 [Page 195]
Internet-Draft APS September 2026
Cases. LC-B-011, an externally imposed restriction needing an
equally external release trigger. LC-B-024, independent suspensions
released independently. LC-C-022, a pending-ratification state that
is neither revoked nor not revoked. LC-E-034, a queued action that
outlasts a suspension.
Candidates. CAND-05, which makes causes a set and requires standing
for each release. CAND-09, which separates chain validity from an
external block and its removal. CAND-05 defines no precedence order.
Families. suspension-cause-composition, 16 cases and 5 gates.
lifecycle-legal-regulatory-events, 44 vectors. lifecycle-multiple-
principals-and-conflict, 92 vectors. lifecycle-time-and-scheduling,
61 vectors.
This does not establish that causes never interact. It states that
no rule here decides which cause is read first when two releases
conflict.
19.2.4. Critical Revocation
Revoking a high-level authority can end the authority of a large set
of agents at once. One design binds an approval for such a
revocation to a snapshot of its impact and checks it again
immediately before the revocation takes effect, treating uncertain
impact as large rather than small. That design is written down and
is neither built nor tested.
*What is unresolved.* Whether revoking an authority whose dependents
are numerous needs an approval path different from any other
revocation, for example one bound to a snapshot of its impact and
rechecked immediately before it takes effect.
*Why the current evidence does not settle it.* No family in the suite
exercises an impact snapshot, an approval bound to one, or a recheck
against one. The design is written down and has never been run.
*What this document requires until it is settled.* Nothing. A
revocation of any size is the ordinary revocation of APS-LC-ANCESTOR-
REVOCATION-REACHES-DEPENDENTS, and this document places no additional
condition on a revocation because of how many dependents it reaches.
*Scope.* Candidate. Adopting an additional condition would change a
Core behavior, which is why it is not proposed here.
Cases. LC-B-025, one revoked licence invalidating every chain that
depends on it at once. LC-D-004, a compromised operator identity as
an implicit ancestor over many independent trees. LC-D-014, an
Pidlisnyi Expires 1 April 2027 [Page 196]
Internet-Draft APS September 2026
issuer whose own issuance log cannot be relied on. LC-F-033,
systemic issuer misbehaviour escalating to distrust of the whole
issuer.
Candidates. CAND-01, an external event is authority-changing only
when established. ANX-01, a verdict records its event-class
coverage. Neither proposes binding an approval to an impact
snapshot.
Families. lifecycle-legal-regulatory-events, 44 vectors. lifecycle-
credential-events, 42 cases.
This does not establish that a large revocation needs a different
approval path. It records that no vector here exercises one.
19.2.5. Office Vacancy and Succession
Where authority was exercised for an office and nobody currently
holds it, nobody may be empowered to exercise, reaffirm or revoke
what the previous holder issued. Whether office-based grants
continue, suspend or need reaffirmation during a vacancy, and who may
act for the office until it is filled, is not defined.
*What is unresolved.* Whether office-based grants continue, suspend
or need reaffirmation while nobody holds the office, and who may act
for the office until it is filled.
*Why the current evidence does not settle it.* The succession
families exercise a covering holder record, a covering vacancy record
and a conflicting pair. None of them exercises a vacancy in which no
party holds standing to exercise, reaffirm or revoke what the
previous holder issued, because a fixture with no standing source has
nothing to assert against.
*What this document requires until it is settled.* A vacancy record
covering the action instant leaves the question not established under
APS-LC-VACANCY-NOT-ESTABLISHED, and a verifier does not carry the
last known holder through a vacancy. Not established here is not a
finding that the authority ended.
*Scope.* Candidate. It touches the succession mechanism and no
requirement of APS Core conformance.
Pidlisnyi Expires 1 April 2027 [Page 197]
Internet-Draft APS September 2026
Cases. LC-A-019, a vacancy that does not have to be filled before
the remaining holders can act. LC-C-007, office binding against
identity binding as an explicit design choice. LC-C-008, a missing
successor designation resolving to a named default rather than
failing closed. LC-C-009, a succession order that is deliberately
not public. LC-I-009, an interim holder's caretaking scope,
including extending its own mandate.
Candidates. CAND-13, replacement authority may be pre-committed.
CAND-04, activation is established, not yet effective, or not
established. CAND-03, which separates issuance validity from current
validity. None says what happens when nobody holds the office and
nobody is empowered to act for it.
Families. lifecycle-root-authority-succession, 13 cases. lifecycle-
fiduciary-succession, 25 cases. activation-not-established, 19 cases
and 5 gates. lifecycle-expiry-and-renewal, 15 vectors.
This does not establish that a vacancy ends office-based authority.
It states that this document selects none of the three outcomes.
19.2.6. Grants Signed Just Before a Departure
Where issuer standing is evaluated at issuance, an issuer who knows
they are leaving can sign long-lived grants that stay valid after
they are gone. A bounded lifetime for grants issued for an office,
or a review when the office changes hands, are possible answers.
Neither is specified.
*What is unresolved.* Whether anything bounds what an issuer who
knows they are leaving may sign, for example a bounded lifetime for
office grants or a review when the office changes hands.
*Why the current evidence does not settle it.* Issuer standing is
evaluated at issuance and the families exercise it there. None of
them carries an issuer signing in anticipation of a departure,
because the record of such a grant is indistinguishable from any
other grant signed at the same instant.
*What this document requires until it is settled.* Nothing beyond the
temporal facet the grant itself carries. Issuance validity and
current validity stay separate findings under APS-PRIN-TWO-FINDINGS,
and a grant signed before a departure is valid until an ordinary
lifecycle event ends it.
*Scope.* Candidate. It touches the succession mechanism and no
requirement of APS Core conformance.
Pidlisnyi Expires 1 April 2027 [Page 198]
Internet-Draft APS September 2026
Cases. LC-A-016, replacement authority pre-committed at issuance
rather than issued after the fact. LC-C-007, whether the grant was
bound to the office or to the person. LC-H-010, a resignation
effective on delivery of notice, which fixes when the departure
happened. LC-I-009, an interim holder extending its own reach.
Candidates. CAND-03, which separates issuance validity from current
validity and deliberately does not answer this. CAND-13, which
covers pre-commitment and not a bound on what an outgoing issuer may
pre-commit.
Families. lifecycle-root-authority-succession, 13 cases. lifecycle-
principal-events, 32 cases. lifecycle-agent-renunciation, 13 cases.
lifecycle-expiry-and-renewal, 15 vectors.
This does not establish that such grants are invalid. It states that
nothing here bounds what an outgoing issuer may sign.
19.2.7. Authority Rollback
Restoring a backup, a snapshot or a lagging replica can bring back
authority state from before a revocation. An authority epoch, or an
append-only record of revocations that a restore has to replay, would
stop a restore from reviving revoked authority. Neither is specified
here, and what a verifier should return after a restore is not
tested.
*What is unresolved.* What a verifier returns after a restore, and
what a verifier does when its own remembered high-water mark was
itself restored from stale state.
*Why the current evidence does not settle it.* The rollback family
exercises the rejection of stale authority: a presented value that
regressed against an established high-water mark is refused. It
carries no case in which the remembered mark is the thing that was
restored, so it is not evidence about recovery from stale verifier
memory.
*What this document requires until it is settled.* An enforcement
point does not act on a state older than the newest it has
established for that subject, under APS-LC-EPOCH-NO-REGRESSION, and
refuses rather than resolving by recency of write. An implementation
claiming the epoch feature defines its stale-verifier-state handling
or reports the feature unsupported, under APS-LC-EPOCH-FEATURE-
DEFINITION.
*Scope.* Candidate. It touches the authority-epoch mechanism and no
requirement of APS Core conformance.
Pidlisnyi Expires 1 April 2027 [Page 199]
Internet-Draft APS September 2026
Cases. LC-E-023, a faithfully restored process holding authority
that may no longer be current. LC-F-016, a storage-layer partition
resurrecting revoked authority below the application layer. LC-
F-017, a revocation true at the source and false at a lagging
replica. LC-F-018, regional enforcement points briefly disagreeing.
LC-F-024, a lock holder whose pause outlasts its lease. LC-F-026, an
isolated primary accepting writes nobody else will see.
Candidates. CAND-08, which forbids acting on a state older than the
newest established for that subject and requires an explicit
attributable record to restore superseded authority.
Families. authority-epoch-rollback, 12 cases. lifecycle-
infrastructure-failure, 30 cases. conflicting-status-sources, 14
cases.
This does not establish that a restore revives revoked authority. It
states that no rule here prevents it.
19.2.8. Semantic Drift
A grant can stay byte for byte the same while what it authorizes
changes, because a tool, an API version or a resource classification
changed underneath it. When a change in meaning should invalidate an
earlier grant or approval, and how a verifier would detect it, is
open.
*What is unresolved.* When a change in what a grant authorizes, with
no change to the grant itself, should invalidate the grant or an
approval under it, and how a verifier holding only records would
detect such a change.
*Why the current evidence does not settle it.* The drift family
exercises the pinned case, the unpinned case and a change of
controller against a model-declared basis. Every one of those starts
from something that was pinned or declared. No vector presents a
change no party declared, because a fixture cannot supply evidence of
a change nobody recorded.
*What this document requires until it is settled.* Where the
authority model declares a class of referent change capability-
relevant, continuity across such a change is established by something
that pins it, under APS-LC-REFERENT-CONTINUITY-PINNED. Where nothing
pins it, continuity is not established and the verdict says so. An
unchanged name is never read as evidence of an unchanged referent.
*Scope.* Candidate. It touches the capability-binding mechanism and
no requirement of APS Core conformance.
Pidlisnyi Expires 1 April 2027 [Page 200]
Internet-Draft APS September 2026
Cases. LC-E-001, a stable model alias as a pointer with a documented
default. LC-E-002, a valid grant whose named executor is gone. LC-
E-027, a precedent for gating expanded capability behind re-consent.
LC-E-033, a provider-side capability upgrade with no delegation-layer
event.
Candidates. CAND-07, a stable name does not establish stable
semantics, which handles the pinned, unpinned and controller cases
against a model-declared basis. CAND-11, a valid grant can be
unexecutable. Whether a change in meaning should invalidate an
earlier grant, and how a verifier would detect it unaided, stays
open.
Families. capability-binding-drift, 8 presentations and a declared
defective fail set of 5. lifecycle-agent-side-events, 20
presentations.
This does not establish that a pinned referent is enough. It states
that detection of a meaning change by a verifier holding only records
is not specified.
19.2.9. Notice and Relying Parties
A revocation can be recorded at one moment and reach an agent, a
gateway and an outside counterparty at different moments. What a
relying party that acted on stale but authentic evidence is entitled
to, and what evidence of notice a principal needs to show, is not
defined here.
*What is unresolved.* What a relying party that acted on stale but
authentic evidence is entitled to, and what evidence of notice a
principal needs to show.
*Why the current evidence does not settle it.* The families exercise
what a verifier establishes from records. Entitlement is not a
finding a verifier returns from records, so no vector can assert it,
and the reliance-notice family records the separation rather than
resolving it.
*What this document requires until it is settled.* Recording a
transition and observing it stay separate events. Where a profile
makes a change effective on a party notice, the notice finding
carries its own time and a verifier records a notice finding or
records that it has none. This document states no entitlement for
any party.
Pidlisnyi Expires 1 April 2027 [Page 201]
Internet-Draft APS September 2026
*Scope.* Candidate. It touches the principal and departure
mechanism. No case behind this question states that a rule about
human agents applies to an AI agent.
Cases. LC-A-001, termination effective on the agent's notice rather
than at the event. LC-A-027, a verifier's chain-is-void finding and
a relying party's protected reliance as two facts. LC-A-028, two
tiers of notice for known counterparties and for strangers. LC-
H-006, a disputed root deposited with a neutral forum. LC-I-001, a
re-registered identifier with no delegation-layer event marking the
change of hands.
Candidates. ANX-03, which separates chain validity from a party's
knowledge and gives the notice finding its own timestamp. CAND-16,
on when a recorded change becomes effective. ANX-03 proposes the
separation and nothing about entitlement.
Families. lifecycle-principal-events, 32 cases. lifecycle-third-
party-reliance-notice, 12 vectors. lifecycle-multiple-principals-
and-conflict, 92 vectors. lifecycle-identifier-reuse-and-rename, 13
presentations.
The cases above come from bodies of law about human agents. Nothing
here states that any of those rules applies to an AI agent, and
nothing here establishes any entitlement for a relying party.
19.2.10. Associating a Principal with an Accepted Authority
A verifier can accept a principal binding and accept a root authority
basis independently, and still have established nothing about whether
the two belong to one authority context. Accepting a root
establishes that a chain has a head the verifier's trust policy
admits. It does not establish which principal that authority
represents.
*What is unresolved.* Which artifact or verifier state associates the
principal axis with the accepted authority lineage for one action,
and what standing the party supplying that association has to hold.
*Why the current evidence does not settle it.* This revision defines
no artifact for the step from a principal to a first authority.
PrincipalBindingV1 names the principal an agent acts for and is
scoped to audiences and authority profiles. A root delegation names
an issuer, a subject and an authority vector. Neither carries a
reference to the other, so no family can present a substituted
principal and a matching one as two vectors that a verifier
separates, and none does.
Pidlisnyi Expires 1 April 2027 [Page 202]
Internet-Draft APS September 2026
*What this document requires until it is settled.* The association is
profile and trust-policy dependent, over the binding, the accepted
root basis and the authority-state material. Where it cannot be made
it is not established, and a verifier does not infer it from agent
identity or from root selection alone, which is the safe behavior
until the question is settled. A verifier that cannot establish it
does not report the action as taken for the principal the chain
names.
*Scope.* Core. Every verification of every action passes through
this arrow, which is why it is named here rather than left to a
feature. The design work named for it is a component schema for the
authority_state_ref of Section 7.4 binding the principal, the
accepted root basis, the current status and the action. That schema
is tested before any new object or decision-format change, and
nothing in this revision depends on it.
Cases. LC-D-004, a compromised operator identity acting as an
implicit ancestor over many independent trees. LC-I-001, a re-
registered identifier with no delegation-layer event marking the
change of hands.
Families. None. The security considerations name principal
substitution as a failure class and name lifecycle-identifier-reuse-
and-rename for the identifier half of it. No family binds a
principal reference across a decision and an admission.
19.2.11. A Durable Record of Admission
The stage chain is intent, decision, result. Admission sits between
the second and the third and produces nothing. Whether an approval
was consumed is enforcement-boundary state keyed by the approval's
identity, and it is not content of any record this document defines.
*What is unresolved.* Whether the admission transition should produce
a signed record, and if it should, what that record's predecessor is,
what a refusal before admission produces, and what becomes the
predecessor of the action-result record.
*Why the current evidence does not settle it.* No family exercises a
fourth stage. The family that pins the action-result stage supplies
no predecessor in any of its cases, so the predecessor axis a fourth
stage would depend on is reported as not checked throughout. A
signed admission record would also not establish that the boundary
performed consumption, reservation and dispatch atomically, so the
record alone would not answer the question it looks like it answers.
Pidlisnyi Expires 1 April 2027 [Page 203]
Internet-Draft APS September 2026
*What this document requires until it is settled.* A verifier that
holds no consumption state reports the approval-state axis as not
established, under the axis discipline of Section 7.6, and does not
report an action admitted from an approval that was issued, under
APS-EVID-STATES-NOT-SYNONYMS. Evaluation alone never consumes an
approval, and a refusal before admission leaves the approval
unconsumed.
*Scope.* Core. The stage chain is core, so any durable admission
record changes a Core construction rather than adding a feature
beside it. Versioning, predecessor resolution and the handling of
records written under this revision are settled together or not at
all.
Families. action-result-binding, 6 cases, with the predecessor axis
not checked in all six. approval-single-use, 9 presentations, which
exercises consumption at the boundary without producing a record of
it.
19.2.12. Recovery Across Consumption, Reservation and Dispatch
Consumption of an approval is atomic. Reservation against every
bounded ancestor is atomic. Dispatch is neither of those things and
the three are not one transaction.
*What is unresolved.* What a boundary does after a failure between
consumption and a durably established dispatch, how two concurrent
admissions on one approval resolve beyond the requirement that
consumption itself be atomic, and how an operation resumes without
repeating its effect.
*Why the current evidence does not settle it.* The single-use family
exercises a race pair at the boundary and admits the first
presentation while refusing the second. That establishes
serialisation of consumption. It does not reach a failure after
consumption, because a fixture that stops a boundary mid-transaction
would be testing the boundary's storage and not the protocol.
*What this document requires until it is settled.* The four moments
the closed core already holds, which Section 9.8 reads together
without adding to them. An idempotent reservation lookup is not
permission to dispatch again, and a consumed approval does not become
reusable because its reservation is still outstanding, both entailed
by Section 7.3.2, under which only an approval that has neither
expired nor been consumed admits dispatch. A reservation is released
only before dispatch or on trusted evidence that dispatch did not
occur, which Section 4.4 states.
Pidlisnyi Expires 1 April 2027 [Page 204]
Internet-Draft APS September 2026
*Scope.* Core. The reservation contract is the core's. A portable
recovery contract would have to be defined before any durable
admission record could carry one, which is why the two questions are
settled in that order.
Families. approval-single-use, 9 presentations, for serialised
consumption. lifecycle-infrastructure-failure, 30 cases, for the
partition and restore shapes a recovery contract would have to
survive.
19.2.13. Whether Holding a Scope Establishes Authority to Confer It
This question was drafted as a candidate lifecycle extension and is
carried here instead, because the counterexample against it is
unresolved.
*What is unresolved.* Whether an agent's holding a scope establishes
that it may confer that scope on another party, including a child
process it spawns or a copy of itself.
*Why the current evidence does not settle it.* The statement that
conferral needs its own declared authority has a counterexample
nothing in the drafting answers. Authority models exist in which
conferral needs no separate grant, because a platform default creates
the child with no explicit pass, and models exist in which a
principal may grant the power to designate successors by name, office
or function. Both are real models and the statement denies authority
in both. The conferral family reaches an undeclared conferral right
as a schema failure rather than as a finding about conferral, so its
vectors do not separate the two readings.
*What this document requires until it is settled.* Nothing beyond
what the closed core already states. Monotonic narrowing bounds what
a child may receive and says nothing about who may create one, and
depth exhaustion is a separate structural limit. A verifier does not
report a conferral finding this document does not define.
*Scope.* Candidate. Nothing in APS Core conformance depends on it.
Cases. LC-E-006, a subagent handing a held scope to a process it
spawned. Families. lifecycle-conferral-without-authority, 10
vectors.
19.2.14. When a Recorded Lifecycle Change Becomes Effective
This question was drafted as a candidate lifecycle extension and is
carried here instead, because the counterexample against it is
unresolved.
Pidlisnyi Expires 1 April 2027 [Page 205]
Internet-Draft APS September 2026
*What is unresolved.* What an authority model that declares no
effectiveness rule for a change type falls back to.
*Why the current evidence does not settle it.* The drafted default
was effective from the moment the change is recorded. The
counterexample is the default itself. Effective on observation is
equally defensible and is what a lagging enforcement point actually
does, and a deployment that treats actions allowed by a lagging
boundary inside a declared bound as a declared and bounded risk has
chosen it deliberately. No family runs the same change under both
readings, so nothing here distinguishes them.
*What this document requires until it is settled.* A verifier that
treats a recorded change as effective records which rule it applied.
Where the model declares a rule, the rule governs. Where it declares
none, this document supplies no default and the effectiveness of the
change at a given boundary is not established.
*Scope.* Candidate. This is not a freshness rule, which asks how old
a verifier's answer is rather than whether the change took effect at
all, and it is not a notice rule about third parties. Cases. LC-
F-018, regional enforcement points briefly disagreeing. Families.
conflicting-status-sources, 14 cases. lifecycle-infrastructure-
failure, 30 cases.
19.2.15. Ending Authority Without Issuer Standing
A party can hold standing to end an authority artifact it never
issued. Section 8.1 names that standing and Section 10.5 gives three
shapes of it. For a direct revocation Section 4.5 names one party,
the delegation's issuer, and the format at Section 4.5.2 carries one
revoker member and requires it to equal that issuer.
*What is unresolved.* Whether a party holding lifecycle standing over
an artifact it did not issue can end that artifact directly, and what
record carries such an act.
*Why the current evidence does not settle it.* One requirement is
keyed to the revoker member, APS-REC-REVOCATION-REVOKER-IS-ISSUER,
which Section 4.5.2 states for that format and Appendix D marks
specified and not exercised, and no vector named there presents a
revocation from a party other than the issuer. A vector in either
direction would need a standing source the corpus does not model,
which is the same missing piece as the standing registry named
elsewhere in this section.
Pidlisnyi Expires 1 April 2027 [Page 206]
Internet-Draft APS September 2026
*What this document requires until it is settled.* A direct
revocation is the issuer's. A party with lifecycle standing that is
not the issuer ends dependent authority by revoking its own ancestor
grant, or through a suspension cause under Section 8.3.5, which
pauses use without ending the artifact. A verifier does not accept a
revocation record whose revoker is not the named delegation's issuer,
which the format at Section 4.5.2 carries as APS-REC-REVOCATION-
REVOKER-IS-ISSUER for records under that format.
*Scope.* Core. The revocation rule is in the closed core, so a party
other than the issuer is not admitted by claiming a feature.
Cases. LC-B-008, authority ending completely and instantly from
outside the delegation system. LC-B-025, one revoked licence
invalidating every chain that depends on it at once.
Families. lifecycle-outside-the-chain-standing, 22 vectors, for
standing held from outside the chain. authority-revocation-record, 8
vectors, which exercises the format for an issuer revocation only.
19.2.16. Two Items Held Out of This Revision
The two items below were drafted, reviewed and left out on purpose.
They are recorded here so that the sections they would touch are not
read as settled. Both are held by a ruling rather than by a missing
answer, which is why they are listed apart from the questions above.
The cascade-derived and cascade-completion record formats. This
revision now specifies one direct revocation record format, at
Section 4.5.2, which a family exercises against five independent
negatives and a duplicate-offer case. That subsection defines
neither a cascade-derived record nor a cascade-completion record, and
no released package issues or verifies either. What is missing
before this document could specify them is a family that settles who
signs a cascade-derived record, how duplicates are treated, and on
what basis a completion record could claim its set was complete,
which is the question at Section 19.2.1. Until then the SHOULD of
Section 4.5.1 and its profile-defined format stand, and a verifier
without both the originating revocation record and a profile for its
format reports the evidence cascade state as indeterminate, which
does not change the authority result.
The action-result predecessor binding. For an action-result record,
the prev clause carries no BCP 14 keyword while the decision-
reference equality in the same sentence carries MUST, and the step
that validates prev and stage transitions during receipt verification
carries none. Both reference implementations accept an action-result
record whose prev names the action-intent record rather than the
Pidlisnyi Expires 1 April 2027 [Page 207]
Internet-Draft APS September 2026
consumed policy decision. Opt-in predecessor binding shipped in the
reference implementations and is recorded there as hardening rather
than as a conformance fix, and the family that pins the action-result
stage supplies no predecessor in any of its cases, so the predecessor
axis is reported as not checked throughout. Two things a ruling has
to settle first. Whether the action-intent to policy-decision link
is made normative at the same time, since it is stated in the same
unkeyworded form and is a different pairing with a different expected
predecessor type. What a verifier that cannot obtain the predecessor
reports, which on the axis discipline this document applies elsewhere
is indeterminate rather than invalid, because an unobtainable
predecessor is a gap in the verifier's evidence and not a defect in
the record.
Families. action-result-binding, 6 cases, with the predecessor axis
not checked in all 6. receipt-decision-relation, 7 vectors.
Neither item establishes a defect in this revision. Each records a
place where this document states less than an implementation already
does.
19.2.17. Four Designs Under Consideration
The four designs below are written down and are not part of this
document. Each is stated with the one thing missing before it could
enter, which in every case is a conformance family that exercises it.
None of them is a commitment, and their presence here is not notice
that a later revision will carry them.
A root authority grant object. Authority delegation in this document
starts from a record whose parent identifier is null, and acceptance
of such a root is verifier policy rather than something the record
establishes. A separate object for the step from a principal to the
first authority would make that step checkable from records.
Missing: no family exercises a record for that step, so every family
starts from a chain whose root is accepted by configuration.
A principal reference bound through the decision and the admission.
The action-binding rule during receipt verification compares the
supplied action input object's agent_id with the record's
subject_agent. Both name the acting agent. A principal reference
carried through the decision and then through the moment the approval
is consumed would let a verifier establish that the action was
admitted for the principal the chain names, and would bear on
principal substitution. Missing: no family binds a principal
reference across the decision and the admission point, so no vector
distinguishes a substituted principal from a matching one at that
boundary.
Pidlisnyi Expires 1 April 2027 [Page 208]
Internet-Draft APS September 2026
An admission record between the decision and the result. Today the
stage chain is intent, decision, result, and whether a decision was
consumed is boundary state rather than record content, which is why
the approval-state axis is not established for a verifier without
access to that state. A fourth stage would make the admission itself
a signed record, would give Section 9.6 a record to rest on, would
make a refusal a signed record rather than an absence, and would make
the result's predecessor the admission rather than the decision.
Missing: no family exercises a fourth stage, and the predecessor axis
that a fourth stage would depend on is not checked in any case of the
family that pins the action-result stage.
A facet partition into core and profile dimensions. The authority
object here carries exactly seven facets, a missing facet is invalid
rather than an implicit unconstrained value, and a profile change on
a facet is unsupported rather than narrower. Splitting the set into
facets every implementation compares and facets a profile declares
would let a deployment add a dimension without making every other
implementation report unsupported. Missing: no family exercises a
facet set other than the seven, so no vector shows what a verifier
should return for a facet it does not know.
None of the four establishes a gap that this revision has to close.
Each records a design whose entry condition is a family that does not
exist.
20. 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 3.3), key and evidence resolution
outcomes (Section 3.5 and Section 7.5), and separate receipt-
verification axes (Section 7.6). Generalizing those results into one
normative vocabulary remains future work. A crosswalk from those
results to whatever vocabulary the wider evidence-sufficiency
discussion settles on [COSAI-189] is future work on the same footing.
This revision does not rename its own outcomes against an unadopted
proposal.
Cross-implementation profiles for DecisionRefV1 also remain future
work. Section 7.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 18) and the normative
specification of institutional governance structures (Section 10)
remain companion work.
Pidlisnyi Expires 1 April 2027 [Page 209]
Internet-Draft APS September 2026
A profile carrying a ReceiptV1 record (Section 7.1) as a signed
statement for registration with a Transparency Service [RFC9943] also
remains future work. Section 14 positions the envelope against that
architecture. This revision does not define the carriage, the
protected claims such a registration requires, or what a relying
party may conclude from a registration receipt.
Operationally independent witnessing of agent state remains partially
addressed. This revision separates proof of possession from signer
authority (Section 3.1, Section 3.4, Section 3.5 and Section 7.2),
defines separately signed principal bindings and claim levels
(Section 3.3), and keeps attestation provenance separate from
verification status (Section 3.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.
Reasoned reaffirmation and constitutional change are future work.
This revision states that a recorded revocation is irreversible, that
restoring superseded authority is a new record from a party with
lifecycle standing rather than a reversal, and that a successor
inherits no tree. It states nothing about the case where the rule
that grants authority changes rather than the authority itself: an
institution amending its own charter, a principal changing the terms
on which every grant beneath it stands, or a party reaffirming an
authority for a stated reason after the condition that suspended it
is gone. Each of those needs a record whose subject is a rule rather
than an artifact, and needs a verifier to decide what a change to a
rule does to the artifacts issued under the previous rule. Nothing
here specifies either. Entry would need a family that exercises a
rule change against the artifacts under it, which no family in the
corpus does.
21. References
21.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
Pidlisnyi Expires 1 April 2027 [Page 210]
Internet-Draft APS September 2026
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
[RFC6234] 3rd, D. E. and T. Hansen, "US Secure Hash Algorithms (SHA
and SHA-based HMAC and HKDF)", RFC 6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[UAX15] The Unicode Consortium, "Unicode Standard Annex #15:
Unicode Normalization Forms",
<https://www.unicode.org/reports/tr15/>.
21.2. Informative References
[DID-KEY] W3C Credentials Community Group, "The did:key Method",
2024, <https://w3c-ccg.github.io/did-key-spec/>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[MCP] Model Context Protocol Project, "Model Context Protocol
Specification, Version 2026-07-28", July 2026,
<https://modelcontextprotocol.io/
specification/2026-07-28>.
[A2A] A2A Project, "Agent2Agent (A2A) Protocol Specification",
<https://a2a-protocol.org/>.
[DID-CORE] W3C, "Decentralized Identifiers (DIDs) v1.0", July 2022,
<https://www.w3.org/TR/did-core/>.
[PEDIGREE] Rampalli, K., "PEDIGREE: Verifiable Delegation Identity
for Agentic AI Systems", Work in Progress, Internet-Draft,
draft-rampalli-pedigree-00, April 2026,
<https://datatracker.ietf.org/doc/draft-rampalli-
pedigree/>.
Pidlisnyi Expires 1 April 2027 [Page 211]
Internet-Draft APS September 2026
[DRP] Nelson, R., "Delegation Receipt Protocol for AI Agent
Authorization", Work in Progress, Internet-Draft, draft-
nelson-agent-delegation-receipts-10, June 2026,
<https://datatracker.ietf.org/doc/draft-nelson-agent-
delegation-receipts/>.
[ACTION-REF]
Etcheverry, P. and K. Ives, "Action Reference: A
Deterministic Identifier for Agent Actions", Work in
Progress, Internet-Draft, draft-etcheverry-action-ref-03,
August 2026, <https://datatracker.ietf.org/doc/draft-
etcheverry-action-ref/>.
[WIMSE-XORG]
Reece, M., "Cross-Organizational Delegation for Workload
and Agent Identity: Problem Statement and Requirements",
Work in Progress, Internet-Draft, draft-reece-wimse-cross-
org-delegation-02, August 2026,
<https://datatracker.ietf.org/doc/draft-reece-wimse-cross-
org-delegation/>.
[OAUTH-CHAIN-DEL]
Liu, D., Zhu, H., Krishnan, S., and A. Parecki,
"Delegation Chain for OAuth 2.0", Work in Progress,
Internet-Draft, draft-liu-oauth-chain-delegation-00, June
2026, <https://datatracker.ietf.org/doc/draft-liu-oauth-
chain-delegation/>.
[OAUTH-AUTHZ-EV]
Liu, D., Zhu, H., Krishnan, S., and A. Parecki,
"Authorization Evidence and Audit Trail for OAuth 2.0
Access Tokens", Work in Progress, Internet-Draft, draft-
liu-oauth-authorization-evidence-01, June 2026,
<https://datatracker.ietf.org/doc/draft-liu-oauth-
authorization-evidence/>.
[OAUTH-INTEGRATION]
Liu, D., Zhu, H., Krishnan, S., Parecki, A., and H. Xue,
"AI Agent Authorization Integration Framework", Work in
Progress, Internet-Draft, draft-liu-ai-agent-
authorization-integration-00, July 2026,
<https://datatracker.ietf.org/doc/draft-liu-ai-agent-
authorization-integration/>.
Pidlisnyi Expires 1 April 2027 [Page 212]
Internet-Draft APS September 2026
[OAUTH-REGO]
Liu, D., Zhu, H., Krishnan, S., Parecki, A., and H. Xue,
"Rego Policy Language for OAuth 2.0 Authorization", Work
in Progress, Internet-Draft, draft-liu-oauth-rego-policy-
00, June 2026, <https://datatracker.ietf.org/doc/draft-
liu-oauth-rego-policy/>.
[EP-AEC] Schrock, I., "Authorization Evidence Chains: Composing
Heterogeneous Agent-Action Evidence (EP-AEC)", Work in
Progress, Internet-Draft, draft-schrock-ep-authorization-
evidence-chain-07, September 2026,
<https://datatracker.ietf.org/doc/draft-schrock-ep-
authorization-evidence-chain/>.
[EP-AUTHINTRO]
Schrock, I., "Authority Documents and Scoped Authority for
Agent-Action Evidence", Work in Progress, Internet-Draft,
draft-schrock-ep-authority-introduction-03, August 2026,
<https://datatracker.ietf.org/doc/draft-schrock-ep-
authority-introduction/>.
[EP-HUMANAUTH]
Schrock, I., "Binding Named-Human Authorization Evidence
into Agent-Action Records", Work in Progress, Internet-
Draft, draft-schrock-human-authorization-binding-00, July
2026, <https://datatracker.ietf.org/doc/draft-schrock-
human-authorization-binding/>.
[SCITT-CAPSULE]
Rampalli, K., "Binding Per-Action Authorization and Memory
Provenance into Agent Action Capsules", Work in Progress,
Internet-Draft, draft-rampalli-scitt-capsule-provenance-
binding-00, July 2026, <https://datatracker.ietf.org/doc/
draft-rampalli-scitt-capsule-provenance-binding/>.
[AGENT-ID-FW]
Duda, A., Korczynski, M., Hureau, O., Fernandez, S.,
Zhang, J., and H. Labiod, "Self-Certifying Identity and
Capability-Based Delegation for Autonomous AI Agents",
Work in Progress, Internet-Draft, draft-duda-agent-id-
framework-00, June 2026,
<https://datatracker.ietf.org/doc/draft-duda-agent-id-
framework/>.
Pidlisnyi Expires 1 April 2027 [Page 213]
Internet-Draft APS September 2026
[AGENT-ID-ARCH]
Beyer, B. W., "Architecture for Human-Anchored Agent
Identity, Delegation, and Provenance", Work in Progress,
Internet-Draft, draft-beyer-agent-identity-architecture-
00, April 2026, <https://datatracker.ietf.org/doc/draft-
beyer-agent-identity-architecture/>.
[AIMS] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B.,
Steele, N., and A. Parecki, "AI Identity Management
System", Work in Progress, Internet-Draft, draft-ietf-
wimse-aims-00, September 2026,
<https://datatracker.ietf.org/doc/draft-ietf-wimse-aims/>.
[AIP-DELEGATION]
Singla, P., "Agent Identity Protocol (AIP): Decentralized
Identity and Delegation for AI Agents", Work in Progress,
Internet-Draft, draft-singla-agent-identity-protocol-03,
June 2026, <https://datatracker.ietf.org/doc/draft-singla-
agent-identity-protocol/>.
[AIP-ENFORCEMENT]
Cao, J. and C. Arango Gutierrez, "Agent Identity Protocol:
Agentic Authentication and Authorized Policy Enforcement",
expired 17 September 2026, Work in Progress, Internet-
Draft, draft-aip-agent-identity-protocol-00, March 2026,
<https://datatracker.ietf.org/doc/draft-aip-agent-
identity-protocol/>.
[APS-NARROWING]
Pidlisnyi, T., "Monotonic Narrowing for Agent Authority",
March 2026, <https://doi.org/10.5281/zenodo.18932404>.
[APS-FACETED]
Pidlisnyi, T., "Faceted Authority Attenuation", March
2026, <https://doi.org/10.5281/zenodo.19260073>.
[APS-EVIDENCE-GAP]
Pidlisnyi, T., "The Evidence-Safety Gap in Cryptographic
Agent Governance", April 2026,
<https://doi.org/10.5281/zenodo.19914628>.
[OAUTH-ID-JAG]
Parecki, A., McGuinness, K., and B. Campbell, "Identity
Assertion JWT Authorization Grant", Work in Progress,
Internet-Draft, draft-ietf-oauth-identity-assertion-authz-
grant-04, May 2026, <https://datatracker.ietf.org/doc/
draft-ietf-oauth-identity-assertion-authz-grant/>.
Pidlisnyi Expires 1 April 2027 [Page 214]
Internet-Draft APS September 2026
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943, June 2026,
<https://www.rfc-editor.org/info/rfc9943>.
[RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C.
Fournet, "CBOR Object Signing and Encryption (COSE)
Receipts", RFC 9942, June 2026,
<https://www.rfc-editor.org/info/rfc9942>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.
Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, January
2020, <https://www.rfc-editor.org/info/rfc8693>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[OAUTH-ACTOR-CHAIN]
Prasad, A., Krishnan, R., Lopez, D., and S. Addepalli,
"Cryptographically Verifiable Actor Chains for OAuth 2.0
Token Exchange", Work in Progress, Internet-Draft, draft-
mw-oauth-actor-chain-01, June 2026,
<https://datatracker.ietf.org/doc/draft-mw-oauth-actor-
chain/>.
[OAUTH-ACTOR-PROFILE]
McGuinness, K., "OAuth Actor Profile for Delegation", Work
in Progress, Internet-Draft, draft-mcguinness-oauth-actor-
profile-00, April 2026, <https://datatracker.ietf.org/doc/
draft-mcguinness-oauth-actor-profile/>.
[OAUTH-REQ-DEL-CHAIN]
Zehavi, Y., "OAuth Authorization Request Delegation
Chain", Work in Progress, Internet-Draft, draft-zehavi-
oauth-authz-req-del-chain-01, September 2026,
<https://datatracker.ietf.org/doc/draft-zehavi-oauth-
authz-req-del-chain/>.
[OAUTH-REVOC-CLOSURE]
Watts, D., "Revocation Closure for Agentic Authorization
Systems", Work in Progress, Internet-Draft, draft-watts-
oauth-agent-revocation-closure-00, September 2026,
<https://datatracker.ietf.org/doc/draft-watts-oauth-agent-
revocation-closure/>.
Pidlisnyi Expires 1 April 2027 [Page 215]
Internet-Draft APS September 2026
[AIP-IBCT] Prakash, S., "Agent Identity Protocol (AIP): Verifiable
Delegation for AI Agent Systems", Work in Progress,
Internet-Draft, draft-prakash-aip-01, August 2026,
<https://datatracker.ietf.org/doc/draft-prakash-aip/>.
[SCITT-AGENT-RECEIPT]
Toraman, T., "A SCITT Profile for AI-Agent Action
Receipts", Work in Progress, Internet-Draft, draft-noa-
scitt-ai-agent-receipt-01, August 2026,
<https://datatracker.ietf.org/doc/draft-noa-scitt-ai-
agent-receipt/>.
[SCITT-ACTION-CAPSULE]
Mih, S., "An Agent Action Capsule Profile for SCITT", Work
in Progress, Internet-Draft, draft-mih-scitt-agent-action-
capsule-05, September 2026,
<https://datatracker.ietf.org/doc/draft-mih-scitt-agent-
action-capsule/>.
[VAARA-RECEIPT]
Sirkkavaara, H., "The Vaara Receipt: A Recomputable
Receipt Format for Decisions About Autonomous Actions",
Work in Progress, Internet-Draft, draft-sirkkavaara-vaara-
receipt-11, September 2026,
<https://datatracker.ietf.org/doc/draft-sirkkavaara-vaara-
receipt/>.
[MCP-SEP-2787]
Model Context Protocol Project, "SEP-2787: Tool call
attestation", specification enhancement proposal, closed
22 September 2026, 2026,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/pull/2787>.
[MCP-SEP-2817]
Model Context Protocol Project, "SEP-2817: AI Invocation
Audit Context in Request _meta", specification enhancement
proposal, open, 2026,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/pull/2817>.
[MCP-SEP-2828]
Model Context Protocol Project, "SEP: Server-Side Signed
Execution Record for MCP Tool Calls", specification
enhancement proposal, withdrawn by its author 18 July
2026, 2026, <https://github.com/modelcontextprotocol/
modelcontextprotocol/pull/2828>.
Pidlisnyi Expires 1 April 2027 [Page 216]
Internet-Draft APS September 2026
[MCP-SEP-3004]
Model Context Protocol Project, "SEP-3004: Tamper-Evident
Audit Record Contract", specification enhancement
proposal, closed 22 September 2026, 2026,
<https://github.com/modelcontextprotocol/
modelcontextprotocol/pull/3004>.
[AUTHZEN] Gazitt, O., Brossard, D., and A. Tulshibagwale,
"Authorization API 1.0", OpenID AuthZEN, Final, January
2026, <https://openid.net/specs/authorization-api-
1_0-final.html>.
[COSAI-149]
Coalition for Secure AI, Workstream 4, "Agent Manifest: a
signed, pre-execution declaration layer for agentic
systems", proposal, open, July 2026, <https://github.com/
cosai-oasis/ws4-secure-design-agentic-systems/issues/149>.
[COSAI-189]
Coalition for Secure AI, Workstream 4, "Evidence
sufficiency, and what a verifier may conclude when
evidence is absent", proposal, open, September 2026,
<https://github.com/cosai-oasis/ws4-secure-design-agentic-
systems/issues/189>.
[COSAI-205]
Coalition for Secure AI, Workstream 4, "Define
Decommissioning as an ADLC Phase and CoSAI Risk Map
Stage", proposal, open, September 2026,
<https://github.com/cosai-oasis/ws4-secure-design-agentic-
systems/issues/205>.
[IETF-WIMSE-CHARTER]
IETF, "Workload Identity in Multi System Environments
(wimse) Working Group Charter", March 2026,
<https://datatracker.ietf.org/doc/charter-ietf-wimse/>.
[IETF-DAWN-CHARTER]
IETF, "Discovery of Agents With Names (dawn) Proposed
Working Group Charter", September 2026,
<https://datatracker.ietf.org/doc/charter-ietf-dawn/>.
[IETF-AGENTPROTO-CHARTER]
IETF, "Agent Communication Protocols (agentproto) Proposed
Working Group Charter", September 2026,
<https://datatracker.ietf.org/doc/charter-ietf-
agentproto/>.
Pidlisnyi Expires 1 April 2027 [Page 217]
Internet-Draft APS September 2026
[APS-LIFECYCLE]
Pidlisnyi, T., "Authority Lifecycle for Long-Running AI
Agents", version 0.2.0-draft, commit
1e2bab7ccee3682a5dd40ccd59f8c87a4afc07e1, work by this
document's author, 2026, <https://github.com/aeoess/agent-
authority-lifecycle/
tree/1e2bab7ccee3682a5dd40ccd59f8c87a4afc07e1>.
[APS-CONFORMANCE]
Pidlisnyi, T., "APS Conformance Suite", merge commit
5829e2ff00d75f49ce21e9d87e756658deb1ef33, work by this
document's author, 2026, <https://github.com/Agent-
Authority-Conformance/aps-conformance-suite/
tree/5829e2ff00d75f49ce21e9d87e756658deb1ef33>.
Appendix A. Implementation Status
This section records the open-source implementations maintained by
this document's author, as of 24 September 2026. It is informative
and does not define APS conformance. The results below record
consistency among artifacts maintained by this document's author and
do not establish independent implementation or adoption. No
conformance run was performed for this revision beyond the one
recorded under Section 4.5.2.
What the lines below rest on. Every Implemented line in this
appendix, and every yes in the implementation columns of Appendix D,
comes from reading the sources of agent-passport-system 7.2.0 on npm
and agent-passport-system 4.2.0 on PyPI. No run backs any of them
except the authority-revocation-record run recorded under
Section 4.5.2. A vector named anywhere in this document under an
identifier that Appendix D marks specified and not exercised carries
no assertion keyed to that identifier, and is named because the
family reaches the same subject matter.
The releases described here are the TypeScript package "agent-
passport-system" 7.2.0 (npm), the Python package "agent-passport-
system" 4.2.0 (PyPI), the npm package "agent-passport-system-mcp"
6.1.0, and the Go repository at https://github.com/aeoess/agent-
passport-go at v0.7.0. The TypeScript and Python packages carry both
a pre-draft record line and a draft-native line, and only the draft-
native line implements the wire formats of Section 3.1, Section 3.3
and Section 4.1. The Go repository implements a subset centred on
canonicalization, action-reference computation, verification and,
since v0.7.0, issuance. The MCP package exposes protocol-layer
tools. The enforcement boundary described in Section 12 is a
separate deployment component and is not part of the published
packages. The description in that section was read from the Agent
Pidlisnyi Expires 1 April 2027 [Page 218]
Internet-Draft APS September 2026
Passport Gateway repository at https://github.com/aeoess/agent-
passport-gateway, at commit 05a6aac8f7261d1866316fe03bd91fe0613dfaf5
of 22 September 2026. No A2A binding is specified by this document,
and the released A2A adapter code is experimental.
The lifecycle modules of Section 8 ship in both packages as
experimental and opt-in surfaces: activation, bounds, capability-
binding, authority-state, chain-selection, lifecycle-state, status-
coverage and suspension. Opt-in means an application that does not
import them gets none of their behavior, and experimental means the
packages' own changelogs decline to promise their surfaces are
stable.
A.1. Implemented and Exercised
These mechanisms are implemented in the releases above and are
covered by those packages' own test suites.
* The passport of Section 3.1 and the principal binding of
Section 3.3, in the closed wire shapes those sections define.
* Per-key validity-window selection at the artifact's signed
issuance time, and the resolution outcomes of Section 3.5,
including the ambiguous outcome for a duplicated key identifier.
* AuthorityDelegationV1 of Section 4.1 with all seven facets inside
the signed content, and the component orders of Section 4.2.
* Phase-major chain verification of Section 4.3, including the
unrecognized-revocation-outcome rule and the root exemption from
the not_before rule, except for the timestamp behavior recorded
under the known deviations below.
* The revocation record format of Section 4.5.2. Both packages
issue and verify it. The authority-revocation-record family
reports 8 pass, 0 fail and 0 not_supported on each, asserting the
state, the valid flag and the full failure list including message
strings. That family is merged into the conformance suite at
commit 5829e2ff00d75f49ce21e9d87e756658deb1ef33. Both packages
also decide a record whose revoker member differs from the named
delegation's issuer as invalid under a revoker-not-issuer reason
code and refuse to issue one, which is APS-REC-REVOCATION-REVOKER-
IS-ISSUER. That behavior is implemented in both and no vector in
the family reaches it, so Appendix D marks the identifier
specified and not exercised. The subsection is a Candidate
feature because supporting this one format is not a requirement of
APS Core.
Pidlisnyi Expires 1 April 2027 [Page 219]
Internet-Draft APS September 2026
* Single-chain selection with no union across chains, which is the
only continuity rule of Section 8 whose module both packages ship
as stable rather than experimental.
* The action_ref of Section 5.1 and the external correlation form of
Section 5.2, exercised across the TypeScript, Python and Go
implementations with shared known-answer vectors.
* The ReceiptV1 envelope of Section 7.1, the identifier and
signature constructions of Section 7.2, and the three stages of
Section 7.3. Both packages accept the expected enforcement-
boundary identity as a verifier trust input and perform the
Section 7.6 step 4 comparison against the receipt issuer.
* The decision_ref of Section 7.4 over all five component
references, and the receipt-to-decision binding and its temporal
relation, which the receipt-decision-relation family exercises
over seven vectors.
* The strict RFC 8785 [RFC8785] canonicalization, checked in
continuous integration for byte-identical output against
independent RFC 8785 implementations.
A conformance fixture set is published at https://github.com/Agent-
Authority-Conformance/aps-conformance-suite. Current versions and
results are maintained at https://github.com/aeoess/agent-passport-
system.
A.2. Specified but Not Implemented
The following mechanisms are specified by this document and
implemented by no released package. The mechanism list is followed
by the identifier list generated from the implementation columns of
Appendix D, which is exhaustive for identified requirements and is
the authority where the two disagree.
* The consumption of a permit or narrow policy-decision record as a
single-use approval, at Section 5.3. The released verification
path checks the envelope, the stage, the predecessor and the
decision binding, and does not consume a receipt_id or hold
single-use state. The enforcement boundary that would consume it
is not a published package, which is also why the reservation and
settlement ledger of Section 4.4 and Section 5 is absent.
* The not_attempted value of Section 7.5. No released package
reports that value on the evidence-resolution axis.
Pidlisnyi Expires 1 April 2027 [Page 220]
Internet-Draft APS September 2026
* Evaluation of a relying party's trust-policy pin at the artifact's
issued_at, at Section 3.5. The released trust-policy path
evaluates a pin's validity window and its rotation overlap against
verification time.
* Cascade-derived records and cascade-completion records, at
Section 4.5.1. Neither is issued nor verified by any released
package, and Section 4.5.2 defines neither.
* The mediation-assumption rule of Section 2.5. No released package
checks that a governed path was the only path.
* Every requirement of Section 9 except the receipt-to-decision
binding and its temporal relation. The interop record the section
cites carries its own harness and is not a released package.
* The profile model of Section 6. No released package implements a
profile document, a profile registry, or profile-context passing,
and no fixture exists for a requirement on a profile document.
* The adapter contracts of Section 11.4, beyond the action-reference
recomputation both packages already perform.
* The conformance reporting of Section 13. No released package
emits a per-vector result record, and no machine-readable claim
format is defined.
* Inside Section 8: the cached-decision limits of Section 8.3.6, the
policy-version limb of Section 8.3.3, the binding mode, office-
holder records, vacancy records, co-holder decision rules and pre-
commitment of Section 8.3.7, and the principal-event records,
confirmation procedures, renunciation and accountability findings
of Section 8.3.8. The identifier custodian records of
Section 8.3.3 are evaluated and are not on this list: the released
capability-binding module evaluates custodian binding and
retention records supplied to it and resolves custodian standing
through caller-supplied resolvers, and it issues and signs no such
record. Production of those records is implemented by no released
package.
Identifier list. Appendix D marks 49 of its 99 identifiers no in
both implementation columns, meaning neither agent-passport-system
7.2.0 on npm nor agent-passport-system 4.2.0 on PyPI has a surface
that implements the requirement, read from source. A no in both
columns is not a statement that the requirement is wrong or
unreachable, only that no released package carries it. They are:
Pidlisnyi Expires 1 April 2027 [Page 221]
Internet-Draft APS September 2026
APS-EVID-NO-RETROACTIVE-REWRITE, APS-EVID-DIGEST-MISMATCH-NOT-
ESTABLISHED, APS-ENF-NO-ABSENCE-INFERENCE, APS-PROF-REQUIRED-CONTENT,
APS-PROF-SEMANTIC-PRESERVATION, APS-PROF-NO-WIDENING, APS-PROF-
UNKNOWN-NOT-VALID, APS-LC-ISSUER-VS-LIFECYCLE-STANDING, APS-LC-
SUCCESSOR-NO-INHERITANCE, APS-LC-RECHECK-AT-ADMISSION, APS-LC-CACHED-
DECISION-FRESHNESS, APS-LC-UNKNOWN-DENIAL-SAYS-NOT-ESTABLISHED, APS-
LC-COMPLETENESS-BASIS, APS-LC-POLICY-VERSION-IDENTIFIED, APS-LC-
POLICY-TIGHTENING-RESTRICTS, APS-LC-EPOCH-FEATURE-DEFINITION, APS-LC-
OFFLINE-DECLARED-IN-ADVANCE, APS-LC-BINDING-MODE-NO-DEFAULT, APS-LC-
VACANCY-NOT-ESTABLISHED, APS-PRIN-TWO-FINDINGS, APS-PRIN-ROLE-NOT-
FROM-BODY, APS-PRIN-SILENCE-NOT-CONSENT, APS-PRIN-ACCOUNTABILITY-
SEPARATE, APS-EVID-RELATIONS-NOT-TRANSITIVE, APS-ENF-EXACT-ACTION-
MATCH, APS-ENF-NO-COVERAGE-NO-BYPASS-CLAIM, APS-ENF-COVERAGE-PREMISE-
SCOPED, APS-ENF-COVERAGE-RESOLVES-TO-ADMISSION, APS-EVID-EFFECT-NOT-
FROM-RESULT, APS-EVID-READBACK-OUTCOMES, APS-EVID-MISSING-NAMED, APS-
EVID-STATES-NOT-SYNONYMS, APS-ENF-RETRY-NEW-DECISION, APS-ENF-
COMPENSATION-NEW-RECORD, APS-ENF-RESERVE-AT-APPROVAL, APS-ENF-
COMPLETE-AT-ADMISSION, APS-ENF-SETTLE-AFTER-RESULT, APS-ENF-RELEASE-
PRE-DISPATCH-ONLY, APS-ENF-CONFLICTING-REUSE-REJECTED, APS-ADAPT-NO-
WIDENING, APS-ADAPT-NO-SILENT-SEMANTIC-LOSS, APS-ADAPT-STAGE-
COMMITMENT, APS-ADAPT-CANONICALIZATION-STATED, APS-ADAPT-MCP-
EXTENSION-DECLARED, APS-CONF-CLASS-NAMED, APS-CONF-CLAIM-CONTENT,
APS-CONF-CLAIM-NOT-VERDICT, APS-CONF-THREE-RESULTS, APS-CONF-NOT-
SUPPORTED-NOT-SCORE.
The remaining identifiers are marked yes in at least one column and
are outside this subsection. Where a mechanism named above covers an
identifier not on this list, the mechanism is partly implemented and
the implementation columns say which part.
A.3. Implementation-Specific Behavior
The following items are implementation choices where this document
leaves a construction to a profile or to a deployment.
* The record types named in Section 8 under the proposed: namespace.
The released packages ship them under that prefix in their
experimental modules. This document fixes no wire name for any of
them, no fixture family mints a record under any of them, and a
later revision may change any of them.
* The authority-epoch marker the authority-state module carries. It
is unsigned, it is not a wire field, and the module supports
neither durability nor concurrency. This document defines no
epoch wire field, and Section 8.3.4 turns the open design choices
into obligations on an implementation that claims the feature.
Pidlisnyi Expires 1 April 2027 [Page 222]
Internet-Draft APS September 2026
* The reason_code value space of Section 4.5.1 and Section 4.5.2, on
which neither section imposes a grammar, and the
verification_method field, which Section 4.5.1 does not name. The
releases constrain neither.
* The target string construction Section 5.1 requires a profile to
define.
* The TypeScript Revocation-Observation emitter computes its
signature over the project's legacy canonicalization rather than
the RFC 8785 profile specified in this document, and verifiers of
that record validate over the same form. The two
canonicalizations differ only in the treatment of null-valued
object members, which the legacy form omits. The record as
emitted carries no null-valued members, so its signed bytes
coincide with RFC 8785 for that record. The Evidence-Bundle
supporting-record emitter uses the RFC 8785 profile. Revocation-
Observation is not a record this document specifies.
A.4. Known Deviations
* The released delegation, receipt-core and action-reference
surfaces admit the second value 60 as 23:59:60 on the last
calendar day of a month. Section 4.3 rejects the second value 60
wherever it appears. The passport and principal-binding surface
rejects it. The revocation record surface of Section 4.5.2 states
a second value of 00 through 59 and no authority-revocation-record
vector carries a second value of 60, so its behavior on that value
is not established either way.
* The capability-binding-drift and lifecycle-identifier-reuse-and-
rename families label an established pinned-referent mismatch as
not established, in a verdict set with no denial member.
Section 8.3.3 specifies a denial with a mismatch reason, and both
released packages decide the denial. A family run that reproduces
the earlier labelling is reproducing that family's own vocabulary
and is not deciding the rule.
* The actionref-canonical family's README states four vectors and
its fixture file carries six, the two extra being duplicate-scope
negatives, one raw and one colliding only after normalization.
The count used throughout this document is six, which is the file.
* The conformance suite pins agent-passport-system 7.1.0 in its own
manifest at the commit this document cites. The package sources
read for this document are 7.2.0 on npm and 4.2.0 on PyPI, so a
result the suite records against its pinned package ran a version
one minor release behind those sources. The authority-revocation-
Pidlisnyi Expires 1 April 2027 [Page 223]
Internet-Draft APS September 2026
record run reported under Section 4.5.2 is the exception: it ran
against clean installs of agent-passport-system 7.2.0 from npm and
agent-passport-system 4.2.0 from PyPI, overriding the suite's
7.1.0 pin, and a separate run against the pinned 7.1.0 was
recorded alongside it.
Appendix B. Changes from -03
This section is informative. It summarizes the principal changes
between draft-pidlisnyi-aps-03 and this revision. It is a history
and not a specification, and where it disagrees with a section of
this document the section governs.
The comprehensive integration did not rewrite the stabilized core
beyond the -04 repairs summarized in Appendix B.2 and the edits
logged under ruling R-A. The carried sections are Section 1,
Section 3, Section 4, Section 5, Section 7, Section 11 and
Section 14, which carry the -03 rules as revised below. Section 2
and Section 6 sit inside that range and are new. Every literal
cross-reference in that text was converted to a cross-reference by
anchor, because this revision renumbers the document. The R-A edits
are two. In Section 3.1, "principal authority is carried by the
separate record" became "the principal relationship is carried by the
separate record", because a binding is not a grant. In Section 15,
"outside the protocol guarantees" became "outside what this document
specifies".
B.1. New Sections
* Section 2, Authority and Verification Model, is new and sits
before any wire format. It names the nine actors, states seven
distinctions the rest of the document enforces, fixes the closed
set of six artifact verdicts and the three boundary outcomes,
states what evidence establishes and what it does not, names the
mediation assumption as load bearing, and carries the transition
contract the whole document is written against.
* Section 4.5.2 is new. It specifies one wire format for the
revocation record that Section 4.5.1 has required since -03
without defining. It is a Candidate feature, not a change to the
SHOULD above it.
* Section 6, Profile Model, is new. It states what a profile
document identifies, including the loss value that applies to each
APS semantic it touches, and collects the extension points at
which this document defers a construction.
Pidlisnyi Expires 1 April 2027 [Page 224]
Internet-Draft APS September 2026
* Section 8, Authority Lifecycle, is new. It has four parts:
concepts, twelve authority continuity rules, eight lifecycle
mechanisms, and candidate extensions. Six of the twelve
continuity rules restate a requirement of the closed core, one
identifier each, and those six identifiers are the enumerated
Lifecycle Core set. Everything else in it is a Candidate feature.
* Section 9, Decision to Effect, is new. It separates five
questions a deployment routinely answers as one, states the four
non-transitive relations between a decision and an effect, and
states the reservation and retry contract the closed core already
holds across four of its sections.
* Section 10 replaces the -03 Institutional Governance section. The
-03 text described an organization's structures. This revision
describes how they reach the delegation layer, as charter, office,
holder, root authority basis, delegation and action, and states
that no family exercises the projection.
* Section 12, the enforcement gateway reference architecture, is new
and informative. It describes one arrangement taken from the
open-source gateway and separates what that implementation does
from what this document requires.
* Section 13, Conformance, is new. It defines seven conformance
classes, the form of a claim, and the three results an
implementation reports per vector.
* Section 19, Limits and Open Questions, is new. It separates five
limits of the protocol from fifteen open design questions, each
with what is unresolved, why the evidence does not settle it, what
this document requires until it is, and whether it touches Core or
a Candidate feature. Two further items are held out of this
revision by ruling and four designs are recorded as under
consideration.
* Section 11.4, Section 11.5 and Section 11.6 are new subsections of
Protocol Bindings. Section 14.1 is a new subsection of Related
Work.
* Appendix C and Appendix D are new appendices. The first is the
provenance index from each rule to its hardest adversarial case.
The second records every requirement identifier of this revision
with the vectors that exercise it.
B.2. Changes Carried From -03
Pidlisnyi Expires 1 April 2027 [Page 225]
Internet-Draft APS September 2026
* Result model. Section 7.3 makes the expected enforcement-boundary
identity a trust input the verifier supplies. Section 7.6 adds a
boundary-identity comparison to step 4 of its order. This changes
the conditions under which a receipt reaches valid, because a
verifier given no expected boundary identity reports that axis as
not established. Section 7.6 now states that an axis a verifier
did not establish never contributes to a valid result, and
Section 7.5 now states that omitting the evidence-resolution axis
is not a permitted verifier scope while declining to resolve
evidence is.
* Root trust. Section 4.3 now states the chain result for a root
the verifier's trust policy does not accept: invalid, with a root-
trust reason at the root's index. -03 left the result for an
untrusted root unsaid.
* Cascade. The -03 requirement that a revocation MUST initiate a
cascade to all transitive descendants is now a MAY to produce
cascade evidence. Descendant invalidity follows from the
Section 4.3 revocation check applied to every chain member.
* Revocation record. The -03 requirement that a revocation MUST
produce a signed revocation record is now a SHOULD, in a format
the applicable profile defines. The four minimum content elements
are unchanged. This revision adds one such format at
Section 4.5.2, which satisfies the SHOULD without narrowing it.
* Reservation identity. A reservation is keyed by action_ref. A
request matching an unsettled and uncancelled footprint is an
idempotent retry, and a request under the same action_ref whose
unit, amount or bounded ancestor set differs is conflicting reuse
and is rejected. Section 9.8 reads that rule together with the
three other core sections that bear on it.
* Leap second. A timestamp carries a second value from 00 through
59 in every section, and a verifier rejects the second value 60
wherever it appears. This is narrower than RFC 3339.
* Key-resolution outcome names. The five failure outcomes of
Section 3.5 carry stable names. The resolved outcome carries no
failure name, and this document defines no further key-resolution
outcome. Section 4.3 no longer promises a stable failure code for
chain verification, because this revision defines no failure-code
vocabulary for it.
* not_before. The rule that a record's not_before MUST NOT predate
its issued_at is scoped to a member whose parent_delegation_id is
not null. A root MAY take effect before its own issued_at.
Pidlisnyi Expires 1 April 2027 [Page 226]
Internet-Draft APS September 2026
* Ceiling rule. An implementation ceiling reached while parsing or
verifying is indeterminate with a reason naming the limit, not
invalid. A syntax violation observed before any ceiling is
reached remains invalid.
* Approval artifact. The -03 sentence permitting a profile to
define a further approval artifact bound to the same action_ref
was removed. The permit or narrow policy-decision record of
Section 7.3.2 identifies the consumable approval.
* Historical key selection. Section 3.4 extends the evidence
requirement to any historical key-selection boundary, including a
relying party's trust-policy pin, with the ambiguous outcome as
the result without such evidence.
* Approval-state axis. Section 7.6 step 10 reports an approval-
state axis, not established where the verifier holds no
consumption state.
* Unit equality. Section 5 states that a unit is an opaque non-
empty string, that two units are the same unit when their UTF-8
byte sequences are equal, and that an implementation neither
rejects a unit for failing a grammar this document does not state
nor treats two unequal unit strings as one unit. -03 stated no
equality rule.
* Revocation record scope. Section 4.5.1 now states that this
document defines no wire encoding, identifier construction,
signature construction, reason-code vocabulary or signer rule for
the revocation record it asks for. -03 stated the four minimum
content elements and left the rest unsaid.
* Invariant citations. Section 4.6 now states that INV-4 is
reported as the evidence cascade state of Section 4.5 and is not
an input to the authority result, where -03 said a cascade-
completion record made INV-4 verifiable from records. The names
of INV-2, Scope Monotonic Narrowing, and INV-3, Spend Limit
Narrowing, and the issuance-time enforcement that section places
on them and on INV-8, are unchanged from -03. Section 4.5.2 cites
INV-5 where it states that a party does not replace a record it
already holds.
* Title. The -03 title was "Agent Passport System (APS): Verifiable
Agent Identity, Faceted Authority, and Signed Action Receipts".
This revision is titled "Agent Passport System (APS): Verifiable
Authority, Lifecycle, Enforcement, and Evidence for AI Agents",
because authority and its lifecycle are what the document is
organized around and receipts are one mechanism inside that.
Pidlisnyi Expires 1 April 2027 [Page 227]
Internet-Draft APS September 2026
B.3. Conventions Introduced by This Revision
* Every normative subsection outside the closed core carries a
status block: Core, or a named Candidate feature, with the fixture
families that exercise it and the released packages that implement
it.
* Requirements outside the closed core carry stable semantic
identifiers of the form APS-AREA-NAME, listed in Appendix D. An
identifier never changes because a section moves and is never
reused.
* A requirement is recorded as exercised only where a named vector
carries an assertion that fails when the requirement is violated.
Everything else is recorded as specified and not exercised.
* Record types belonging to a Candidate feature stay in the
proposed: namespace. One name graduates in this revision,
aps:authority-revocation:v1, because its semantics are fixed for
that record_type and version, its wire shape is specified, a
family exercises it against independent negatives, and both
reference implementations map to it.
Appendix C. Case and Rule Provenance Index
This appendix is informative. It is the provenance index for the
lifecycle material in this document. It has two parts: an index from
each rule to the case that is the hardest adversarial instance of it,
and eighteen cases given in full. The corpus itself stays where it
is maintained, in [APS-LIFECYCLE], pinned at the commit that
reference names, and this appendix reproduces no full listing of it.
How the sources are used. The cases are drawn from law, corporate
governance, aviation, medicine, banking, insolvency, government
succession, military command, distributed systems, cryptographic
infrastructure and published security incidents. Every one of those
sources is used as a source of a case shape or of a counterexample.
None of them says anything about AI agents. Nothing in this appendix
states that a legal doctrine, a statute, a regulation or an
institutional rule applies to an AI agent, and no such reading is
intended or supported. A precedent here answers the question "what
shapes does authority actually take", not the question "what rule
governs an agent".
Status values. "verified" means the case has a source that was
fetched and quoted. "reviewed hypothetical" means the case was
written and reviewed with no external precedent claimed. "candidate"
means the case names a gap and is held as a candidate rather than a
Pidlisnyi Expires 1 April 2027 [Page 228]
Internet-Draft APS September 2026
settled shape. "boundary" means the case is sound and resolves to
something other than an authority state a verifier returns from
records, which is why it is listed separately. A status is a
statement about the case, not about any implementation.
Family names are the fixture families of the conformance suite
[APS-CONFORMANCE]. Naming a family records that vectors for that
shape exist. It is not a conformance result and not a claim that any
implementation passes them.
What this appendix does not establish. It does not establish that
the corpus is complete, that the cases are independent of each other,
or that any case has been tested. It does not establish that this
document specifies a rule for every case listed, and several cases
exist precisely because it does not.
C.1. Rule and Case Provenance Index
Each entry names one rule of this document, the case that is the
hardest adversarial instance of it found in the corpus, the fixture
families that carry cases of that shape, and the status of the
canonical case. Status values are those defined above. Where the
canonical case is given in full below, the entry says so.
L1, an ancestor revocation reaches what depends on it
Canonical adversarial case LC-C-006, an ancestor found never to
have been valid rather than revoked, given in full below,
verified. Families: lifecycle-multiple-principals-and-conflict,
ancestor-revocation-chain.
L2, identity continuity is not authority continuity
Canonical adversarial case LC-B-008, authority ending through an
external fact with no artifact in the delegation graph, given in
full below, verified. Families: lifecycle-legal-regulatory-
events, sponsor-handover.
L3 and L4, succession creates new authority and inherits no tree
Canonical adversarial case LC-A-016, replacement authority pre-
committed inside the original instrument, given in full below,
verified. Families: lifecycle-principal-events, lifecycle-root-
authority-succession, lifecycle-fiduciary-succession.
L5, independent chains are not combined
Canonical adversarial case LC-C-012, two independently rooted
chains coordinating on one objective, given in full below,
verified. Families: lifecycle-multiple-principals-and-conflict,
chain-selection-no-union, single-chain-selection.
Pidlisnyi Expires 1 April 2027 [Page 229]
Internet-Draft APS September 2026
L6, an earlier approval is not current authority
Canonical adversarial case LC-B-029, a receiving institution's
acceptance as a boundary a later change does not reach, given in
full below, verified. Families: lifecycle-organization-events,
cached-authorization-revocation.
L7, unknown revocation state is not active
Canonical adversarial case LC-F-018, regional enforcement points
briefly disagreeing, given in full below, verified. Families:
lifecycle-infrastructure-failure, revocation-resolution-forward-
compat, conflicting-status-sources.
L8, suspension is not revocation
Canonical adversarial case LC-C-022, a pending-ratification state
that is neither revoked nor not revoked, given in full below,
verified. Families: lifecycle-multiple-principals-and-conflict,
suspension-cause-composition.
L9, key rotation is not delegation revocation
Canonical adversarial case LC-D-013, key custody narrowed to a few
named holders and defeated by one unmanaged device, verified.
Families: lifecycle-credential-events, key-rotation-historical.
This case is a boundary case for the authority model and is
carried in the corpus rather than in full here.
L10, expiry is not revocation
Canonical adversarial case LC-A-001, authority ending at a factual
moment under a notice-effective rule, given in full below,
verified. Families: lifecycle-principal-events, lifecycle-expiry-
and-renewal, lifecycle-purpose-exhaustion.
L11, no silent authority resurrection
Canonical adversarial case LC-E-023, a faithfully restored process
holding authority that may no longer be current, verified.
Families: lifecycle-infrastructure-failure, authority-epoch-
rollback, chain-selection-no-union.
L12, completeness is a separate and stronger claim
Canonical adversarial case LC-F-027, an empty audit window as
delivery lag rather than absence, given in full below, verified.
Families: lifecycle-infrastructure-failure, lifecycle-evidence-
and-record. Second canonical case LC-D-025, completeness of what
a still-valid grant was used for, also given in full below.
Pidlisnyi Expires 1 April 2027 [Page 230]
Internet-Draft APS September 2026
Activation conditions
Canonical adversarial case LC-C-008, a missing successor
designation resolving to a named default rather than failing
closed, given in full below, verified. Families: lifecycle-time-
and-scheduling, activation-not-established.
Purpose bounds and exhaustion
Canonical adversarial case LC-A-008, purpose exhaustion ending
authority once an authenticated record shows the purpose was met
rather than once the agent decides it was, verified. Families:
lifecycle-principal-events, lifecycle-purpose-exhaustion.
Capability binding and policy version
Canonical adversarial case LC-E-033, a provider-side capability
upgrade with no delegation-layer event, verified. Families:
lifecycle-agent-side-events, capability-binding-drift, lifecycle-
policy-change. Second canonical case LC-E-002, a valid grant
whose named executor is gone, given in full below.
Authority epoch and fencing
Canonical adversarial case LC-F-016, a storage-layer partition
resurrecting revoked authority below the application layer,
verified. Families: lifecycle-infrastructure-failure, authority-
epoch-rollback.
Suspension, cause sets and release
Canonical adversarial case LC-B-024, independent suspensions
released independently, given in full below, verified. Families:
lifecycle-legal-regulatory-events, suspension-cause-composition.
Status sources, freshness and coverage
Canonical adversarial case LC-F-017, a revocation true at the
source and false at a lagging replica, verified. Families:
lifecycle-infrastructure-failure, conflicting-status-sources,
cached-authorization-revocation.
Succession, handover and reauthorization
Canonical adversarial case LC-C-014, a handover gated on the
incoming holder's acknowledgment, given in full below, verified.
Families: lifecycle-time-and-scheduling, sponsor-handover,
lifecycle-organization-events.
Principals, identities and departure
Canonical adversarial case LC-B-026, a third party injecting an
approval gate into an unmodified valid chain, given in full below,
verified. Families: lifecycle-legal-regulatory-events, lifecycle-
principal-events, lifecycle-principal-unreachable.
Pidlisnyi Expires 1 April 2027 [Page 231]
Internet-Draft APS September 2026
Conferral of a held scope
Canonical adversarial case LC-E-006, a scope handed to a spawned
process, given in full below, verified. Families: lifecycle-
agent-side-events, lifecycle-conferral-without-authority. This
rule is an open question at Section 19.2.13 rather than a rule of
this document.
Work in flight
Canonical adversarial case LC-E-013, invalidation arriving mid-run
rather than at the next gateway check, given in full below,
verified. Families: lifecycle-agent-side-events, lifecycle-
organization-events, lifecycle-time-and-scheduling. This is an
open question at Section 19.2.2.
The queued-action shape
Canonical adversarial case LC-E-034, a queued action outlasting a
suspension, given in full below, reviewed hypothetical. Families:
lifecycle-time-and-scheduling, suspension-cause-composition.
Principal-to-authority association
Canonical adversarial case LC-D-004, a compromised operator
identity acting as an implicit ancestor over many independent
trees, verified. Families: lifecycle-credential-events,
lifecycle-identifier-reuse-and-rename. This is an open question
at Section 19.2.10 and no family binds a principal reference
across a decision and an admission.
What this index does not establish. It does not establish that the
canonical case named for a rule is the only adversarial case for it,
that the families named exercise the rule at the level this document
states it, or that a rule with a canonical case is better covered
than a rule without one. Coverage is recorded in Appendix D and
nowhere else.
C.2. Eighteen Cases in Full
Twelve of these are the cases the lifecycle document and its
candidate statements cite most. Nine of the twelve are cited eight
times or more across those two documents, and the other three are
cited seven times and are also used by the worked examples in
Section 9.11. The remaining six are the cases the worked examples
and the open questions of this document turn on directly.
Each case carries five fields. Situation is what happened.
Authority question is what a verifier has to answer. Rule exercised
names the rule in this document the case bears on. Disposition in
this document says what this revision does with the case, and every
case carries one. What the rule does not establish is the boundary
Pidlisnyi Expires 1 April 2027 [Page 232]
Internet-Draft APS September 2026
of that rule. Two further lines are kept where they exist: the
source the case was drawn from, and the failure a naive
implementation reaches, which is what makes the case adversarial
rather than illustrative.
Where the corpus recorded a proposed outcome, that line is kept as
the pressure the case puts on an authority model and not as a rule.
A case from another domain is a source of the question and never a
source of the rule, and the disposition line is where this document
answers.
*LC-C-008. A missing successor designation should fail open to a
named statutory fallback, not fail closed like an unknown revocation*
Status verified. Family lifecycle-time-and-scheduling. Domain
government.
Situation. A role becomes vacant and the organization never issued
an explicit order naming who acts in the meantime. A verifier
looking for a successor designation finds none recorded.
Source. The Federal Vacancies Reform Act's default rule that the
first assistant to a vacant Senate-confirmed office automatically
becomes the acting officer, subject to a prior-service requirement
and disqualification if the President has nominated that person. US
Government Accountability Office, GAO-02-272R
(https://www.gao.gov/products/gao-02-272r): "the first assistant to
the office of such officer shall perform the functions and duties of
the office temporarily in an acting capacity."
Authority question. Does an unrecorded successor designation leave
the office authority not established, or does the authority model
supply a named default that the verifier must apply?
Pressure this case puts on an authority model. A model that treats
every unknown the same way answers this one badly. The corpus
records that the domain solved it with a named default holder,
resolved outside the record and checkable against its own eligibility
conditions, which puts the question of whether an authority model can
carry a pre-committed default at all.
What a naive implementation gets wrong. A framework modeled only on
L7's fail-closed rule for unknown revocation state will wrongly fail
closed here too, and block a routine, lawful vacancy that the statute
already solved with an affirmative default.
Pidlisnyi Expires 1 April 2027 [Page 233]
Internet-Draft APS September 2026
Rule exercised. Invariants L7. L7 is about an unknown or stale
revocation answer, which fails closed. An unknown successor
designation is a different unknown, and in the source domain it
resolves to a named fallback holder with its own eligibility gate
rather than to a refusal. The two unknowns are not one.
Disposition in this document. A statutory fallback is a pre-
committed instrument in the sense of Section 8.3.7, and this document
defines no such instrument and no default holder. Without one the
vacancy is not established, with the coverage limb named, and a
verifier supplies no default in either direction.
What the rule does not establish. It does not establish that a named
default holder exists in any deployment, and it does not establish
which unknowns should resolve to a default. It establishes that an
unknown successor designation and an unknown revocation answer are
two different unknowns.
*LC-C-006. A tainted ancestor invalidates dependents only from the
moment the taint is found, not retroactively*
Status verified. Family lifecycle-multiple-principals-and-conflict.
Domain government.
Situation. A chain of appointments rests on a person's authority to
make them. Eighteen months later, an independent investigator finds
that person's own appointment was never valid, not revoked, never
valid in the first place, and by then the downstream appointees have
signed many orders that already took effect.
Source. The GAO's August 2020 finding that DHS acting secretary Chad
Wolf's and acting deputy secretary Ken Cuccinelli's appointments were
invalid, because Kevin McAleenan, who named them, had himself been
installed outside the statutory order of succession and had no
authority to amend that order. GAO finding, reported by GovExec
(https://www.govexec.com/management/2020/08/top-two-homeland-
security-officials-are-serving-illegally-gao-rules/167714/):
"McAleenan's subsequent appointments of Wolf and Cuccinelli were
therefore invalid, GAO said, as he was not eligible to make them."
Authority question. What does a verifier report about an ancestor
established to have been invalid from issuance rather than revoked,
and about the decisions taken while it looked valid?
Pidlisnyi Expires 1 April 2027 [Page 234]
Internet-Draft APS September 2026
Pressure this case puts on an authority model. An ancestor invalid
from issuance and discovered late is not a revocation event, and a
model with only a revocation event has nothing to record. The corpus
also separates what a finding does going forward from what it does to
effects already taken, which the finding itself does not answer.
What a naive implementation gets wrong. A revocation-only model
finds nothing wrong here, because no one ever revoked anything. It
has no way to represent "this grant was void from issuance"
discovered after the fact, and no way to backdate that discovery
without either pretending nothing happened or silently erasing
evidence of effects already taken.
Rule exercised. Invariants L1, L12. Open question: work in flight.
L1 (revoking an ancestor invalidates dependents) assumes the ancestor
was once valid and was later revoked. This case is the harder one L1
does not cover, an ancestor invalid from the start, discovered long
after the fact. Also touches the "work in flight" open question and
L12 (completeness), since the orders executed under the tainted chain
are exactly the evidence a completeness claim needs to account for.
Disposition in this document. Void from issuance is the artifact
verdict invalid, carrying its own reason code and separated from
revoked by that code, under Section 2.3. The finding reaches the
chain from the moment a verifier establishes it. What becomes of
effects already taken is a different question, open at
Section 19.2.2.
What the rule does not establish. It does not establish what becomes
of effects already taken under the chain while the chain looked
valid, and it does not establish a moment at which the invalidity
began for a relying party.
*LC-F-018. Multiple regional enforcement points are physically
distinct copies of authority state, and can briefly disagree*
Status verified. Family lifecycle-infrastructure-failure. Domain
distributed-systems.
Situation. An APS deployment runs multiple regional gateways sharing
a globally-replicated authority store. A principal revokes a
delegation. The gateway in the same region as the write enforces the
revocation immediately. A gateway in a different region still serves
the pre-revocation decision for some seconds to minutes.
Source. AWS documents IAM's own distributed, eventually-consistent
propagation path. AWS IAM troubleshooting guide
(https://docs.aws.amazon.com/IAM/latest/UserGuide/
Pidlisnyi Expires 1 April 2027 [Page 235]
Internet-Draft APS September 2026
troubleshoot_general.html): "Any changes that you make in IAM (or
other AWS services)... take time to become visible from all possible
endpoints. Some delay results from the time it takes to send data
from server to server, replication zone to replication zone, and
Region to Region."
Authority question. When two enforcement points hold separate copies
of authority state and disagree, which answer does a verifier treat
as the state of the authority?
Pressure this case puts on an authority model. A deployment with
more than one enforcement point holds more than one copy of authority
state, so a model has to say what a lagging copy does to an answer
and what an answer outside any declared bound is worth. The corpus
records propagation lag as a bound a deployment declares and tests,
and the case is what forces the question rather than the answer to
it.
What a naive implementation gets wrong. Assuming a single "the"
authority store with one true current state, when a multi-region
deployment has physically distinct copies that can each individually
be asked whether something is revoked and briefly disagree.
Rule exercised. Invariants L7. None of L1-L12 model multiple
enforcement points each holding their own view of a replicated
authority store. The L7 shape, "the authority is unreachable,"
doesn't capture "reachable but behind."
Disposition in this document. A result is what one verifier
established from the sources it read at one moment. Section 8.3.6
makes freshness and coverage properties of the source rather than of
the authority, and Section 4.3 makes a stale or unavailable
revocation answer indeterminate and never active. This document
states no propagation bound.
What the rule does not establish. It does not establish a
propagation bound for any deployment. It establishes that a
deployment with more than one enforcement point holds more than one
copy of authority state.
*LC-C-022. A pending-ratification state is neither "revoked" nor
"not revoked," and if ratification is denied, the record has to say
the action was provisional throughout, not that a final revocation
was later reversed*
Status verified. Family lifecycle-multiple-principals-and-conflict.
Domain military.
Pidlisnyi Expires 1 April 2027 [Page 236]
Internet-Draft APS September 2026
Situation. A commander relieves a subordinate of command. The
required written approval from a higher general officer has not yet
arrived. Until it does, the relief has a lesser, provisional effect.
If the approval never comes, the action is retroactively
recharacterized as having only ever been the lesser effect, not
undone from a final state.
Source. US Army relief-for-cause procedure. Fort Carson command
policy memo, quoting AR 600-20
(https://home.army.mil/carson/6116/5089/9699/relief-for-cause.pdf):
"Any commander may temporarily suspend a subordinate from command,
but the final action to relieve an officer from any command position
will not be taken until after written approval by the first general
officer in the chain of command."
Authority question. How does a verifier report a change that has
been initiated, has partial effect, and becomes final only on a
separate approval that may never arrive?
Pressure this case puts on an authority model. A change that has
partial effect and becomes final only on a separate approval fits
neither revoked nor not revoked. The corpus records the domain
treating the interval as provisional throughout, so a model that only
has a final state has to recharacterize the earlier record
afterwards, which is the move this document does not allow.
What a naive implementation gets wrong. Conflating this with an
ordinary self-declared, self-terminated suspension. This is a
different shape, an external, unilateral suspension by a superior
that only becomes a final revocation with a specific separate
approval. Treating the two the same either finalizes a revocation
that legally never became final, or fails to suspend the subordinate
while waiting on paperwork.
Rule exercised. Invariants L8. Open question: release from
suspension. Adds a ratification-pending intermediate state with
retroactive recharacterization on denial, a shape not present in L8's
plain suspension and revocation split, and directly relevant to
release from suspension, Section 19.2.3.
Disposition in this document. A pending ratification is a suspension
cause under Section 8.3.5. Authority is inactive while the cause
stands, the cause is released only by a party with standing over it,
and a release creates no new authority. No verdict for a revocation
that is not yet final is defined here.
Pidlisnyi Expires 1 April 2027 [Page 237]
Internet-Draft APS September 2026
What the rule does not establish. It does not establish who may
ratify, and it does not establish how long a pending state may stand
before something else has to happen.
*LC-A-001. A principal's death ends actual authority regardless of
durability, effective on the agent's notice, not at the instant of
death*
Status verified. Family lifecycle-principal-events. Domain agency-
law.
Situation. A principal dies. An agent holding a delegation from
that principal, durable or not, keeps trying to act on the
principal's accounts. Nobody has processed a revocation record.
Source. Restatement (Third) of Agency §3.07: reproduced text,
staff.washington.edu (https://staff.washington.edu/djdrake/RESt-
Agency.doc): "The death of an individual principal terminates the
agent's actual authority. The termination is effective only when the
agent has notice of the principal's death." Durability does not
change this: Uniform Power of Attorney Act (2006) §110(a), as enacted
at N.H. RSA 564-E:110 (https://gc.nh.gov/rsa/html/
LVI/564-E/564-E-110.htm): a power of attorney terminates when "(1)
the principal dies; (2) the principal becomes incapacitated, if the
power of attorney is not durable."
Authority question. Does authority end at the event, or at the
moment the acting party has notice of it, and which of the two does a
verifier hold evidence for?
Pressure this case puts on an authority model. In the source domain
authority ends at the principal's death whatever the instrument says,
and takes effect for a party on that party's notice rather than at
the instant of the event. A model that records only a manual
revocation has no place for either the event or the notice, and
recording a transition and observing it are two events with two
times.
What a naive implementation gets wrong. A revoke-only system waits
for an explicit revocation record and misses that death is a self-
executing terminating event. A system can also over-read "durable"
as blanket death-immunity, when durability is scoped only to
surviving incapacity, not death. Every power of attorney, durable or
not, ends at death.
Pidlisnyi Expires 1 April 2027 [Page 238]
Internet-Draft APS September 2026
Rule exercised. Invariants L1, L10. L1, L10. Termination happens
at a factual moment (death) under a notice-effective rule, not an
ancestor-revocation record. The scope of "durable" (incapacity-
survival only, never death-survival) is a distinction no invariant
states, and a naive system easily over-generalizes it.
Disposition in this document. An external event changes a verifier's
answer only through a record from a party in a role the authority
model accepts, which is Section 8.4.1 and Section 8.3.8. The death
itself reaches no verifier. A record of the event decides nothing
without that accepted role, and where the role cannot be resolved the
continuation of authority is not established.
What the rule does not establish. It does not establish that any
rule about human agents applies to an AI agent. It does not
establish how notice is evidenced, or who carries the burden of
showing it.
*LC-B-029. A receiving bank's acceptance is the hard boundary after
which a mid-flight authority change no longer stops the order*
Status verified. Family lifecycle-organization-events. Domain
banking-payments.
Situation. A treasury agent submits a payment order under a valid
delegation. The authorizing principal's authority is revoked minutes
later. If the receiving bank has not yet accepted the payment order,
the revocation stops it from settling. If the bank already accepted
it, the order proceeds regardless of the revocation, unless the bank
itself agrees to unwind it.
Source. UCC 4A-211's acceptance boundary. Cornell LII
(https://www.law.cornell.edu/ucc/4A/4A-211): "After a payment order
has been accepted, cancellation or amendment of the order is not
effective unless the receiving bank agrees or a funds-transfer system
rule allows cancellation or amendment without agreement of the bank."
Authority question. Once an operation has passed a boundary after
which no further authorization decision occurs, does a later
authority change reach it?
Pidlisnyi Expires 1 April 2027 [Page 239]
Internet-Draft APS September 2026
Pressure this case puts on an authority model. The corpus leaves
work in flight open. In this document that is Section 19.2.2: the
old grant cannot authorize a new effect at the next authorization
boundary, and what happens to the operation itself is unsettled.
This supplies a concrete resolution for one instrument type: the
receiving institution's acceptance is the hard boundary. Before it,
revoking the authorizing delegation stops the order. After it, the
order proceeds independent of what the delegation graph says.
What a naive implementation gets wrong. Assuming revocation
automatically halts any payment order already submitted under it
ignores that acceptance gives the order a revocation-proof effect.
Assuming revocation never matters for in-flight orders ignores that
unaccepted orders remain fully stoppable.
Rule exercised. Invariants L6. Distinct from the already-verified
LC-B-028 (stop-payment), which is a customer-initiated cancellation
decision under L6's recheck principle. This is the underlying
delegated authority itself changing mid-flight, the specific question
left open under work in flight, Section 19.2.2.
Disposition in this document. The old grant admits no new effect at
the next authorization boundary, under APS-LC-RECHECK-AT-ADMISSION.
What happens to an operation already under way is open at
Section 19.2.2, and this document defines no acceptance boundary
inside a target system.
What the rule does not establish. It does not establish a boundary
for any instrument other than the one it names, and it does not
establish what the operation should do once that boundary has passed.
*LC-B-026. A third party outside the principal-agent relationship
can inject a new approval gate into an otherwise unmodified, valid
chain*
Status verified. Family lifecycle-legal-regulatory-events. Domain
regulatory.
Situation. A company settles a regulatory action. The consent
decree does not touch any existing delegation. It adds a new,
externally-imposed requirement that a named "responsible employee or
official" personally certify a defined category of future reports,
for the life of the decree.
Source. Consent decree practice requiring a named responsible
official to certify compliance reports under penalty of law. SEC
EDGAR filing
(https://www.sec.gov/Archives/edgar/data/1397516/000119312507093837/
Pidlisnyi Expires 1 April 2027 [Page 240]
Internet-Draft APS September 2026
dex105.htm): "...which makes any representation concerning the
Defendants' compliance or noncompliance with any requirement of this
Consent Decree shall be certified by a 'responsible employee or
official' of the Defendants."
Authority question. How does a verifier report an approval gate
added from outside the delegation chain, when no artifact in the
chain changed?
Pressure this case puts on an authority model. The original
delegation chain is untouched and still valid, and a transaction in
the decree's scope is no longer sufficient on that chain alone. It
also needs the named official's separate certification, until the
decree's own sunset date.
What a naive implementation gets wrong. A gateway that only re-
verifies the original chain has no slot for a chain-external approval
requirement injected by an outside party. It keeps authorizing
exactly the transactions the decree was meant to catch, because
nothing in the delegation itself changed.
Rule exercised. Structurally close to a dual-control policy, but the
source of the added gate is external (a court-approved settlement,
not internal risk policy), which none of L1-L12 name as a category.
Also the strongest sourced instance found of "policy change" as a
family.
Disposition in this document. The chain stays valid and the added
gate denies the action at the boundary, which is the restricted state
of Section 2.3. No record defined here carries the gate, and a
deployment that needs one states it in its profile.
What the rule does not establish. It does not establish how an
externally added gate is carried in a record, and it does not
establish that the added gate narrows the underlying grant.
*LC-B-008. Authority can end completely, instantly, and outside the
delegation system entirely*
Status verified. Family lifecycle-legal-regulatory-events. Domain
regulatory.
Situation. A bank's officer authority does not merely get revoked.
A federal receiver is appointed and by statute steps into every power
that officer held, the instant the appointment takes effect, with
zero notice to the delegation system that was relying on that
officer's authority.
Pidlisnyi Expires 1 April 2027 [Page 241]
Internet-Draft APS September 2026
Source. 12 U.S.C. § 1821(d), under which the FDIC as receiver of a
failed bank succeeds by operation of law to all rights and powers of
the institution and its officers. Cornell LII
(https://www.law.cornell.edu/uscode/text/12/1821): "The Corporation
shall, as conservator or receiver, and by operation of law, succeed
to all rights, titles, powers, and privileges of the insured
depository institution."
Authority question. What does a verifier do when the authority at
the head of a chain ends through an external fact that produces no
artifact anywhere in the delegation graph?
Pressure this case puts on an authority model. In the source domain
every delegation rooted in the former officer's authority ends when
the receiver is appointed, whether or not any system recorded a
revocation, and no replacement authority exists until the new
principal issues one. A model in which authority ends only through a
record it holds has nothing to read here, which is what makes the
case adversarial.
What a naive implementation gets wrong. A system that expects the
terminating event to show up as a revocation record in the
infrastructure it monitors sees nothing, because the ancestor
authority ended through an external legal fact with no corresponding
artifact anywhere in the delegation graph.
Rule exercised. Invariants L1, L2. A harder-edged instance of L1
and L2, where the "ancestor" whose end triggers invalidation is not
an APS artifact or even a company-internal record, but a statute
taking effect the instant a regulator acts.
Disposition in this document. An external event changes a verifier's
answer only through a record from a party in a role the authority
model accepts, which is Section 8.4.1 and Section 8.3.8. The
appointment reaches no verifier by itself. Replacement authority is
a new grant from a party that currently holds the authority granted,
under Section 8.3.7.
What the rule does not establish. It does not establish that an
external legal fact is observable to a verifier, and it does not
establish the moment at which a verifier could establish one.
*LC-A-016. Some replacement authority is pre-committed at issuance
time, not issued fresh after the fact*
Status verified. Family lifecycle-principal-events. Domain agency-
law.
Pidlisnyi Expires 1 April 2027 [Page 242]
Internet-Draft APS September 2026
Situation. A single delegation instrument names a primary delegate
and an ordered list of successors. The primary exits: dies, resigns,
becomes incapacitated. The next-in-line successor should be able to
act under the same original grant, with no new document and no action
required from the principal at the moment of handoff.
Source. The Uniform Power of Attorney Act's successor-agent
provision. UPOAA (2006) §111, hosted by the Mississippi Secretary of
State (https://www.sos.ms.gov/content/documents/pol_res/
power%20of%20attorney/5upoaa_final_may08.pdf): "A principal may
designate one or more successor agents to act if an agent resigns,
dies, becomes incapacitated, is not qualified to serve, or declines
to serve."
Authority question. Where replacement authority was pre-committed
inside the original instrument, does the successor act under that
instrument or need a fresh grant?
Pressure this case puts on an authority model. In the source
instrument the successor's authority comes from the original grant,
at the scope and terms that grant already set, and becomes
exercisable on the primary's exit with nothing issued at handoff
time. A model in which replacement authority is always issued fresh
after the fact has no shape for a grant that was pre-committed at
issuance.
What a naive implementation gets wrong. A system built around
"replacement authority always means a fresh grant from a currently-
authorized principal" (the L3/L4 pattern) has no slot for succession
pre-committed inside a single instrument. It either treats the
successor as unauthorized until a new grant appears, or wrongly
treats the successor as inheriting the primary's entire personal
delegation tree rather than just this one instrument.
Rule exercised. Invariants L3, L4. L3 and L4 assume replacement
authority is issued fresh, after the fact, by whoever currently holds
authority. This is a third pattern, authority pre-committed at
issuance for a defined contingency, that neither invariant names.
Disposition in this document. Pre-commitment is named at
Section 8.3.7 and no released package implements it. Where the terms
declare no binding mode and the actor is not the named subject, the
mode is not established and a verifier supplies no default.
What the rule does not establish. It does not establish that a pre-
committed successor is exercisable, and it does not establish what
the successor may do before its activating condition is established.
Pidlisnyi Expires 1 April 2027 [Page 243]
Internet-Draft APS September 2026
*LC-E-034. A queued action that outlasts a suspension needs a live
check at fire time, not just at the moment it was queued*
Status reviewed hypothetical. Family lifecycle-time-and-scheduling.
Domain agent-native.
Situation. An agent's authority is suspended pending an
investigation. It already had a recurring action queued to fire
later. The suspension is lifted before the queued action's scheduled
fire time. The scheduler holding the queued action has no visibility
into suspension state at all, it only knows the schedule, and fires
the action exactly as originally planned.
Source. No external precedent claimed.
Authority question. Does a queued action carry the authority state
it was queued under, or the state live at the moment it fires?
Pressure this case puts on an authority model. This particular
timeline is benign under L8's own logic, since the suspension was
already lifted before the action fired, so denying it would be wrong.
The case is worth naming because the scheduler got the right answer
by accident, having never checked live suspension state at all. The
same scheduler would fire the action identically even if the
suspension were still active at fire time, which is the actual
failure this case points at.
What a naive implementation gets wrong. A scheduler that only checks
authority state at the moment an action was queued, not at fire time,
produces the correct result in this timeline purely by luck. Change
nothing about the scheduler and only change the timeline so the
suspension is still active at fire time, and it fires an action that
should have been paused, because dormant queued work was never
something L8's stated mechanism has a hook to act on until the
scheduler itself checks live state at fire time.
Rule exercised. Invariants L8. L8 is specified only in terms of
pausing the use of authority and everything that depends on it, which
implicitly assumes a live dependency to pause. A queued-but-not-yet-
executing action is dormant, not in use, so L8's text does not make
explicit that the scheduler must check live state at fire time for
the scheduled-action case specifically.
Disposition in this document. The recheck at the moment of
consumption is APS-LC-RECHECK-AT-ADMISSION. A scheduler is not an
enforcement boundary in this document, and a queued action reaches an
authority answer only at the next authorization boundary.
Pidlisnyi Expires 1 April 2027 [Page 244]
Internet-Draft APS September 2026
What the rule does not establish. It claims no external precedent.
It does not establish that any scheduler behaves this way, and the
timeline it names is benign. Its value is the failure next to it, a
scheduler that would fire identically with the suspension still
standing.
*LC-F-027. An empty audit window can mean the record hasn't arrived
yet, not that nothing happened*
Status verified. Family lifecycle-infrastructure-failure. Domain
distributed-systems.
Situation. An APS deployment's audit pipeline batches evidence
records for delivery rather than writing them synchronously. A
revocation is enforced immediately at the gateway, but the durable
audit record proving the decision happened does not land in the
evidence store for some minutes afterward.
Source. AWS documents that CloudTrail log delivery is not
instantaneous. AWS CloudTrail FAQs
(https://aws.amazon.com/cloudtrail/faqs/): "Typically, CloudTrail
delivers an event within 5 minutes of the API call."
Authority question. Can a verifier read an empty window in an
evidence store as a finding that nothing happened in that window?
Pressure this case puts on an authority model. An evidence store
read inside its own delivery lag is not a complete account of the
interval asked about, so a model that reconstructs authority state at
a past instant has to say what an empty window is worth. The corpus
records delivery lag as a bound a deployment declares and monitors,
and it does not follow that an enforcement decision waits on its own
audit record.
What a naive implementation gets wrong. Treating an empty audit-log
window as proof nothing happened during that window, when it may only
mean the batched delivery hasn't caught up yet, exactly the wrong
conclusion for an investigation happening in near-real-time.
Rule exercised. Invariants L12. L12 (completeness is a separate and
stronger claim). This is the delivery-lag instance: a record that
hasn't arrived yet is not evidence of absence.
Disposition in this document. A verifier does not read absence from
silence. APS-LC-COMPLETENESS-BASIS makes a completeness claim state
its basis and reports not established with the coverage limb where
that basis cannot be established, and Section 19.1 carries no proof
of absence as a limit of this document.
Pidlisnyi Expires 1 April 2027 [Page 245]
Internet-Draft APS September 2026
What the rule does not establish. It does not establish a delivery
bound, and it does not establish that a record which has not arrived
will arrive.
*LC-D-025. "Authority is currently valid" and "a complete record
exists of what was done under it" are different claims a verifier
answers separately*
Status verified. Family lifecycle-credential-events. Domain
security-incident.
Situation. An outsourced support role is legitimately scoped to view
sensitive customer data as part of its ordinary function. Some
holders of that access are bribed to misuse it within that same valid
scope. The org detects and terminates the involved principals before
an extortion attempt surfaces, but the data already copied out cannot
be recovered by the termination.
Source. Coinbase's May 2025 disclosure that criminals bribed a
number of its outsourced, India-based customer support contractors to
copy customer data, which was then used in a $20 million extortion
attempt. The Hacker News (https://thehackernews.com/2025/05/
coinbase-agents-bribed-data-of-1-users.html): "What these attackers
were doing was finding Coinbase employees and contractors based in
India who were associated with our business process outsourcing or
support operations, that kind of thing, and bribing them in order to
obtain customer data."
Authority question. Does establishing that authority is no longer
valid establish anything about what was done under it while it was
valid?
Pressure this case puts on an authority model. Revoking a
misbehaving principal's authority answers whether it can still act
and answers nothing about what it already did while the authority was
valid. The second question needs its own account, built from
evidence of exercised authority inside the valid window, and a model
that reports only the first has no way to say that the second is
unanswered.
What a naive implementation gets wrong. Treating "we revoked their
access" as having closed the incident conflates stopping future
authorized action with establishing what happened during the entire
window the authority was, by every technical measure, valid and
properly scoped. A validly scoped grant misused for its whole active
duration leaves a gap no revocation, however prompt, can
retroactively close.
Pidlisnyi Expires 1 April 2027 [Page 246]
Internet-Draft APS September 2026
Rule exercised. Invariants L12. Distinct from L12's teardown-
completeness framing, which is about whether a descendant list was
complete at a boundary. This is about whether the record of what a
still-valid grant was actually used for is complete, a related but
separate completeness claim about exercised authority rather than
about descendant enumeration.
Disposition in this document. Chain validity and an account of what
was done under a grant are two findings. APS-LC-COMPLETENESS-BASIS
governs the second, and this document defines no basis on which such
an account is complete.
What the rule does not establish. It does not establish what a
complete record of exercised authority would contain, and it does not
establish that the revocation was late.
*LC-C-012. Independently rooted chains can commit to a shared
objective without unioning their scopes*
Status verified. Family lifecycle-multiple-principals-and-conflict.
Situation. One agent holds two chains from two unrelated roots. It
proposes an action whose amount is above the ceiling of either chain
on its own and below the two ceilings added together, and presents
both chains for the one action.
Authority question. Does holding two valid chains give an agent
authority that neither chain gives it, and is coordinating on one
objective the same thing as combining two authorities?
Rule exercised. APS-AUTH-CHAIN-NO-UNION and APS-AUTH-CHAIN-SET-NOT-
A-SELECTION, at Section 8.2.5. Each action is decided against one
root-to-leaf chain. A concatenated presentation is not a selection
of one chain and no action is decided against it. Independently
rooted chains may coordinate on a shared objective while each keeps
its own scope.
Disposition in this document. APS-AUTH-CHAIN-NO-UNION decides it.
One chain per action, no union of scope grants or spend ceilings, and
cross-principal composition needs a profile this document does not
supply.
What a naive implementation gets wrong. A verifier that unions the
two ceilings admits an amount neither principal granted, and reports
a single result for a decision it made against a set.
Pidlisnyi Expires 1 April 2027 [Page 247]
Internet-Draft APS September 2026
What the rule does not establish. It does not establish how an
action selects its chain, which is an implementation choice. It does
not establish that cross-principal composition is impossible, only
that it needs a profile this document does not supply.
*LC-E-006. Holding a scope does not carry authority to hand it to
something you spawn*
Status verified. Family lifecycle-agent-side-events.
Situation. An agent holding a scope spawns a child process and
passes the scope to it, with nothing in the authority model declaring
that the agent may confer authority.
Authority question. Is authority to exercise a scope the same
authority as authority to confer that scope on another party?
Rule exercised. Nothing normative in this revision. The question is
carried at Section 19.2.13 because the counterexample against the
drafted rule is unresolved. Monotonic narrowing bounds what a child
may receive and says nothing about who may create one.
Disposition in this document. Nothing normative in this revision.
The question is carried at Section 19.2.13, and until it is settled a
verifier that cannot establish conferral authority reports it as not
established rather than reading it out of possession.
What a naive implementation gets wrong. A framework that reads
conferral out of possession creates authority for a party the
principal never named, and a framework that forbids it outright
denies authority in models where a platform default supplies it.
What the rule does not establish. It does not establish that
conferral always needs a fresh act of the principal, and it does not
decide what happens to children already issued without declared
conferral authority.
*LC-C-014. A handover can require the incoming holder's
acknowledgment, with authority staying put until it arrives*
Status verified. Family lifecycle-time-and-scheduling.
Situation. Responsibility for an agent moves from one holder to
another. The instrument governing the handover makes the move
effective on the incoming holder acknowledging it rather than at a
stated instant.
Pidlisnyi Expires 1 April 2027 [Page 248]
Internet-Draft APS September 2026
Authority question. Is a handover an instant at which one party
authority ends and another begins, or an interval with a condition at
its end?
Rule exercised. APS-LC-SUCCESSION-NEW-GRANT and the handover rules
at Section 8.3.7. The agent keeps its identity, its old authority
does not survive revocation of the ancestor it depended on, and the
replacement chain stands on its own because it was independently
issued. Ordering is a deployment choice: a planned handover may
accept an overlap and a compromised holder may call for a gap.
Disposition in this document. The acknowledgment-gated handover is
described at Section 8.3.7 and no released package implements it.
Where the terms declare no binding mode, the mode is not established
and a verifier supplies no default.
What a naive implementation gets wrong. A framework that models a
handover as an instant has no state for the interval, and either
grants the incoming holder authority before the acknowledgment or
leaves the outgoing holder with none after the announcement.
What the rule does not establish. It does not decide the cutover
order for any deployment, and it does not establish what covers the
agent work during the interval.
*LC-B-024. Multiple independent suspensions on the same principal
have to be released independently, not cleared by any one of them
lapsing*
Status verified. Family lifecycle-legal-regulatory-events.
Situation. Two parties, acting for unrelated reasons, each impose a
suspension on one grant. One of the two releases its own.
Authority question. Does a release from one source reach a cause
imposed by another, and what is the state of the grant while one
cause remains?
Rule exercised. APS-LC-CAUSE-SET-NOT-FLAG, APS-LC-RELEASE-PER-CAUSE
and APS-LC-RELEASE-STANDING-EXTERNAL, at Section 8.3.5. Causes are a
set, each named cause is decided independently, standing over a cause
is resolved outside the record, and a party holding standing over a
cause it did not impose can release it.
Disposition in this document. APS-LC-CAUSE-SET-NOT-FLAG and APS-LC-
RELEASE-PER-CAUSE decide it, and Section 8.3.5 defines no precedence
order among causes.
Pidlisnyi Expires 1 April 2027 [Page 249]
Internet-Draft APS September 2026
What a naive implementation gets wrong. A framework holding one
suspension flag clears the whole pause on the first release, and a
framework that reads standing from the release record lets any
genuine signature clear any cause.
What the rule does not establish. It does not define a precedence
order among causes, and it does not establish that a release returns
authority to the shape it had before the cause was imposed.
*LC-E-002. A valid, non-expired, non-revoked grant can become
unexecutable, and that is a fourth state, not a variant of the other
three*
Status verified. Family lifecycle-agent-side-events.
Situation. A grant names a target, an executor or a capability that
no longer resolves. Nothing in the grant has changed and no
lifecycle event has occurred.
Authority question. Does a referent that has vanished change the
verdict on the artifact, or does it change only what happens at
execution?
Rule exercised. The unexecutable statement at Section 9.10, which is
informative because no family exercises it. The artifact verdict is
unchanged, the execution attempt fails, and the record carries the
referent that could not be resolved. Unexecutable is an execution
outcome and not an artifact verdict.
Disposition in this document. Section 9.10, which is informative.
The artifact verdict is unchanged, the execution attempt fails, and
the record carries the referent that could not be resolved.
What a naive implementation gets wrong. A framework that reports
such an artifact invalid, expired, revoked or suspended reports a
lifecycle event that did not happen, and loses the distinction
between an authority that ended and a target that vanished.
What the rule does not establish. It does not prescribe which party
re-points a grant whose referent is gone, or whether that party may.
It does not cover a referent that changed rather than vanished.
*LC-E-013. A long job's own logic must expect authority invalidation
to arrive silently mid-run, not only at its next gateway check*
Status verified. Family lifecycle-agent-side-events.
Pidlisnyi Expires 1 April 2027 [Page 250]
Internet-Draft APS September 2026
Situation. An agent is part way through a long operation when the
authority it is running under is revoked. The next authorization
boundary is some distance away.
Authority question. What does the agent do between the revocation
and the next boundary, and does the revocation reach the work already
under way?
Rule exercised. APS-LC-RECHECK-AT-ADMISSION at Section 8.2.6, and
CAND-12 at Section 8.4.7. The old grant authorizes no new effect at
the next authorization boundary. Effects already completed stand,
and ending authority does not by itself end sessions or derived
credentials already issued.
Disposition in this document. APS-LC-RECHECK-AT-ADMISSION decides
the next authorization boundary. Whether the operation resumes,
restarts, compensates or stops is open at Section 19.2.2.
What a naive implementation gets wrong. A framework that checks
authority only at a gateway treats the interval between boundaries as
covered by the last check, and an implementation that assumes
revocation halts a running operation assumes a control this document
does not require.
What the rule does not establish. It does not say whether the
operation resumes, restarts, compensates or stops, which is the
question at Section 19.2.2.
C.3. Boundary Cases
These 36 cases came out of the same research as the cases above and
each one is sound. What each lacks is a lifecycle verdict. Each
resolves to a liability outcome, a detection-surface gap, an
operational practice or an evidence question rather than to an
authority state a verifier returns from records. They are listed
because they bound the model. They mark where the authority question
stops and a different question starts, and a design that answers one
of them by extending the authority model is answering a different
question from the one it looks like.
Grouped by the reason each is outside the authority question, with
the count in each group: execution and scheduler mechanics, 5.
Implementation or configuration defect, 2. Liability or legal
consequence, 5. No authority transition in the scenario, 2. No
verifier in the scenario, 3. Security control, 19. The full list is
held in [APS-LIFECYCLE] and is not reproduced here.
Pidlisnyi Expires 1 April 2027 [Page 251]
Internet-Draft APS September 2026
Eight of the thirty-six are named elsewhere in this document and are
given here so that those references resolve. LC-E-010, an
idempotency-key retry returning the original result instead of re-
executing, and LC-E-011, a reused key with changed parameters
erroring outright, both under execution and scheduler mechanics, and
both behind the statement at Section 9.7 that deduplication is
execution behavior rather than an authority finding. LC-E-022, at-
least-once delivery making the target rather than the scheduler
responsible for preventing duplicate execution, same group. LC-
F-036, a cache whose configured lifetime drifts past its declared
freshness policy, under implementation or configuration defect, which
the stale-revocation failure class names as a configuration defect
rather than an authority finding. LC-D-016, a substituted
cryptographic constant defeating structural verification, under
security control, which the trust-root substitution class names as
the build-integrity half with no fixture family. LC-D-023 and LC-
D-019, an admin credential on a readable share and harvested
credentials remaining sufficient, both under security control, behind
the ambient bypass class. LC-D-027, a narrowly granted vendor
credential reaching unrelated systems because nothing enforced the
boundary, same group and same class.
Several of these are published security incidents. They are listed
as sources of case shapes. Nothing here attributes fault to any
named organization, and nothing here states that any incident would
have gone differently under this document.
This list does not establish that a boundary case is unimportant, and
it does not establish that the six reasons are the only reasons a
case could fall outside the authority question. It establishes which
cases were read and set aside, and why.
Appendix D. Requirement Matrix
This appendix is informative. It records every normative requirement
this revision states outside the closed core, under the stable
semantic identifier that requirement carries, with the section that
states it, the feature it belongs to, the vectors that exercise it,
and whether each reference implementation covers it.
Identifiers have the form APS-<AREA>-<SEMANTIC-SLUG> defined in
Section 13.2. The areas are fixed: ID, PRIN, AUTH, LC, POL, ENF,
REC, EVID, PROF, ADAPT, GOV and CONF. An identifier never changes
because a section moves and is never reused. Renumbering this
document moves no identifier.
Pidlisnyi Expires 1 April 2027 [Page 252]
Internet-Draft APS September 2026
Feature values. Core means a requirement of APS Core conformance,
mandatory for an implementation claiming the class the requirement's
area maps to in Section 13.1. Core, restated means the requirement
is stated in the closed core and the named section restates it
without adding to it, so citing either place cites one requirement.
Lifecycle Core is an informative grouping name for the six
identifiers in Section 8 that restate the closed core, one from each
of six of the twelve continuity rules, and it is not a claimable
base. Core, document requirement means a requirement of APS Core
conformance that binds a document a party writes rather than a
runtime check a verifier performs, so no runtime vector can reach it.
Every other value names one Candidate feature an implementation can
claim.
Vector columns. A requirement is recorded as exercised only where a
named vector carries an assertion that fails when the requirement is
violated. A related family is not coverage, and a family named in a
status block is not coverage on its own. Where both vector fields
read none, the requirement is specified and not exercised. Of the 99
requirements below, 14 are exercised by a named vector and 85 are
specified and not exercised.
Implementation columns. TypeScript is agent-passport-system 7.2.0 on
npm and Python is agent-passport-system 4.2.0 on PyPI. A value of
yes means the named package has a surface that implements the
requirement, read from its source, not that a run was observed. The
one run this document records is the authority-revocation-record run
at Section 4.5.2, and no other run backs a value in these columns.
Corpus pin. Every vector named below is present in the APS
conformance suite [APS-CONFORMANCE] at merge commit
5829e2ff00d75f49ce21e9d87e756658deb1ef33, dated 24 September 2026,
which includes the authority-revocation-record family. Vectors were
read from the working tree at commit
04c2e334395c55c029f061ae0ca55f80aeb6ee9e plus that family, and no
vector changed between the two commits.
D.1. Requirements of This Revision
The implementation values below come from reading the sources of
agent-passport-system 7.2.0 on npm and agent-passport-system 4.2.0 on
PyPI, on the same basis as Appendix A. No run backs any of them
except the authority-revocation-record run recorded under
Section 4.5.2. A vector named under an identifier marked specified
and not exercised carries no assertion keyed to that identifier.
Where a status block elsewhere in this document lists implemented
requirements, it lists the identifiers this list marks yes for at
least one of the two packages.
Pidlisnyi Expires 1 April 2027 [Page 253]
Internet-Draft APS September 2026
APS-EVID-VERDICT-SET-CLOSED
Section: Section 2.3. Feature: Evidence model. Positive vectors:
lifecycle-evidence-and-record, all 12 cases, whose runner asserts
the closed verdict vocabulary on every case. Negative vectors:
none. Implementation: TypeScript yes, Python yes.
APS-EVID-REASON-CODE-REQUIRED
Section: Section 2.3. Feature: Evidence model. Positive vectors:
none. Negative vectors: none. Implementation: TypeScript yes,
Python yes.
APS-EVID-NOT-ESTABLISHED
Section: Section 2.3. Feature: Evidence model. Positive vectors:
none. Negative vectors: none. Implementation: TypeScript yes,
Python yes.
APS-EVID-NO-RETROACTIVE-REWRITE
Section: Section 2.4. Feature: Evidence model. Positive vectors:
lifecycle-evidence-and-record LC-G-006-b, LC-G-006-c. Negative
vectors: lifecycle-evidence-and-record LC-G-006-d, LC-G-006-e.
Implementation: TypeScript no, Python no.
APS-EVID-DIGEST-MISMATCH-NOT-ESTABLISHED
Section: Section 2.4. Feature: Evidence model. Positive vectors:
none. Negative vectors: lifecycle-evidence-and-record LC-G-006-f.
Implementation: TypeScript no, Python no.
APS-ENF-NO-ABSENCE-INFERENCE
Section: Section 2.5. Feature: Evidence model. Positive vectors:
none. Negative vectors: accountability-record vector 9, positive-
deny-executed. Implementation: TypeScript no, Python no.
APS-REC-REVOCATION-TIME-SIGNED
Section: Section 4.5.2. Feature: Revocation record format.
Positive vectors: authority-revocation-record ARR-01. Negative
vectors: authority-revocation-record ARR-04. Implementation:
TypeScript yes, Python yes.
APS-REC-REVOCATION-UNKNOWN-TYPE-UNSUPPORTED
Section: Section 4.5.2. Feature: Revocation record format.
Positive vectors: none. Negative vectors: authority-revocation-
record ARR-05. Implementation: TypeScript yes, Python yes.
APS-REC-REVOCATION-RECOMPUTE-IDS
Section: Section 4.5.2. Feature: Revocation record format.
Positive vectors: authority-revocation-record ARR-01. Negative
vectors: authority-revocation-record ARR-02, ARR-03, ARR-06.
Implementation: TypeScript yes, Python yes.
Pidlisnyi Expires 1 April 2027 [Page 254]
Internet-Draft APS September 2026
APS-REC-REVOCATION-FIRST-WINS
Section: Section 4.5.2. Feature: Revocation record format.
Positive vectors: authority-revocation-record ARR-07. Negative
vectors: authority-revocation-record ARR-08. Implementation:
TypeScript yes, Python yes.
APS-REC-REVOCATION-REVOKER-IS-ISSUER
Section: Section 4.5.2. Feature: Revocation record format.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-PROF-REQUIRED-CONTENT
Section: Section 6.1. Feature: Profile model. Positive vectors:
none. Negative vectors: none. Implementation: TypeScript no,
Python no.
APS-PROF-SEMANTIC-PRESERVATION
Section: Section 6.1. Feature: Profile model. Positive vectors:
none. Negative vectors: none. Implementation: TypeScript no,
Python no.
APS-PROF-NO-WIDENING
Section: Section 6.1. Feature: Profile model. Positive vectors:
none. Negative vectors: none. Implementation: TypeScript no,
Python no.
APS-PROF-UNKNOWN-NOT-VALID
Section: Section 6.1. Feature: Profile model. Positive vectors:
none. Negative vectors: none. Implementation: TypeScript no,
Python no.
APS-LC-STANDING-NOT-FROM-RECORD
Section: Section 8.1. Feature: Lifecycle concepts. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-STANDING-THREE-VALUED
Section: Section 8.1. Feature: Lifecycle concepts. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-ISSUER-VS-LIFECYCLE-STANDING
Section: Section 8.1. Feature: Lifecycle concepts. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
Pidlisnyi Expires 1 April 2027 [Page 255]
Internet-Draft APS September 2026
APS-LC-VERDICT-ENUMERATIONS-DISTINCT
Section: Section 8.1. Feature: Lifecycle concepts. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-NOT-ESTABLISHED-LIMB
Section: Section 8.1. Feature: Lifecycle concepts. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-ANCESTOR-REVOCATION-REACHES-DEPENDENTS
Section: Section 8.2.1. Feature: Lifecycle Core. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-IDENTITY-NOT-AUTHORITY
Section: Section 8.2.2. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors: none.
Implementation: TypeScript yes, Python yes.
APS-LC-NO-REVOCATION-REVERSAL
Section: Section 8.2.3. Feature: Lifecycle Core. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-NO-REPARENTING
Section: Section 8.2.3. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors: none.
Implementation: TypeScript yes, Python yes.
APS-LC-SUCCESSOR-NO-INHERITANCE
Section: Section 8.2.4. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors: none.
Implementation: TypeScript no, Python no.
APS-AUTH-CHAIN-NO-UNION
Section: Section 8.2.5. Feature: Lifecycle Core. Positive
vectors: none. Negative vectors: single-chain-selection SCS-06,
chain-selection-no-union CSNU-01 to CSNU-11. Implementation:
TypeScript yes, Python yes.
APS-AUTH-CHAIN-SET-NOT-A-SELECTION
Section: Section 8.2.5. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors:
single-chain-selection SCS-06. Implementation: TypeScript yes,
Python yes.
Pidlisnyi Expires 1 April 2027 [Page 256]
Internet-Draft APS September 2026
APS-AUTH-CHAIN-REPORT-ONE-CHAIN
Section: Section 8.2.5. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors: none.
Implementation: TypeScript yes, Python yes.
APS-LC-RECHECK-AT-ADMISSION
Section: Section 8.2.6. Feature: Lifecycle Core. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-LC-CACHED-DECISION-FRESHNESS
Section: Section 8.2.6. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors: none.
Implementation: TypeScript no, Python no.
APS-LC-UNKNOWN-NOT-ACTIVE
Section: Section 8.2.7. Feature: Lifecycle Core. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-UNKNOWN-DENIAL-SAYS-NOT-ESTABLISHED
Section: Section 8.2.7. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors: none.
Implementation: TypeScript no, Python no.
APS-LC-SUSPENSION-NOT-REVOCATION
Section: Section 8.2.8. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors: none.
Implementation: TypeScript yes, Python yes.
APS-LC-ROTATION-NOT-REVOCATION
Section: Section 8.2.9. Feature: Lifecycle Core. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-REVOCATION-NOT-ABOUT-KEY
Section: Section 8.2.9. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors: none.
Implementation: TypeScript yes, Python yes.
APS-LC-EXPIRY-NOT-REVOCATION
Section: Section 8.2.10. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors: none.
Implementation: TypeScript yes, Python yes.
Pidlisnyi Expires 1 April 2027 [Page 257]
Internet-Draft APS September 2026
APS-LC-NO-RESURRECTION
Section: Section 8.2.11. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors: none.
Implementation: TypeScript yes, Python yes.
APS-LC-COMPLETENESS-BASIS
Section: Section 8.2.12. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors:
lifecycle-infrastructure-failure LC-F-016-b, LC-F-026-a, LC-
F-027-a, LC-F-027-b, LC-F-029-a. Implementation: TypeScript no,
Python no.
APS-LC-ACTIVATION-SOURCE-DECLARED
Section: Section 8.3.1. Feature: Activation conditions. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-ACTIVATION-EVIDENCE-ORDER
Section: Section 8.3.1. Feature: Activation conditions. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-ACTIVATION-NOT-INVALID
Section: Section 8.3.1. Feature: Activation conditions. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-BOUND-KINDS-DISTINCT
Section: Section 8.3.2. Feature: Purpose bounds and exhaustion.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-PURPOSE-MEMBERSHIP-NOT-EXHAUSTION
Section: Section 8.3.2. Feature: Purpose bounds and exhaustion.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-FULFILMENT-UNESTABLISHED-NOT-EXHAUSTED
Section: Section 8.3.2. Feature: Purpose bounds and exhaustion.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-EXHAUSTION-IRREVERSIBLE
Section: Section 8.3.2. Feature: Purpose bounds and exhaustion.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
Pidlisnyi Expires 1 April 2027 [Page 258]
Internet-Draft APS September 2026
APS-LC-REFERENT-CONTINUITY-PINNED
Section: Section 8.3.3. Feature: Capability and policy binding.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-PINNED-MISMATCH-DENIES
Section: Section 8.3.3. Feature: Capability and policy binding.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-POLICY-VERSION-IDENTIFIED
Section: Section 8.3.3. Feature: Core, restated. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-LC-POLICY-TIGHTENING-RESTRICTS
Section: Section 8.3.3. Feature: Capability and policy binding.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-LC-EPOCH-FEATURE-DEFINITION
Section: Section 8.3.4. Feature: Authority epoch. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-LC-EPOCH-NO-REGRESSION
Section: Section 8.3.4. Feature: Authority epoch. Positive
vectors: none. Negative vectors: authority-epoch-rollback AER-01
to AER-12, for rejection of stale authority. Implementation:
TypeScript yes, Python yes.
APS-LC-EPOCH-SCOPE-DECLARED
Section: Section 8.3.4. Feature: Authority epoch. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-WITHDRAWAL-NOT-REMOVAL
Section: Section 8.2.3. Feature: Continuity rules outside
Lifecycle Core. Positive vectors: none. Negative vectors: none.
Implementation: TypeScript yes, Python yes.
APS-LC-CAUSE-SET-NOT-FLAG
Section: Section 8.3.5. Feature: Suspension cause sets. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
Pidlisnyi Expires 1 April 2027 [Page 259]
Internet-Draft APS September 2026
APS-LC-RELEASE-PER-CAUSE
Section: Section 8.3.5. Feature: Suspension cause sets. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-RELEASE-STANDING-EXTERNAL
Section: Section 8.3.5. Feature: Suspension cause sets. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-CHAIN-RESULT-PRECEDES-PAUSE
Section: Section 8.3.5. Feature: Suspension cause sets. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-STATUS-SOURCE-ACCEPTED
Section: Section 8.3.6. Feature: Status sources. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-FRESHNESS-PER-SOURCE
Section: Section 8.3.6. Feature: Status sources. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-STATUS-CONFLICT-NO-ADMIT
Section: Section 8.3.6. Feature: Status sources. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-COVERAGE-AS-STATED
Section: Section 8.3.6. Feature: Status sources. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
APS-LC-OFFLINE-DECLARED-IN-ADVANCE
Section: Section 8.3.6. Feature: Status sources. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-LC-SUCCESSION-NEW-GRANT
Section: Section 8.3.7. Feature: Succession and handover.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
Pidlisnyi Expires 1 April 2027 [Page 260]
Internet-Draft APS September 2026
APS-LC-BINDING-MODE-NO-DEFAULT
Section: Section 8.3.7. Feature: Succession and handover.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-LC-VACANCY-NOT-ESTABLISHED
Section: Section 8.3.7. Feature: Succession and handover.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-PRIN-TWO-FINDINGS
Section: Section 8.3.8. Feature: Principals and departure.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-PRIN-ROLE-NOT-FROM-BODY
Section: Section 8.3.8. Feature: Principals and departure.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-PRIN-SILENCE-NOT-CONSENT
Section: Section 8.3.8. Feature: Principals and departure.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-PRIN-ACCOUNTABILITY-SEPARATE
Section: Section 8.3.8. Feature: Principals and departure.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-EVID-RELATIONS-NOT-TRANSITIVE
Section: Section 9.1. Feature: Decision to effect. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-REC-DECISION-REF-RECOMPUTED
Section: Section 9.1. Feature: Core, restated. Positive vectors:
receipt-decision-relation pass, temporal-equal, temporal-earlier.
Negative vectors: receipt-decision-relation substitution and the
three flipped counterparts. Implementation: TypeScript yes,
Python yes.
APS-REC-DECISION-BINDING-BEFORE-READ
Section: Section 9.1. Feature: Decision to effect. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
Pidlisnyi Expires 1 April 2027 [Page 261]
Internet-Draft APS September 2026
APS-ENF-EXACT-ACTION-MATCH
Section: Section 9.2. Feature: Decision to effect. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-ENF-NO-COVERAGE-NO-BYPASS-CLAIM
Section: Section 9.3. Feature: Decision to effect. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-ENF-COVERAGE-PREMISE-SCOPED
Section: Section 9.3. Feature: Decision to effect. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-ENF-COVERAGE-RESOLVES-TO-ADMISSION
Section: Section 9.3. Feature: Decision to effect. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-EVID-EFFECT-NOT-FROM-RESULT
Section: Section 9.4. Feature: Decision to effect. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-EVID-READBACK-OUTCOMES
Section: Section 9.4. Feature: Decision to effect. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-EVID-MISSING-NAMED
Section: Section 9.5. Feature: Decision to effect. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-EVID-STATES-NOT-SYNONYMS
Section: Section 9.6. Feature: Decision to effect. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-ENF-RETRY-NEW-DECISION
Section: Section 9.7. Feature: Decision to effect. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
Pidlisnyi Expires 1 April 2027 [Page 262]
Internet-Draft APS September 2026
APS-ENF-COMPENSATION-NEW-RECORD
Section: Section 9.7. Feature: Decision to effect. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-ENF-RESERVE-AT-APPROVAL
Section: Section 5.3. Feature: Core, restated. Positive vectors:
none. Negative vectors: none. Implementation: TypeScript no,
Python no.
APS-ENF-COMPLETE-AT-ADMISSION
Section: Section 7.3.2. Feature: Core, restated. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-ENF-SETTLE-AFTER-RESULT
Section: Section 4.4. Feature: Core, restated. Positive vectors:
none. Negative vectors: none. Implementation: TypeScript no,
Python no.
APS-ENF-RELEASE-PRE-DISPATCH-ONLY
Section: Section 4.4. Feature: Core, restated. Positive vectors:
none. Negative vectors: none. Implementation: TypeScript no,
Python no.
APS-ENF-CONFLICTING-REUSE-REJECTED
Section: Section 5. Feature: Core, restated. Positive vectors:
none. Negative vectors: none. Implementation: TypeScript no,
Python no.
APS-ADAPT-NO-WIDENING
Section: Section 11.4.1. Feature: Adapter contracts. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-ADAPT-NO-SILENT-SEMANTIC-LOSS
Section: Section 11.4.1. Feature: Adapter contracts. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-ADAPT-RECOMPUTE-ACTION-REF
Section: Section 11.4.1. Feature: Adapter contracts. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python yes.
Pidlisnyi Expires 1 April 2027 [Page 263]
Internet-Draft APS September 2026
APS-ADAPT-STAGE-COMMITMENT
Section: Section 11.4.1. Feature: Adapter contracts. Positive
vectors: none. Negative vectors: k8s-receipt-admission-stage-
negatives cand1 to cand5. Implementation: TypeScript no, Python
no.
APS-ADAPT-CANONICALIZATION-STATED
Section: Section 11.4.1. Feature: Adapter contracts. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-ADAPT-MCP-EXTENSION-DECLARED
Section: Section 11.4.2. Feature: Adapter contracts. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-ADAPT-NO-INVENTED-SPEND-BASIS
Section: Section 11.4.4. Feature: Core, restated. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript yes, Python no.
APS-CONF-CLASS-NAMED
Section: Section 13.1. Feature: Core, document requirement.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-CONF-CLAIM-CONTENT
Section: Section 13.4. Feature: Core, document requirement.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-CONF-CLAIM-NOT-VERDICT
Section: Section 13.4. Feature: Core, document requirement.
Positive vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-CONF-THREE-RESULTS
Section: Section 13.5. Feature: Conformance reporting. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
APS-CONF-NOT-SUPPORTED-NOT-SCORE
Section: Section 13.5. Feature: Conformance reporting. Positive
vectors: none. Negative vectors: none. Implementation:
TypeScript no, Python no.
Pidlisnyi Expires 1 April 2027 [Page 264]
Internet-Draft APS September 2026
What this list does not establish. It does not establish that any
implementation ran any vector, that an exercised requirement is
correctly implemented anywhere, or that the requirements listed are
every obligation this document places on an implementation. An
obligation stated across two sentences, or stated without a BCP 14
keyword, carries no identifier and does not appear here.
D.2. Map From the Suite Requirement Identifiers
The rows below are every requirement the inventory records against a
named fixture. The 43 requirements the inventory records as not
exercised with no fixture at all are not reproduced here and are
listed in the inventory itself.
+===========+=====+=============================+===+====+=========+
|REQ id |Sec |Family |Vec|Impl|Result |
+===========+=====+=============================+===+====+=========+
|REQ-2.2-1 |2.2 |cross-stack/receipts-amdal |6 |PY |partial |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-2.2-4 |2.2 |cross-stack/receipts-amdal |6 |PY |partial |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-2.4-2 |2.4 |cross-stack/oracle-safety- |13 |TS, |partial |
| | |check | |PKG | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-2.5-4 |2.5 |cross-stack/oracle-safety- |13 |TS, |partial |
| | |check | |PKG | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-2.6-1 |2.6 |instruction-provenance |10 |TS |partial |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-3.2-1 |3.2 |cross-stack/oracle-safety- |13 |none|not |
| | |check | | |exercised|
+-----------+-----+-----------------------------+---+----+---------+
|REQ-3.2-2 |3.2 |cross-stack/oracle-safety- |13 |TS |exercised|
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-3.2-3 |3.2 |cross-stack/oracle-safety- |13 |TS |partial |
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-3.2-4 |3.2 |cross-stack/oracle-safety- |13 |TS |exercised|
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-3.2-5 |3.2 |cross-stack/oracle-safety- |13 |TS |partial |
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-3.2-7 |3.2 |cross-stack/oracle-safety- |13 |TS |exercised|
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-3.2-8 |3.2 |cross-stack/oracle-safety- |13 |TS |partial |
Pidlisnyi Expires 1 April 2027 [Page 265]
Internet-Draft APS September 2026
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-3.2-9 |3.2 |cross-stack/oracle-safety- |13 |TS |exercised|
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-3.3-1 |3.3 |cross-stack/oracle-safety- |13 |TS |partial |
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-3.5-1 |3.5 |cross-stack/oracle-safety- |13 |TS |partial |
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-3.5-2 |3.5 |interop/aae-envelope |4 |TS |partial |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-4-1 |4 |cross-stack/oracle-safety- |13 |none|not |
| | |check | | |exercised|
+-----------+-----+-----------------------------+---+----+---------+
|REQ-4-2 |4 |cross-stack/oracle-safety- |13 |none|partial |
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-4.1-1 |4.1 |actionref-canonical |6 |none|not |
| | | | | |exercised|
+-----------+-----+-----------------------------+---+----+---------+
|REQ-4.1-2 |4.1 |actionref-canonical |6 |none|not |
| | | | | |exercised|
+-----------+-----+-----------------------------+---+----+---------+
|REQ-4.1-3 |4.1 |actionref-canonical |6 |TS |partial |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-4.1-7 |4.1 |cross-stack/action-ref- |14 |NODE|partial |
| | |v1-negatives | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-4.1-8 |4.1 |cross-stack/action-ref- |14 |NODE|partial |
| | |v1-negatives | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-4.2-1 |4.2 |cross-stack/argentum-action- |10 |PY |exercised|
| | |ref-v1v2 | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-5.1-1 |5.1 |cross-stack/receipts-aeoess |2 |PY, |partial |
| | | | |PKG | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-5.1-2 |5.1 |cross-stack/receipts-aeoess, |2, |PY, |partial |
| | |cross-stack/oracle-safety- |13 |TS | |
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-5.1-3 |5.1 |cross-stack/receipts-aeoess |2 |PY, |partial |
| | | | |PKG | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-5.2-1 |5.2 |cross-stack/receipts-aeoess |2 |PY |partial |
+-----------+-----+-----------------------------+---+----+---------+
Pidlisnyi Expires 1 April 2027 [Page 266]
Internet-Draft APS September 2026
|REQ-5.3.1-1|5.3.1|cross-stack/receipts-aeoess |2 |none|partial |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-5.3.2-3|5.3.2|cross-stack/oracle-safety- |13 |none|not |
| | |check | | |exercised|
+-----------+-----+-----------------------------+---+----+---------+
|REQ-5.4-1 |5.4 |receipt-decision-relation |7 |TS |partial |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-5.4-2 |5.4 |receipt-decision-relation |7 |none|not |
| | | | | |exercised|
+-----------+-----+-----------------------------+---+----+---------+
|REQ-5.5-1 |5.5 |cross-stack/oracle-safety- |13 |TS |partial |
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-5.6-1 |5.6 |cross-stack/oracle-safety- |13 |TS |partial |
| | |check | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-7.3-3 |7.3 |cross-stack/token-exchange- |12 |TS |partial |
| | |attenuation-v0 | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-9-3 |9 |cross-stack/aat-amdal |5 |PY |partial |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-9-4 |9 |cross-stack/action-ref- |14 |NODE|partial |
| | |v1-negatives | | | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-9-6 |9 |interop/scitt-cose-vectors- |not|TS |partial |
| | |ietf126 |run| | |
+-----------+-----+-----------------------------+---+----+---------+
|REQ-9-7 |9 |composition/a2a-1496- |4 |TS |partial |
| | |negative-paths | | | |
+-----------+-----+-----------------------------+---+----+---------+
Table 15: Requirement coverage, corpus inventory rows with a fixture
Reading the table. A vector count is the count for the file the
inventory row names, not for every file in the family. Where a
family carries dated files, the count is for the file cited. The
oracle-safety-check rows share one 13-vector set and differ in which
mutation of it the row reaches, so the counts do not add across rows.
The scitt-cose row records a verifier that exists but needs an
external test-vector checkout that is not in the tree, and the corpus
records that run as skipped.
What this table does not establish. It does not establish that an
exercised row means the requirement is correctly implemented
anywhere, that a partial row is close to exercised, or that the ratio
of the three results measures anything. It does not carry the 43
requirements with no fixture, so it is not a coverage summary.
Pidlisnyi Expires 1 April 2027 [Page 267]
Internet-Draft APS September 2026
D.3. Families Named in Status Blocks
The families below are named in the status blocks of Section 6 and
Section 13. Five of them are named in Appendix D.1 as the vectors
that exercise a requirement of this revision: accountability-record,
authority-epoch-rollback, chain-selection-no-union, receipt-decision-
relation and single-chain-selection. The rest carry no requirement
identifier, because the inventory at Appendix D.2 covers the -03 text
and these families were written against text proposed after it.
+===============+===+====================+==========================+
|Family |Vec|Counted from |Declared status |
+===============+===+====================+==========================+
|activation-not-|19 |cases |candidate_against_proposed|
|established | | | |
+---------------+---+--------------------+--------------------------+
|accountability-|12 |vectors |not declared in the |
|record | | |vectors file |
+---------------+---+--------------------+--------------------------+
|action-result- |6 |cases |not declared in the |
|binding | | |vectors file |
+---------------+---+--------------------+--------------------------+
|ancestor- |4 |cases |not declared in the |
|revocation- | | |vectors file |
|chain | | | |
+---------------+---+--------------------+--------------------------+
|approval- |9 |presentations |not declared in the |
|single-use | | |vectors file |
+---------------+---+--------------------+--------------------------+
|arap-binding |27 |denial_binding_cases|candidate |
| | |12, approval_cases | |
| | |10, | |
| | |pep_fallback_cases 5| |
+---------------+---+--------------------+--------------------------+
|authority- |12 |cases |candidate |
|epoch-rollback | | | |
+---------------+---+--------------------+--------------------------+
|cached- |9 |cases |candidate |
|authorization- | | | |
|revocation | | | |
+---------------+---+--------------------+--------------------------+
|capability- |8 |presentations |candidate_against_proposed|
|binding-drift | | | |
+---------------+---+--------------------+--------------------------+
|chain- |11 |cases |candidate_against_proposed|
|selection-no- | | | |
|union | | | |
+---------------+---+--------------------+--------------------------+
Pidlisnyi Expires 1 April 2027 [Page 268]
Internet-Draft APS September 2026
|conflicting- |14 |cases |candidate_against_proposed|
|status-sources | | | |
+---------------+---+--------------------+--------------------------+
|instruction- |10 |vectors |not declared in the |
|provenance | | |fixture file |
+---------------+---+--------------------+--------------------------+
|issuance- |8 |part_a_issuance 5, |not declared in the |
|refusal-expiry | |part_b_verification |vectors file |
| | |3 | |
+---------------+---+--------------------+--------------------------+
|key-rotation- |5 |cases |not declared in the |
|historical | | |vectors file |
+---------------+---+--------------------+--------------------------+
|lifecycle- |10 |vectors |not declared in the |
|conferral- | | |vectors file |
|without- | | | |
|authority | | | |
+---------------+---+--------------------+--------------------------+
|lifecycle- |42 |cases |candidate_against_proposed|
|credential- | | | |
|events | | | |
+---------------+---+--------------------+--------------------------+
|lifecycle- |13 |presentations |candidate_against_proposed|
|identifier- | | | |
|reuse-and- | | | |
|rename | | | |
+---------------+---+--------------------+--------------------------+
|lifecycle- |44 |vectors |not declared in the |
|legal- | | |vectors file |
|regulatory- | | | |
|events | | | |
+---------------+---+--------------------+--------------------------+
|lifecycle- |92 |vectors |candidate_against_proposed|
|multiple- | | | |
|principals-and-| | | |
|conflict | | | |
+---------------+---+--------------------+--------------------------+
|lifecycle- |22 |vectors |candidate_against_proposed|
|outside-the- | | | |
|chain-standing | | | |
+---------------+---+--------------------+--------------------------+
|lifecycle- |32 |cases |candidate_against_proposed|
|principal- | | | |
|events | | | |
+---------------+---+--------------------+--------------------------+
|merkle-root- |6 |vectors |not declared in the |
|parity | | |vectors file |
+---------------+---+--------------------+--------------------------+
Pidlisnyi Expires 1 April 2027 [Page 269]
Internet-Draft APS September 2026
|read-fidelity- |8 |vectors |not declared in the |
|receipt | | |fixture file |
+---------------+---+--------------------+--------------------------+
|receipt- |7 |one file per vector |not declared in a vectors |
|decision- | | |file |
|relation | | | |
+---------------+---+--------------------+--------------------------+
|revocation- |14 |cases |not declared in the |
|resolution- | | |vectors file |
|forward-compat | | | |
+---------------+---+--------------------+--------------------------+
|runtime- |9 |cases |not declared in the |
|authority- | | |vectors file |
|denial- | | | |
|continuity | | | |
+---------------+---+--------------------+--------------------------+
|single-chain- |6 |cases |not declared in the |
|selection | | |vectors file |
+---------------+---+--------------------+--------------------------+
|suspension- |16 |cases |candidate_against_proposed|
|cause- | | | |
|composition | | | |
+---------------+---+--------------------+--------------------------+
Table 16: Fixture families named in status blocks of the profile and
conformance sections
The cross-stack group named in the protocol adapter class is not one
family. At the pinned commit it holds nine external-system families
and two lab-authored regression families, each admitted under its own
evidence document and each declaring its own verification split.
They are not counted as a single number here for the same reason the
corpus refuses a suite-wide support number.
Counted from. The Counted from column names the key in the family's
vectors file that the count was taken from. The key differs by
family because the unit differs, which is the same reason
Section 13.5 gives for refusing a total. A count in this table is a
count of entries under one named key and is not comparable across
rows.
Declared status. The value is read from the family's vectors file,
from its status member or its label member. Where a file carries
both and they differ in spelling, the longer spelling is recorded,
which is the reading the corpus itself states for the two families
that do this. Not declared in the vectors file means the file
carries neither member. That does not mean the family has no status,
and several state one in the README only.
Pidlisnyi Expires 1 April 2027 [Page 270]
Internet-Draft APS September 2026
Every family in this table is run by the repository's own test entry
point at the pinned commit, which is a fact about the package
manifest at that commit rather than an observation of a run.
What this table does not establish. It does not establish that any
family passed, that the families listed are a complete set for this
document, or that vector counts measure the strength of a family. A
family with 92 vectors is not four times the family with 22.
Author's Address
Tymofii Pidlisnyi
Agent Passport System
Email: signal@aeoess.com
URI: https://agent-passport.org
Pidlisnyi Expires 1 April 2027 [Page 271]