Bounded Capability Receipts and Durable Spend Control for Agent Actions
draft-schrock-ep-bounded-capability-receipts-05
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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Iman Schrock | ||
| Last updated | 2026-09-06 (Latest revision 2026-08-11) | ||
| RFC stream | (None) | ||
| Formats | |||
| 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-schrock-ep-bounded-capability-receipts-05
Network Working Group I. Schrock
Internet-Draft EMILIA Protocol, Inc.
Intended status: Experimental 6 September 2026
Expires: 10 March 2027
Bounded Capability Receipts and Durable Spend Control for Agent Actions
draft-schrock-ep-bounded-capability-receipts-05
Abstract
Agents sometimes need bounded authority to perform more than one
consequential action without obtaining a new human approval for every
operation. A signed token alone cannot enforce a shared budget
across replicas, survive retries safely, or distinguish an operation
that never crossed an effect boundary from one whose outcome is
unknown.
This document defines a bounded capability receipt and a durable
reserve-admit-reconcile protocol. The receipt binds an issuance
authorization, a closed action scope, a budget with explicit units, a
holder proof, an expiry, and any parent capability. The state
protocol atomically refuses overspend and operation-key replay,
fences concurrent owners, and charges an indeterminate operation when
an external effect may have occurred. Delegation transfers rather
than copies authority: all direct child allocations are funded by
committed parent operations before child registration, and their
aggregate cannot exceed the parent balance within one authoritative
atomic state domain. It also defines narrowing-only delegation,
explicit revocation inheritance for delegated authority, an optional
admission-control epoch that can freeze new consequence admission,
and evidence interfaces. It does not make a bearer token into human
approval, does not provide cross-domain or offline global double-
spend prevention, and does not claim that an authorized action was
safe, lawful, or successfully executed.
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/.
Schrock Expires 10 March 2027 [Page 1]
Internet-Draft EP Bounded Capabilities 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 10 March 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
1.2. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Trust Model . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. The Bounded Capability Receipt . . . . . . . . . . . . . . . 6
4.1. Required Fields . . . . . . . . . . . . . . . . . . . . . 7
4.2. Signature Input and Receipt Digest . . . . . . . . . . . 9
4.3. Receipt Verification . . . . . . . . . . . . . . . . . . 9
5. Issuance Authorization . . . . . . . . . . . . . . . . . . . 10
6. Per-Action Human Authorization Composition . . . . . . . . . 10
7. Action Scope . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Holder Proof and Threshold Custody . . . . . . . . . . . . . 14
9. Registration . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Reserve, Admit, and Reconcile . . . . . . . . . . . . . . . . 16
10.1. Reserve . . . . . . . . . . . . . . . . . . . . . . . . 16
10.2. Effect Boundary . . . . . . . . . . . . . . . . . . . . 17
10.3. Commit . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.4. Crash Recovery and Reconciliation . . . . . . . . . . . 19
11. Executor and State-Domain Binding . . . . . . . . . . . . . . 19
11.1. Admission-Control Epoch and Emergency Freeze . . . . . . 20
12. Narrowing Delegation . . . . . . . . . . . . . . . . . . . . 21
12.1. Revocation Inheritance Across Delegation Lineage . . . . 21
13. Evidence and Decision Vocabulary . . . . . . . . . . . . . . 23
14. Failure Codes . . . . . . . . . . . . . . . . . . . . . . . . 23
Schrock Expires 10 March 2027 [Page 2]
Internet-Draft EP Bounded Capabilities September 2026
15. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 24
16. Relationship to Other Work . . . . . . . . . . . . . . . . . 27
17. Security Considerations . . . . . . . . . . . . . . . . . . . 29
18. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32
19. Implementation Status . . . . . . . . . . . . . . . . . . . . 32
20. Changes Since -04 . . . . . . . . . . . . . . . . . . . . . . 35
21. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
23. References . . . . . . . . . . . . . . . . . . . . . . . . . 36
23.1. Normative References . . . . . . . . . . . . . . . . . . 36
23.2. Informative References . . . . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction
A single-action authorization receipt is intentionally narrow: it
records approval of one exact action and can be accepted at most once
within its atomic consumption domain. Some agent deployments also
need a different primitive. For example, an operator may authorize
an agent to purchase a bounded class of supplies, subject to an
aggregate monetary ceiling and an expiry, without asking a human to
approve each conforming purchase.
That primitive has two inseparable parts:
1. a signed capability receipt that states the immutable authority
boundary; and
2. a shared, durable state machine that serializes reservations and
committed consumption across retries, processes, replicas, and
restarts.
The signed object without the state machine is replayable budget
metadata. The state machine without a signed, scoped grant has no
portable statement of authority. This document specifies their
composition.
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.
BCP 14 is indexed by the RFC Editor at [BCP14].
Schrock Expires 10 March 2027 [Page 3]
Internet-Draft EP Bounded Capabilities September 2026
1.2. Scope and Non-Goals
This document defines issuance binding, action-scope evaluation,
budget accounting, holder proof, durable reservation and commitment,
narrowing delegation, and an optional admission-control epoch inside
the authoritative state domain. It does not define user
authentication, human-approval presentation, general policy syntax,
payment clearing, settlement, currency conversion, revocation
distribution, or the external effect adapter.
A capability receipt is machine authority evidence. It is not,
merely by being signed, evidence that a human reviewed each later
action. Deployments that require per-action human authorization
continue to require a per-action authorization artifact.
When a capability may be exercised by more than one executor, every
executor MUST use the same relying-party-pinned authoritative atomic
state domain. A deployment that cannot enforce that binding MUST
restrict the capability to one executor or state only a per-executor
budget guarantee.
2. Terminology
Issuance authorization: An independently verified authorization
artifact for the exact act of creating a bounded capability.
Capability receipt: The signed immutable grant defined by this
document.
Capability issuer: The principal whose pinned key signs a capability
receipt.
Holder proof: Proof that the requester controls the secret or key
named by the capability receipt. Holder proof is not proof that a
requested action is in scope.
Scope verifier: A verifier for a named scope profile, selected and
configured by the relying party.
Capability store: The authoritative shared transactional state for
registration, reservation, and committed consumption.
State domain: The relying-party-pinned atomic store and trust
configuration to which every authority-bearing participant for a
capability lineage is bound. A state-domain identifier is
deployment context, not portable proof of global uniqueness.
Admission-control domain: An optional state-domain partition with
Schrock Expires 10 March 2027 [Page 4]
Internet-Draft EP Bounded Capabilities September 2026
authoritative active or frozen status and a monotonically
increasing admission epoch. This term is local execution-control
state. It is not the organizational-independence use of "control
domain" in evidence or witness profiles.
Admission epoch: The current monotonic version of an admission-
control domain, captured by a reservation and rechecked
immediately before provider entry.
Operation ID: An identifier unique for one attempted operation under
one capability receipt. The authoritative operation key is the
tuple of capability receipt digest and operation ID inside the
state domain.
Reservation token: An unguessable owner-fencing value returned by a
successful reservation and required for its commitment.
Provider-entry deadline: The authoritative instant before which a
reserved operation may enter the effect adapter. It is no later
than capability expiry.
Effect boundary: The point after which an external effect may have
occurred and therefore budget cannot safely be restored merely
because the caller did not receive a successful response.
Indeterminate outcome: An operation for which the executor cannot
prove that no effect occurred and cannot prove a successful
expected effect.
3. Trust Model
The relying party selects capability-issuer keys, accepted issuance
authorization profiles, scope profiles, state-store domain, and local
authorization policy. A key embedded in a presented capability
receipt MUST NOT, by itself, become a trust anchor. An empty trust
configuration MUST fail closed.
The capability store is trusted to serialize state transitions and
retain committed operation records. The effect adapter is trusted to
place the effect boundary correctly and to report outcomes honestly.
This protocol makes those trust dependencies explicit; it does not
remove them.
Schrock Expires 10 March 2027 [Page 5]
Internet-Draft EP Bounded Capabilities September 2026
All capability-store participants that can authorize a capability or
allocate, register, reserve, commit, reconcile, revoke, or report any
ancestor or descendant drawing on that capability's authority MUST
use one shared authoritative atomic state domain. Independent stores
cannot prevent each other from accepting or reallocating the same
remaining authority. Conservation claims in this document apply only
inside that one domain.
A deployment may have multiple executor instances, settlement
adapters, or process replicas. If they can exercise the same
capability, each MUST resolve the same state domain before admission
and use that domain for the budget transition. An executor's local
record of prior spending is not an authoritative aggregate record.
If the deployment cannot make the shared-domain guarantee, it MUST
either name exactly one executor in the applicable scope or describe
the limit as per-executor and MUST NOT claim aggregate conservation
across executors.
When the admission-control epoch profile in this document is used,
the domain status, epoch, capability state, applicable allowance
status, and operation state MUST be serialized in the same
authoritative transaction domain. A cached or freshness-bounded
status check outside that transaction cannot establish immediate
freeze behavior.
4. The Bounded Capability Receipt
The receipt is a JSON object serialized using the JSON
Canonicalization Scheme (JCS) [RFC8785] before signing. The
following is illustrative:
Schrock Expires 10 March 2027 [Page 6]
Internet-Draft EP Bounded Capabilities September 2026
{
"@version": "EP-BOUNDED-CAPABILITY-v1",
"capability": {
"capability_id": "cap_01J...",
"issuer": "https://operator.example",
"subject": "agent:procurement-7",
"authorization": {
"receipt_id": "rcpt_01J...",
"receipt_digest": "sha256:4c..."
},
"scope": {
"profile": "urn:emilia:scope:caid-set-v1",
"value": {
"caids": ["caid1:sha256:..."]
},
"digest": "sha256:8a..."
},
"budget": {
"amount": 250000,
"unit": "iso4217:USD",
"scale": 2
},
"holder": {
"method": "sha-256-preimage",
"commitment": "sha256:91..."
},
"threshold": {"m": 2, "n": 3},
"revocation_mode": "cascade",
"parent": null,
"not_before": "2026-07-18T20:00:00Z",
"expires_at": "2026-07-19T20:00:00Z"
},
"capability_signature": {
"algorithm": "Ed25519",
"public_key": "base64url...",
"value": "base64url..."
}
}
4.1. Required Fields
@version: EP-BOUNDED-CAPABILITY-v1.
capability_id: A globally unique, opaque identifier. Uniqueness is
not used as a substitute for cryptographic binding.
issuer: The issuer identifier used to select a relying-party-pinned
verification key.
Schrock Expires 10 March 2027 [Page 7]
Internet-Draft EP Bounded Capabilities September 2026
subject: The intended holder or workload identifier. This
identifier does not replace holder proof or live workload
authentication.
authorization: The identifier and SHA-256 digest of the complete
issuance authorization artifact. The digest MUST cover the exact
bytes accepted by that artifact's native verifier.
scope: A named scope profile, its value, and the SHA-256 digest of
the JCS serialization of profile and value.
budget: A non-negative integer amount no greater than
9007199254740991, an explicit unit, and a decimal scale from 0
through 18. For iso4217:USD with scale 2, an amount of 250000
denotes USD 2500.00. Implementations MUST NOT infer a scale from
display conventions. The represented value is amount * 10^-scale;
increasing scale therefore reduces the maximum representable
major-unit value. A profile MUST refuse an amount-and-scale
combination that cannot represent its declared operating range.
This version does not encode arbitrary-precision decimal values.
holder: A recognized holder-proof method and its method-specific
commitment.
threshold: Integers m and n satisfying 1 <= m <= n <= 255. This
field describes custody of the holder credential; it does not
assert approval by distinct humans.
revocation_mode: Exactly direct or cascade. A direct revocation
affects the named capability but does not withdraw authority
already transferred to a registered child. A cascade revocation
also blocks new authority claims by every descendant. The value
is signed and MUST NOT be inferred from the issuer, holder,
lineage depth, or a presenter-selected default. A missing or
unknown value MUST be rejected.
parent: null for a root capability. For a child capability, an
object containing the parent capability ID, the digest of the
complete signed parent receipt, and the identifier of an
authenticated parent delegation operation. That operation MUST
bind the child receipt digest and the delegated amount, unit,
scale, scope, validity interval, and revocation mode. A parent
identifier without digest-bound parent and delegation evidence is
insufficient.
not_before and expires_at: UTC timestamps in Internet Date/Time
Schrock Expires 10 March 2027 [Page 8]
Internet-Draft EP Bounded Capabilities September 2026
format [RFC3339] using the canonical string form selected by the
deployment profile. Expiry is exclusive. Numeric epochs,
implementation-specific date strings, and values that do not
round-trip to the canonical form MUST be rejected.
4.2. Signature Input and Receipt Digest
The issuer signature input is the JCS serialization of the object
containing exactly @version and capability. The signature algorithm
for this version is Ed25519 [RFC8032]. The receipt digest is:
SHA-256(JCS({
"@version": receipt["@version"],
"capability": receipt.capability,
"capability_signature": receipt.capability_signature
}))
The issuance authorization is bound by both its identifier and
digest. Binding only a caller-selected receipt identifier is
insufficient because two different artifacts can carry the same
identifier.
4.3. Receipt Verification
A verifier MUST perform all of the following and fail closed on any
error:
1. apply bounded parsing and reject duplicate JSON member names,
unknown critical versions, malformed encodings, and out-of-range
values;
2. select the issuer key from relying-party configuration, not from
the presented object alone;
3. verify the issuer signature over the exact signature input;
4. natively verify the issuance authorization under its own pinned
trust inputs and compare both receipt identifier and digest;
5. verify that the authorized action is issuance of this exact
capability object, or of a digest that commits to it;
6. verify the scope digest and require a recognized, relying-party-
enabled scope profile;
7. verify the validity interval and, for a child, resolve and verify
the digest-bound parent lineage to a root capability or a locally
trusted, previously validated lineage checkpoint. Reject an
Schrock Expires 10 March 2027 [Page 9]
Internet-Draft EP Bounded Capabilities September 2026
unresolved, truncated, reordered, or substituted link; a repeated
capability ID or receipt digest; the leaf appearing among its
ancestors; or a path exceeding deployment policy. At every hop,
verify that the child amount does not exceed the authenticated
delegated amount, unit and scale are unchanged, validity is
contained by the parent, and scope is no broader than the parent
scope; and
8. compute the capability receipt digest used for store
registration.
Receipt verification returns VERIFIED. It does not return
AUTHORIZED, prove remaining budget, or prove that a proposed
operation is in scope.
5. Issuance Authorization
The issuance authorization MUST authorize the act of creating the
capability, including the immutable digest of its subject, scope,
budget, holder commitment, revocation mode, parent, and validity
interval. It MUST NOT be reused as though it were a per-operation
authorization for later spends.
When the issuance artifact is an EMILIA Authorization Receipt, its
exact action is capability issuance and its one-time consumption
occurs when the capability is registered. Later capability-funded
operations are governed by this document's scope and durable state
protocol.
6. Per-Action Human Authorization Composition
A deployment may require a separately authenticated human
authorization for an individual capability-funded exercise. That
artifact MUST bind the exact canonical exercise-action digest used by
reservation and effect admission. If material terms are not
committed by that digest, the artifact MUST bind those terms
independently.
A capability signature, holder proof, threshold custody, or key
protected inside a workload is not evidence that a human reviewed the
later exercise. The capability verifier and human-authorization
verifier may remain separate. A relying-party composition policy may
require both results for the same action digest, but the two
verifiers MUST NOT treat the other's evidence as a trust anchor.
Schrock Expires 10 March 2027 [Page 10]
Internet-Draft EP Bounded Capabilities September 2026
This composition does not make human authorization part of every
bounded capability. A deployment that permits conforming exercises
without a per-action human artifact MUST state that the issuance
authorization established the bounded class rather than a human
reviewing each later action.
7. Action Scope
Before reserving budget, the enforcement point MUST compute the
proposed material action independently of presenter-supplied labels
and invoke the pinned verifier for scope.profile. A missing profile,
unknown action representation, lossy mapping, or indeterminate
comparison MUST refuse.
The mandatory-to-implement urn:emilia:scope:caid-set-v1 profile
contains a non-empty, duplicate-free array of Canonical Action
IDentifiers. It matches only exact identifier equality. For
delegation, a child CAID set is no broader than its parent only when
every child identifier is an exact member of the parent set.
Equality of the complete sets is allowed. This non-strict subset
relation is reflexive and transitive. Possession of a CAID
authorizes nothing outside this verified capability context.
Application profiles can define closed constraints over typed action
fields. Such a profile MUST specify canonicalization, exact value
equality, comparison, unknown-field handling, numerical units, and an
algorithm for deciding whether a delegated scope is no broader than
its parent. The profile MUST state whether that attenuation relation
is reflexive and whether it is transitive. It MUST classify the
basis for any transitivity claim as one of: definition-derived,
mechanically-checkable, or asserted. A mechanically checkable claim
MUST define a finite domain and deterministic procedure by which a
verifier or conformance suite can enumerate the required triples. An
asserted claim is profile-author testimony, not a demonstrated
algebraic property.
Every profile identifier used in a signed scope MUST identify
immutable comparison semantics. An identifier fixed by immutable
standards text satisfies this requirement. Any other application-
profile identifier MUST be content-addressed. A mutable alias or
version label alone is insufficient. The relying party MUST pin the
exact profile definition selected by that identifier and refuse if
the definition cannot be resolved without ambiguity or has changed.
Action membership and attenuation are separate decisions. Membership
returns IN_SCOPE, OUT_OF_SCOPE, or INDETERMINATE. Attenuation
returns NO_BROADER, BROADER, or INDETERMINATE. A composite scope is
no broader only when every mandatory component returns NO_BROADER.
Schrock Expires 10 March 2027 [Page 11]
Internet-Draft EP Bounded Capabilities September 2026
Any BROADER component makes the composite broader; otherwise any
undecided component makes the composite indeterminate. Missing
components MUST NOT be treated as successful comparisons.
A verifier MUST NOT promote per-hop comparisons into a chain-wide
non-widening claim unless transitivity is either derived from the
relation definition or mechanically established over the profile's
complete declared finite domain. A comparison under a non-
transitive, asserted-transitive, or unknown-transitivity relation is
local to the reported hop. It can be useful evidence, but it does
not compose by induction across a delegation chain.
A definition-derived classification is permitted only when the
immutable profile definition specifies a relation whose transitivity
follows by construction. Merely labeling a relation transitive,
including in authenticated profile metadata, is an asserted basis.
For a mechanically established classification, every scope value used
in the composed chain MUST be a member of the exact finite domain
covered by the establishment record. A value outside that domain
makes the mechanical result inapplicable to that chain.
For a mechanically established result, the verifier MUST disclose
whether it performed the complete enumeration itself or relied on a
prior conformance run. The establishment record MUST identify the
runner, completion time, immutable profile and relation-rule
identifiers and content digests, the canonical encoding, digest
algorithm, digest, and cardinality of the complete declared finite
domain, the deterministic procedure identifier, version, and content
digest, and the result. A verifier relying on a prior run MUST
authenticate and integrity-check that record and MUST accept the
runner under relying-party-pinned trust policy. A self-authenticated
or otherwise untrusted runner is insufficient. If the record is
unavailable, invalid, untrusted, or does not cover the pinned
profile's complete declared finite domain, the verifier MUST NOT use
it for chain composition. A current per-hop comparison may still be
reported local-only. This requirement does not require enumeration
at admission time.
A verifier relying on a prior run MUST compare the establishment
record's profile and relation-rule content digests, complete-domain
encoding, digest algorithm, digest, and cardinality, and
deterministic procedure identifier, version, and content digest with
the exact profile, rule, domain, and procedure selected for the
current evaluation. A mutable version label without an immutable
content binding is not an exact match. A mismatch, or an inability
to perform that comparison, makes the record stale for this
evaluation. Authenticated integrity proves what the earlier run
reported; it does not establish that the earlier result remains
Schrock Expires 10 March 2027 [Page 12]
Internet-Draft EP Bounded Capabilities September 2026
applicable after a profile, rule, domain, or procedure revision. A
stale record MUST NOT support a chain-wide non-widening claim and
contributes no current comparison result. A verifier may report
local-only only after it separately performs the current per-hop
comparison; if it cannot do so, it MUST report INDETERMINATE.
Reliance on an authenticated, matching prior conformance run is
deliberately permitted. This document assigns no automatic trust
rank to verifier-performed enumeration and relied-on enumeration; the
disclosed reliance mode lets the relying party apply its own policy.
Implementations SHOULD NOT repeat an otherwise acceptable complete
enumeration solely to avoid reporting the relied-on mode.
For each mandatory component of a delegation path containing more
than one edge, every adjacent comparison used for a chain-wide claim
MUST use the same immutable profile definition, relation-rule
definition, finite-domain identity where applicable, and transitivity
basis. Transitivity established separately for two different
relations does not prove that those relations compose. This document
defines no cross-relation composition rule. A path that changes any
of those relation inputs is local-only across that boundary.
A local-only report may be retained as diagnostic evidence, but it
MUST NOT establish descendant authority across a path of more than
one delegation edge. Registration or admission of that descendant
MUST refuse when the current comparison is broader and MUST refuse or
return INDETERMINATE when chain composition cannot be established. A
single delegation edge requires a current successful local comparison
but does not require transitive induction.
Scope comparison is evaluated per component and relative to the
verifier that produced it. A comparison report MUST record each
component, the deciding verifier, the pinned profile and rule, the
values compared, the local result, whether the relation is reflexive,
the transitivity classification and basis, any mechanical
establishment record and reliance mode, and whether the result is
local-only or chain-composable. An undecided result MUST distinguish
a component for which no order is defined from one whose governing
profile was unavailable to that verifier. Mandatory-profile
components MUST be reported rather than assumed. A structural chain
result and a scope comparison result MUST NOT be combined into an
overall validity claim unless both reports, including their
decidability and composition limits, travel with the claim.
Profiles that intentionally use a non-reflexive relation MUST state
that an unchanged scope will be refused. Profiles that cannot decide
either action membership or attenuation MUST return INDETERMINATE.
Schrock Expires 10 March 2027 [Page 13]
Internet-Draft EP Bounded Capabilities September 2026
8. Holder Proof and Threshold Custody
The mandatory-to-implement holder method is sha-256-preimage. The
holder presents exactly 32 bytes over a confidential, integrity-
protected channel, and the enforcement point compares SHA-
256(preimage) with the signed commitment using a constant-time
comparison. The preimage MUST NOT be logged, stored with the
receipt, or included in portable evidence.
This method is intentionally a bearer-equivalent interoperability
baseline. Any party that learns the preimage can exercise the
remaining capability subject to its scope, budget, status, and
validity. A deployment whose threat model requires non-exportable
holder custody or per-operation proof of possession SHOULD select an
operation-bound signature method, such as the method below, or an
application profile defining a hardware-bound holder method. Those
stronger properties MUST NOT be inferred from the preimage method.
This version additionally defines ed25519-operation-proof. For that
method, holder.commitment is the lowercase sha256:<64-hex> digest of
the 32-byte Ed25519 public key. The exercise proof carries that raw
public key and a 64-byte Ed25519 signature, each encoded as unpadded
base64url [RFC4648]. The verifier MUST decode both values strictly,
compare the public key digest with the signed holder commitment, and
verify the signature over the UTF-8 JCS serialization of this closed
object:
{
"@version": "EP-BOUNDED-CAPABILITY-HOLDER-PROOF-v1",
"capability_receipt_digest": "sha256:<64-hex>",
"operation_id": "<operation identifier>",
"exercise_action_digest": "sha256:<64-hex>",
"amount": 1,
"unit": "<signed budget unit>",
"scale": 0,
"audience": "<relying-party-pinned executor audience>",
"state_domain_digest": "sha256:<64-hex>"
}
Every value in that object MUST be taken from the independently
verified receipt, immutable exercise snapshot, and relying-party
configuration used by the reservation. Presenter-supplied
replacements MUST NOT be accepted. Replaying the same signed request
is refused by the capability-scoped operation key; changing the
operation ID, action, amount, unit, scale, audience, or state domain
requires a new signature. This proof establishes control of the
committed key for that reservation request. It does not establish a
human gesture, comprehension, or approval ceremony.
Schrock Expires 10 March 2027 [Page 14]
Internet-Draft EP Bounded Capabilities September 2026
For ed25519-operation-proof, the portable threshold value MUST be
m=1, n=1. Threshold or hardware custody behind the committed Ed25519
public key is an implementation property and does not become a
portable multi-party or human-approval claim.
The preimage may be divided using a threshold secret-sharing scheme
before presentation. Share format, participant authentication,
confidentiality, recovery, and distribution are outside this
document. Reconstructing m shares proves control of the holder
secret; it does not prove that m distinct humans reviewed or approved
the action. Human multi-party approval requires a protocol such as
[EP-QUORUM].
9. Registration
After receipt verification and one-time consumption of the issuance
authorization, the issuer registers the capability in the
authoritative store. Registration MUST atomically create immutable
fields for capability ID, receipt digest, unit, scale, total budget,
scope digest, validity interval, revocation mode, and parent. It
MUST initialize consumed and reserved to zero.
A second registration of the same capability ID MUST succeed only
when every immutable field and receipt digest is identical. Any
mismatch is a collision and MUST refuse.
Consumption of the issuance authorization and registration of its
exact capability receipt MUST form one idempotent logical operation
bound to the capability receipt digest. If both transitions cannot
share one atomic state transaction, the issuance-authorization
consumption record MUST identify the registration operation and exact
capability receipt digest, and both domains MUST retain enough state
to query and reconcile an ambiguous result. A crash after
consumption MUST NOT permit the authorization to issue a different
capability or to be silently restored.
A deployment using separate domains for those two transitions MUST
identify a concrete reconciliation profile that defines its durable
states, authenticated queries, exact-digest join, retry behavior, and
terminal ambiguous result. In the absence of such a profile,
consumption and registration MUST occur in one authoritative atomic
state transaction.
Retry of that registration may return the existing identical
capability only after verifying the same issuance-consumption record.
An absent or conflicting record MUST refuse or return INDETERMINATE;
it MUST NOT create a second root capability from uncertain issuance
state.
Schrock Expires 10 March 2027 [Page 15]
Internet-Draft EP Bounded Capabilities September 2026
Mutable counters in a presented receipt are not authoritative.
Remaining budget is computed only from the shared store:
remaining = total - consumed - reserved
The authoritative state MUST maintain the invariant reserved +
consumed <= total for every capability. For a parent capability,
each registered child allocation MUST be covered by one or more
distinct terminal delegated operation committed against that parent
before child registration. The aggregate amount of registered direct
children MUST NOT exceed the amount committed by those distinct
parent delegation operations, and each operation identifier MUST NOT
fund more than one child receipt digest.
10. Reserve, Admit, and Reconcile
10.1. Reserve
A reservation request contains the capability ID, capability receipt
digest, operation ID unique under that capability, the immutable
canonical exercise-action digest and CAID where used, positive
integer amount, unit, scale, and authenticated holder proof. The
same immutable action snapshot MUST be used for scope evaluation,
authorization, reservation accounting, and the effect callback; a
mutable caller object MUST NOT cross those boundaries. Validity and
expiry MUST be evaluated from one authoritative time sample obtained
inside the same state transaction; caller-supplied time is not
authoritative. The relying party MUST pin a positive maximum pre-
entry reservation interval. The store MUST derive and record a
provider-entry deadline equal to the earlier of capability expiry and
that authoritative transaction time plus the pinned interval. When
the admission-control epoch profile is enabled, the store MUST first
load and lock the selected admission-control domain, require status
active, and capture its current epoch in the operation record. In
one serializable transaction, or while holding an equivalent row
lock, the store MUST:
1. load the registered capability and compare the receipt digest;
2. resolve the complete authority-bearing ancestor lineage in the
same authoritative state domain and reject unavailable,
inconsistent, or truncated state;
3. reject an unknown, not-yet-valid, expired, or revoked capability;
4. reject when any revoked ancestor has revocation_mode equal to
cascade;
Schrock Expires 10 March 2027 [Page 16]
Internet-Draft EP Bounded Capabilities September 2026
5. reject a unit or scale mismatch;
6. reject any already-seen operation key for that capability,
regardless of its previous outcome;
7. verify that the amount is positive and no greater than total -
consumed - reserved;
8. increase reserved by the amount; and
9. create an operation in state reserved with an unguessable
reservation token, exercise-action digest, amount, and provider-
entry deadline, plus the admission-control domain and captured
epoch when that profile is enabled, and return the token only to
the owner.
Scope evaluation and local authorization policy MUST succeed before
the effect adapter is entered. Deployments SHOULD perform them
before reserving to reduce abandoned reservations.
10.2. Effect Boundary
The enforcement point enters the effect adapter only after a
successful reservation. It MUST NOT expose an alternate path to the
same effect that bypasses capability enforcement when the action
requires this profile.
Immediately before provider entry, the store MUST atomically verify
reservation ownership, verify that its authoritative transaction time
is earlier than the recorded provider-entry deadline, and recheck
current capability and applicable allowance state. This check MUST
recheck direct revocation and every authority-bearing cascade-mode
ancestor in the same atomic state domain, as specified in
Section 12.1. A reservation does not freeze revocation status. When
the admission-control epoch profile is enabled, the same transaction
MUST require domain status active and equality between the current
epoch and the epoch captured at reservation. On success, that
transaction MUST record that provider entry has begun, decrease
reserved, and increase consumed by the same amount before the effect
adapter is invoked. A reservation that has reached its deadline MUST
NOT enter the effect adapter. A serialized absence of the provider-
entry marker after the deadline is authoritative proof of non-entry
and may drive the not_entered transition in Section 10.4.
A frozen domain, epoch mismatch, capability revocation, or current
allowance refusal can establish not_entered only when the same
transaction authenticates the reservation owner and proves that the
operation remains reserved. It then decreases reserved without
Schrock Expires 10 March 2027 [Page 17]
Internet-Draft EP Bounded Capabilities September 2026
increasing consumed and retains the operation as a replay tombstone.
A wrong holder, missing authoritative state, or conflicting operation
state MUST NOT release another owner's reservation or assert non-
entry. It must refuse provider entry and retain the operation for
authenticated recovery.
10.3. Commit
For an external effect, a commit request contains the operation ID,
reservation token, and outcome executed or indeterminate. In one
atomic transaction, the store MUST verify ownership and state
provider_entered and make the operation terminal. It MUST NOT debit
the budget again; the reserved amount became consumed at provider
entry.
A delegated operation does not enter an external effect adapter. Its
atomic terminal transition verifies ownership and state reserved,
rechecks the funding capability's direct revocation and every
authority-bearing cascade-mode ancestor, decreases reserved,
increases consumed by the same amount, and binds the child
registration described in Section 12. This funding commitment is the
authority-transfer cutoff for a delegated operation. If applicable
revocation commits first, the store MUST refuse the transfer and may
release the reservation only after authenticating its owner and
proving that no child authority was committed. If the funding
commitment commits first, its debit remains consumed; subsequent
child use follows the signed direct or cascade mode. Retrying child
registration for that same committed transfer does not create another
allocation or reopen the parent debit.
A repeated commit, wrong reservation token, or external-effect commit
against an operation not in provider_entered MUST refuse. A caller
timeout does not justify retrying with a new operation ID; the caller
MUST query the original operation or reconcile it.
If the executor cannot prove that the effect boundary was not
crossed, it MUST commit indeterminate. The budget remains consumed
from provider entry. Availability loss is safer than allowing the
same authority to be spent again after an unobserved external effect.
Capability expiry or the provider-entry deadline prevents a new
provider entry; it does not invalidate accounting for an operation
that entered the provider beforehand. Such an operation MUST remain
committable or reconcilable after those instants. This closes an
already admitted attempt and does not extend authority to begin
another effect.
Schrock Expires 10 March 2027 [Page 18]
Internet-Draft EP Bounded Capabilities September 2026
10.4. Crash Recovery and Reconciliation
Reservations survive process and replica failure. A deployment MUST
define a reconciler for non-terminal operations. The reconciler may
commit executed only with authenticated effect evidence. It may
restore budget only when it can prove the effect boundary was never
crossed while the operation remains reserved. An operation in
provider_entered has already consumed its budget and MUST NOT restore
it merely because outcome evidence is unavailable. In every other
case it MUST commit indeterminate.
When non-entry is proved, the store MUST use one atomic transition to
verify the reservation owner and exact action, decrease reserved
without increasing consumed, and make the operation terminal with
outcome not_entered. The operation key and its action binding MUST
remain as a replay tombstone after budget restoration. A later
presentation of that operation key MUST NOT create a new reservation.
Repeated reconciliation is idempotent only for the same terminal
outcome and authenticated evidence binding.
11. Executor and State-Domain Binding
The state domain is a relying-party trust input. A portable
capability receipt need not embed a globally meaningful domain
identifier, but the registration and operation records SHOULD
identify the domain and executor participant used for each admission
so that a relying party can detect an unsupported state fork.
When multiple executors are authorized to present one capability, the
store MUST serialize their reservations and commitments in one
domain. Merely replicating a signed receipt, copying a remaining
counter, or exchanging eventual spending logs does not satisfy this
requirement. A deployment that uses independent stores may still use
signed receipts, but it MUST NOT describe the resulting behavior as
one aggregate budget.
A scope that names one executor is a valid narrower deployment
choice. The applicable scope profile MUST define how that executor
participant is identified and compared at admission. This removes
the cross-executor guarantee requirement; it does not turn a local
record into a global budget or provide offline double-spend
prevention.
Schrock Expires 10 March 2027 [Page 19]
Internet-Draft EP Bounded Capabilities September 2026
11.1. Admission-Control Epoch and Emergency Freeze
A deployment MAY partition one authoritative state domain into
admission-control domains. A freeze is an exact-action-authorized,
idempotent transition that changes one domain from active to frozen
and advances its admission epoch. The transition MUST serialize
against both reservation and provider entry. A freeze that commits
before reservation refuses that reservation. A reservation that
commits first remains owned, but a freeze that commits before its
provider entry causes authenticated non-entry and budget release.
Provider entry that commits first has consumed the authority and
cannot be relabeled by the freeze.
An idempotent freeze retry MUST authenticate the request before
revealing a prior result and MUST match the admission-control domain,
event type, exact action digest, operation identifier, and authority-
instance digest of the committed transition. The operation
identifier is not a bearer token. A conflicting authority instance
or action under the same identifier MUST refuse without returning the
prior result.
For an exact retry, authentication means verifying the same signed
authority instance and exact control action that the committed record
names. The retry remains resolvable after that authority instance
has been consumed or has expired; it does not require unused budget
and MUST NOT consume again. A new freeze transition requires
currently valid authority and atomically consumes its configured unit
in the same state-domain transaction that advances the epoch. A
distinct authorized request received while the domain is already
frozen reports already_frozen without advancing the epoch or
appending another transition event.
When an automated detector uses a bounded capability to request a
freeze, its scope MUST identify the admission-control domains it can
freeze, its action scope MUST be limited to the freeze transition,
and its budget and validity MUST be finite. That capability MUST NOT
authorize restoration. Exhaustion refuses a new automatic freeze;
paging or escalation is a separate operational action whose delivery
and human acknowledgment must not be inferred from transport
acceptance.
Restoration is a separately authorized transition from frozen to
active that advances the epoch again. It MUST NOT revive a
reservation captured under an earlier epoch or automatically recreate
credentials revoked during the freeze. Evidence bound to an
operation that entered before the freeze remains usable only to
reconcile that immutable operation.
Schrock Expires 10 March 2027 [Page 20]
Internet-Draft EP Bounded Capabilities September 2026
This profile stops new admission inside the owning atomic state
domain. It does not stop computation, undo an external effect, or
provide instant freeze across a disconnected state domain. A leased
edge profile must state the maximum stale-admission window as the
remaining lease lifetime plus the declared relative clock uncertainty
and local enforcement delay.
12. Narrowing Delegation
A child capability MUST NOT outlive its parent, exceed the
authenticated amount delegated from the parent, change unit or scale,
or broaden the parent's scope. Its delegation chain MUST be bounded
by deployment policy and MUST include the parent receipt digest.
Before registering a child, the verifier MUST validate complete
digest-linked ancestry to a trusted root within the configured depth
bound, or enforce equivalent authenticated parent-edge constraints in
one authoritative store. The verified lineage MUST form a simple
path. The verifier MUST reject a repeated capability identifier or
receipt digest, a missing or inconsistent parent, a substituted or
reordered edge, or a chain whose trusted root cannot be established.
A cycle, truncated lineage, or over-depth chain MUST fail closed.
Per-receipt identifier uniqueness or a self-declared list of
ancestors does not establish graph-wide acyclicity. An
implementation MUST NOT infer acyclicity merely because its ordinary
issuance path constructs children from known parents; verification
applies the same check to imported and reconstructed chains.
Creating a child is itself a parent-funded operation. Before
registering the child, the issuer MUST reserve the delegated amount
from the parent and MUST commit that exact reservation once with
outcome delegated. The authenticated terminal operation record MUST
bind the exact child receipt digest, delegated amount, unit, scale,
scope, validity interval, and revocation mode before the child is
registered; otherwise a valid parent spend could be paired with a
different child. A shared store SHOULD perform parent commitment and
child registration atomically. If that is impossible and child
registration fails after the parent is committed, the parent budget
remains consumed and the orphaned delegation MUST be retained for
reconciliation. The system MUST NOT silently refund it.
12.1. Revocation Inheritance Across Delegation Lineage
Delegation transfers bounded authority rather than leaving every
child as a live reference to its parent. Direct revocation of an
ancestor therefore does not, by itself, determine whether authority
already transferred to registered descendants survives. The signed
revocation_mode field makes that choice explicit.
Schrock Expires 10 March 2027 [Page 21]
Internet-Draft EP Bounded Capabilities September 2026
When a capability's revocation_mode is direct, revoking that
capability MUST prevent new reservations and child allocations funded
by that capability. It MUST NOT, solely because of that revocation,
invalidate a child registered before the revocation committed. The
child remains subject to its own validity, scope, budget, direct
revocation, and any cascade-mode ancestor.
When a capability's revocation_mode is cascade, revoking that
capability MUST prevent every descendant from making a new
reservation or funding a new child. The enforcement point MUST
establish the current revocation state of every authority-bearing
cascade-mode ancestor in the same authoritative atomic state domain
used for the descendant reservation. A cached status value or
eventually consistent notification does not establish immediate
cascade revocation.
Direct revocation of the exercised capability and revocation of every
authority-bearing cascade-mode ancestor MUST serialize with both
reservation and provider entry in that state domain. Revocation that
commits first prevents a new reservation. Revocation that commits
after reservation but before provider entry MUST prevent entry. Only
the authenticated reservation owner may establish not_entered,
release the held amount, and retain the replay tombstone under
Section 10.2. If provider entry commits first, later revocation
prevents new authority claims but MUST NOT release consumed
authority, relabel an effect, or authorize a retry. An unresolved
effect remains subject to Section 10.4.
This entry-time rule does not change direct-mode descendant
independence. Revocation of a direct-mode ancestor alone does not
invalidate a previously registered descendant; the descendant's own
revocation and every cascade-mode ancestor still apply.
If complete current ancestor state cannot be established before
reservation or provider entry, the request MUST refuse without
entering the effect adapter. Missing status alone does not authorize
release of an existing reservation; retain it for authenticated
recovery unless the store separately proves non-entry. This is a
pre-effect status failure, not evidence that an external effect is
indeterminate. A deployment using separate state domains or
freshness-bounded status distribution MUST NOT claim immediate
cascade revocation across those domains.
Neither mode grants a grace period after revocation. Continued or
wind-down authority MUST be established by a separate authorization
with its own exact scope, budget, holder, and validity interval; it
MUST NOT be inferred from an in-flight delegation. This document
defines the consequence of an authenticated revocation within one
Schrock Expires 10 March 2027 [Page 22]
Internet-Draft EP Bounded Capabilities September 2026
state domain. It does not define who is entitled to revoke, how
revocation is distributed, or how independently operated domains
transfer exclusive admission ownership.
13. Evidence and Decision Vocabulary
A capability receipt can be VERIFIED. A scope verifier can return
the profile-local result IN_SCOPE, OUT_OF_SCOPE, or INDETERMINATE.
This containment result is not the architecture's MATCH state, which
is reserved for correlation of exact material actions. A relying-
party evidence requirement can be SATISFIED. Successful local policy
and an atomic reservation together can establish AUTHORIZED for one
exercise. Separately authenticated effect evidence can establish
EXECUTED. No earlier state implies a later one.
Portable evidence for a capability-funded operation SHOULD include
the capability receipt digest, issuance authorization digest, scope
profile and digest, operation ID, the exact exercise action digest
and CAID where used, amount, unit, scale, reservation timestamp,
terminal outcome, and any authenticated effect statement. The
integrity-protected operation record MUST bind the exercise action
and the capability receipt digest. Holder secrets and reservation
tokens MUST NOT be included.
An Authorization Evidence Chain may carry that operation record as a
native component whose verifier recursively verifies the capability
receipt, issuance authorization, scope result, and operation-record
integrity. The static grant is not a same-action component for every
later exercise. Evidence satisfaction does not query or reserve
current budget; that state transition remains at the enforcement
point.
14. Failure Codes
Implementations SHOULD expose stable, non-authorizing failure codes
including:
* capability_untrusted_issuer
* capability_authorization_mismatch
* capability_scope_mismatch
* capability_scope_indeterminate
* capability_holder_proof_invalid
* capability_not_active
Schrock Expires 10 March 2027 [Page 23]
Internet-Draft EP Bounded Capabilities September 2026
* capability_expired
* capability_revoked
* capability_revocation_mode_invalid
* capability_ancestor_revoked
* capability_ancestor_status_unavailable
* capability_budget_exceeded
* capability_delegation_lineage_invalid
* capability_delegation_not_narrowed
* capability_operation_replay
* capability_reservation_owner_mismatch
* capability_reservation_expired
* capability_commit_indeterminate
A failure code is diagnostic output, not an authorization artifact.
Responses SHOULD avoid revealing secret, budget, or scope details to
an unauthenticated caller.
15. Conformance
A conforming implementation MUST pass positive and adversarial
vectors for receipt canonicalization and signature, authorization-
digest substitution, untrusted issuer, unknown scope profile, action
mismatch, holder-proof failure, duplicate registration, concurrent
overspend, operation replay, wrong reservation token, double commit,
expiry, a cycle spread across separately signed receipts, repeated
ancestors, leaf-as-ancestor, missing or truncated lineage, reordered
or substituted parent links, parent-receipt and delegation-operation
substitution, a single-hop child exceeding the authenticated
delegated amount, unit or scale changes, scope or validity widening
at every hop, over-depth chains, parent over-allocation, crash
recovery, and indeterminate-effect charging.
The conformance set MUST exercise revocation inheritance over a root,
child, and grandchild. It MUST show that direct-mode revocation
leaves previously registered descendant authority independently
usable, while cascade-mode revocation refuses every later descendant
reservation and child allocation. It MUST reject a missing or
Schrock Expires 10 March 2027 [Page 24]
Internet-Draft EP Bounded Capabilities September 2026
unknown revocation_mode, refuse when required ancestor state is
unavailable, and cover a race between ancestor revocation and
descendant reservation in which exactly one transition commits first.
A reservation that commits first remains owned pending the separate
provider-entry decision; a revocation that commits first prevents the
reservation.
The conformance set MUST test reserve, revoke, then provider entry
for both direct leaf revocation and inherited cascade revocation.
Both cases MUST refuse entry and permit budget release only through
authenticated not_entered with a retained replay tombstone. It MUST
also test provider entry before revocation: the amount remains
consumed and outcome reconciliation remains available without re-
execution. A direct-mode ancestor revocation alone MUST NOT refuse
an otherwise valid descendant's entry. Missing ancestor status and
wrong-holder recovery attempts MUST NOT silently release another
owner's reservation.
The conformance set MUST also serialize applicable revocation against
a delegated funding commitment after reservation. Revocation first
refuses the new allocation; commitment first preserves the parent
debit and applies the signed revocation mode to subsequent child use.
Neither registration retries nor revoked child use restore or
duplicate the parent allocation.
The conformance set MUST also include multiple executor participants
sharing one domain, an independent-store state fork, and a scope
restricted to one executor; only the shared-domain case may claim one
aggregate budget.
The scope-profile conformance set MUST show exact CAID equality and
non-strict subset attenuation, including unchanged parent and child
sets. For a profile whose relation is mechanically checkable, it
MUST enumerate the complete declared finite domain and test
reflexivity and transitivity. It MUST also include a relation that
passes every adjacent hop but fails transitivity, and demonstrate
that the verifier labels those hop results local-only and refuses to
claim chain-wide non-widening. An asserted-transitive profile MUST
NOT be reported as demonstrably transitive. The set MUST cover both
a verifier-performed enumeration and reliance on an authenticated
prior conformance run, and MUST refuse chain-wide promotion when that
prior record is unavailable, invalid, or does not cover the complete
declared finite domain.
The conformance set MUST include an authenticated prior record that
differs from the current evaluation in the profile or rule content
digest, complete-domain encoding, digest algorithm, digest or
cardinality, or deterministic procedure identifier, version or
Schrock Expires 10 March 2027 [Page 25]
Internet-Draft EP Bounded Capabilities September 2026
content digest, and demonstrate that every such mismatch prevents
chain-wide promotion. It MUST show that a stale record contributes
no current local result, while a separately executed current
comparison can still be reported local-only. It MUST also
demonstrate that a matching prior record can support chain
composition without repeating the enumeration, subject to relying-
party policy.
The conformance set MUST reject an establishment record from an
authenticated but untrusted runner, a record using the same mutable
version label over different profile or rule content, a chain value
outside the mechanically enumerated domain, and a multi-hop chain
whose adjacent comparisons use different relations that are each
independently transitive. It MUST demonstrate that a local-only
multi-hop result cannot establish descendant authority.
The conformance set MUST cover a crash between issuance-authorization
consumption and root-capability registration, an exact retry that
resolves to the existing capability, and a conflicting retry that
refuses. It MUST also show that authenticated proof of provider non-
entry restores reserved budget while retaining a terminal replay
tombstone, and that the same raw operation ID under a different
capability is not by itself a replay. Reservation-lifetime cases
MUST show refusal of provider entry at the deadline, recovery of an
abandoned pre-entry reservation after the deadline, and successful
terminal accounting after capability expiry for an operation whose
provider entry was recorded beforehand. A split-domain root
registration case MUST identify and exercise its concrete
reconciliation profile; without one, the case MUST refuse the split
deployment.
When the admission-control epoch profile is supported, the
conformance set MUST exercise freeze-before-reservation, reservation-
before-freeze with provider-entry refusal, provider-entry-before-
freeze, epoch advance on restoration, wrong-holder refusal without
release, and reconciliation of an operation admitted before freeze.
It MUST demonstrate that provider entry moves one amount from
reserved to consumed exactly once, outcome commit does not debit it
again, and authenticated non-entry releases the held amount exactly
once. An idempotency case MUST refuse a retry whose operation
identifier matches but whose action or authority instance differs.
It MUST also demonstrate that an exact retry returns the original
result without a second budget consumption after the named authority
has been consumed, while a new request requires current valid
authority.
Schrock Expires 10 March 2027 [Page 26]
Internet-Draft EP Bounded Capabilities September 2026
The conformance set MUST reject a holder preimage of the wrong length
or digest, and MUST demonstrate that a captured valid preimage does
not bypass scope, budget, status, validity, operation replay, or
provider-entry-deadline checks. It MUST also reject an amount-and-
scale combination outside the operating range declared by the
selected profile. For ed25519-operation-proof, it MUST include a
valid proof and mutations of the public key, capability digest,
operation ID, action digest, amount, unit, scale, audience, and
state-domain digest; every mutation MUST refuse. It MUST also refuse
a portable threshold other than m=1, n=1 for that method.
The parent-over-allocation case MUST include at least three sibling
child-creation attempts whose individually valid amounts collectively
exceed the parent's available balance, with concurrent reservation
ordering chosen by the implementation. At most a balance-preserving
subset may commit. The case MUST also cover one operation identifier
presented for two different child receipt digests and an orphaned
child-registration failure after parent commitment. The former
refuses as operation replay; the latter leaves the committed parent
amount consumed pending reconciliation.
A wire-format implementation that does not implement one shared
atomic store is a receipt verifier, not a conforming spend-control
implementation. A store implementation that accepts a capability
without pinned issuer verification, issuance authorization, and scope
matching is not conforming.
16. Relationship to Other Work
Rich Authorization Requests [RFC9396] carries fine-grained
authorization details but deliberately leaves comparison semantics
for arbitrary detail types to their specifications. This document
defines an executor-side durable spend state machine and requires a
named closed scope profile.
OAuth Transaction Tokens [TXN-TOKENS] propagate transaction-specific
authorization context through a call chain. Bounded Capability
Receipts instead address an aggregate budget shared across multiple
operations and the reserve/commit boundary at the executor. A
deployment can use both.
The Delegation Receipt Protocol for AI Agent Authorization [DRP]
records delegation and narrowing. This document requires narrowing
for child capabilities and additionally accounts delegated budget as
a terminal parent spend.
Schrock Expires 10 March 2027 [Page 27]
Internet-Draft EP Bounded Capabilities September 2026
Attenuating Authorization Tokens for Agentic Delegation Chains
[ATTENUATING] describes constrained, attenuable agent tokens. This
document's distinct contribution is not the existence of constrained
tokens; it is the composition of a signed grant with shared
reservation ownership, committed budget accounting, and conservative
treatment of indeterminate external effects.
The Agent Identity Protocol [AIP] defines per-token budget ceilings
and explicitly assigns cumulative spending enforcement to the
orchestration runtime. A bounded capability budget is instead a
balance-valued authority in one authoritative store: reservation and
consumption reduce the amount available to every sibling allocation
in that domain.
PEDIGREE [PEDIGREE] defines cryptographic delegation, mandate
narrowing, and an operator-controlled ceiling. This document
preserves that identity and policy role and addresses the adjacent
runtime question of how one parent balance funds multiple children
without multiplying aggregate authority.
The Credential Broker for Agents [CB4A] defines proxy and short-
lived-token delivery patterns that keep long-lived provider
credentials away from agents. A deployment can use such a broker as
the credential-owning effect adapter after this protocol grants one
valid reservation; this document does not duplicate credential
brokering.
Condition-Bounded Credentials [CBC] binds workload-key use to live,
verifier-appraised conditions. That property composes with holder
proof and provider entry, especially for stable attestable workloads.
It does not replace aggregate balance accounting, and this document
does not extend its hardware assumptions to hardware-less or cross-
domain swarms.
The affine Token Budgets work [TOKEN-BUDGETS] studies LLM cost
overruns and uses Rust ownership to prevent cloning and use-after-
delegation in one process. It is adjacent prior art. This document
instead binds human- or policy-authorized consequential authority,
exact exercise actions, durable provider-entry reservations, and
conservative post-entry uncertainty across a transactional runtime.
It does not claim that balance-valued budgets or affine ownership
were invented here.
The Attested Payment Authorization for Autonomous Agents [HAWKINS]
binds an attested payment key and endorsed software identity to a
payment authorization scope and requires verification before
settlement. It is adjacent and complementary work: this document
does not define hardware attestation or transparency registration,
Schrock Expires 10 March 2027 [Page 28]
Internet-Draft EP Bounded Capabilities September 2026
while that document does not specify the authoritative shared-state,
reserve-and-commit, parent-funded delegation, and post-entry
uncertainty machinery defined here. A deployment can compose the two
by binding their decisions to the same exact exercise-action digest
without making either verifier consume the other's evidence as a
trust anchor.
17. Security Considerations
*Identifier substitution.* Capability signatures bind the full
issuance authorization digest, not only an identifier. Scope, budget
units, parent, holder commitment, and validity are all inside the
issuer signature.
*State forks.* Two stores accepting the same capability lineage can
each spend or delegate its full budget. Global offline or cross-
domain double-spend prevention is therefore not provided.
Deployments that cannot name one authoritative atomic state domain
for a capability and every authority-bearing ancestor and descendant
MUST NOT claim aggregate sibling conservation or an enforced
aggregate budget.
*Executor federation.* A multi-rail or multi-process deployment does
not, by itself, establish a shared budget. Every executor that can
admit an exercise must be bound to the same state domain, or the
scope must be restricted to one executor and the claim must be stated
as per-executor. Eventual reconciliation after independent
admissions cannot retroactively prevent overspend.
*Crash ambiguity.* Restoring budget after a timeout can authorize
duplicate external effects. Once the effect boundary may have been
crossed, uncertainty is charged as indeterminate.
*Reservation lifetime and expiry.* An unbounded pre-entry reservation
permits durable capacity denial and creates ambiguous expiry
behavior. The provider-entry deadline bounds that state. Expiry
prevents new provider entry but does not erase or reopen an attempt
that entered before expiry; that attempt remains terminally
accounted. A store that cannot serialize deadline recovery against
provider entry MUST NOT restore the budget.
Schrock Expires 10 March 2027 [Page 29]
Internet-Draft EP Bounded Capabilities September 2026
*Freeze and provider-entry races.* A freeze result is meaningful only
when domain status, admission epoch, capability state, applicable
allowance state, and operation state are serialized in the same
authoritative transaction domain. A freshness-bounded callback or
asynchronously replicated status cannot support an immediate-freeze
claim. The implementation MUST NOT release a reservation on a wrong-
holder request or relabel an operation after provider entry. An
unavailable domain row or conflicting state fails closed and retains
the reservation for authenticated recovery.
*Freeze idempotency.* Returning a cached transition result before
authenticating the request turns the idempotency key into a
disclosure token. Exact retries must match the same authority
instance and exact control action. A different principal, a
different capability held by the same principal, or a different
action under the same operation identifier is not an idempotent
retry.
*External predicate freshness.* Reservation protects the bounded
budget; it does not make mutable world facts current. If an action
depends on a record, counterparty status, market condition, or other
external predicate that can change after scope evaluation, the
deployment MUST require freshness-bound live evidence or re-evaluate
that predicate in boundary policy before provider entry. A short
reserve-to-effect interval reduces exposure but is not a correctness
mechanism. If the re-evaluation refuses before provider entry,
budget may be restored only through the authenticated not_entered
transition in Section 10.4.
*Operation-key scope.* Operation IDs are unique under one capability
receipt rather than globally attacker-reserved across the state
domain. The store MUST bind the capability receipt digest and
operation ID as one operation key. Preventing the same material
action from being admitted under two independently valid capabilities
is a separate relying-party policy and action-fencing concern.
Replay refusal in this document means refusal of an already-seen
operation key. It does not prohibit two otherwise authorized
operations with different operation IDs from carrying the same action
digest. A deployment requiring one occurrence per material action
MUST add a durable action fence or bind a unique occurrence
identifier into the material action.
*Bearer and share theft.* A raw holder secret or enough
unauthenticated shares can authorize possession and every remaining
in-scope operation. Confidential transport does not protect against
an enforcement point, endpoint, or log that leaks the reusable
preimage. Secret shares require confidential distribution,
authenticated participants, compromise response, and rate limiting.
Schrock Expires 10 March 2027 [Page 30]
Internet-Draft EP Bounded Capabilities September 2026
Deployments that require non-exportable custody need a separately
defined signature- or hardware-bound holder profile. The built-in
ed25519-operation-proof prevents a reusable bearer secret from
crossing the boundary, but protection of the signing key and
resistance to signing-oracle abuse remain deployment
responsibilities. Threshold custody is not human quorum.
*Revocation.* Expiry and exhausted budget are not revocation. A
deployment that requires early invalidation MUST consult a separately
authenticated revocation or status source before reservation and at
provider entry and define its freshness policy. Revocation
inheritance is not inferred from lineage alone: the signed mode
determines whether already transferred descendant authority survives.
An immediate cascade claim requires the ancestor revocation
transition, descendant reservation, and provider entry to be
serialized in the same authoritative atomic state domain.
Notification or eventual cache refresh cannot supply that guarantee.
Full-lineage locking can make a high-fan-out ancestor a contention
and denial-of-service hot spot; deployments MUST bound lineage depth,
admission work, and lock acquisition time without weakening the fail-
closed result.
*Units and arithmetic.* All accounting uses integers with signed unit
and scale. Floating-point arithmetic, implicit currency conversion,
and caller-selected rounding MUST NOT occur in the authoritative
budget path. The safe-integer ceiling and decimal scale jointly
limit range; a high scale does not provide both arbitrary precision
and arbitrary major-unit magnitude.
*Database authority.* The capability tables contain authorization
state. Deployments MUST restrict writes to the enforcement service,
use least-privilege credentials, protect backups, and audit
administrative changes.
*Delegation lineage.* Local uniqueness checks over one presented
receipt do not establish graph-wide acyclicity or complete ancestry.
Separately presented receipts can omit links, substitute a parent
operation, or form a cycle unless each parent edge is authenticated
and resolved by digest, or an authoritative store enforces equivalent
edge constraints. Implementations MUST fail closed on incomplete,
cyclic, substituted, or non-narrowing lineage. Verifiers apply the
complete traversal and refusal rules in Section 12 to imported chains
and chains reconstructed from storage.
*Comparison-proof substitution and exhaustion.* A signed conformance
record from an untrusted runner does not establish a relation
property. Profiles that permit mechanical establishment MUST bound
domain cardinality and procedure work, define one canonical domain
Schrock Expires 10 March 2027 [Page 31]
Internet-Draft EP Bounded Capabilities September 2026
encoding, and reject values outside the established domain for chain-
composition purposes. Implementations MUST apply bounded parsing
before processing a presented record and MUST NOT perform attacker-
sized enumeration on the admission path.
*Semantic limits.* A valid capability does not prove that an action
is safe, lawful, beneficial, or correctly executed. Local policy and
domain controls remain necessary.
*Evidence limits.* Absence of a receipt proves only that no matching
receipt was found in the examined evidence domain. It does not prove
that no authorization existed. A committed operational event is not
independently verifiable cryptographic evidence unless a separately
specified signed artifact covers that event and the relying party
verifies it under pinned trust policy.
*Cryptographic scope.* This version uses SHA-256 and Ed25519. It
does not provide a post-quantum signature profile or a zero-knowledge
receipt. Algorithm agility and long-term preservation are separate
concerns.
18. Privacy Considerations
Capability receipts and operation records can reveal spending limits,
organizational roles, intended action classes, counterparties, and
timing. Profiles SHOULD minimize identifiers, separate portable
evidence from operational secrets, and define retention and access
controls. Hashing a low-entropy scope or identifier does not make it
confidential.
19. Implementation Status
The Apache-2.0 TypeScript reference implementation includes a signed
pre-standard capability envelope, holder-secret commitment, optional
threshold secret reconstruction, and a durable PostgreSQL reservation
and commitment store. Its issuer-controlled delegation API, when
used with one shared capability store, reserves and commits a child
amount from the immediate parent before registering the child. Both
the in-memory and PostgreSQL stores record a provider-entry deadline
bounded by capability expiry, refuse late provider entry, retain an
explicit provider-entry marker, and recover a timed-out pre-entry
reservation as not_entered without deleting its operation record.
The store has adversarial tests for overspend, replay, ownership
fencing, expiry, terminal commitment, concurrent N-sibling aggregate
over-allocation, one operation identifier paired with different child
digests, orphaned registration after parent commitment, and an
explicit two-store state-fork counterexample. These are same-team
implementation and regression results, not independent implementation
Schrock Expires 10 March 2027 [Page 32]
Internet-Draft EP Bounded Capabilities September 2026
or production deployment evidence.
The reference stores move an operation amount from reserved_amount to
consumed_amount in the same transaction that records provider entry,
and later outcome commit does not debit the budget again. The in-
memory and PostgreSQL reference stores implement the -05 admission-
control domain status and monotonic epoch on explicitly covered
operations. Reservation captures the current epoch; provider entry
locks and rechecks the same domain before changing held budget to
consumed budget; freeze and restore each advance the epoch; and a
pre-freeze reservation that has not entered is released as
not_entered only under its reservation-owner check. Same-team
hostile tests exercise both serializations of freeze versus provider
entry against an ephemeral live PostgreSQL 17 instance, wrong-holder
release refusal, restore non-revival, idempotent authenticated freeze
retry, and the no-second-debit rule. This is local implementation
experience, not independent interoperability or production evidence.
There is no disconnected-edge lease implementation and no signed
freeze-event artifact. Control transitions use a trusted verifier
callback; the reference store does not yet atomically consume a
portable detector capability in the same transaction.
The prototype wire format predates this document and does not yet
implement all mandatory fields in this version, including full
issuance authorization digest binding, an explicit action-scope
profile, and explicit budget unit scale, digest-linked parent
lineage, authenticated parent-delegation binding, not_before, and
complete ingest-time cycle validation. It is therefore
implementation experience, not a claim of conformance. There is no
independent implementation, interoperability event, production
transaction history, post-quantum profile, or zero-knowledge
implementation. The executor-domain participant binding and per-
action human-authorization composition added in -02 are protocol
requirements and composition rules. The reference execution path now
implements those two integrations: an aggregate budget claim requires
an exact match to a relying-party-pinned atomic state-domain digest;
a mismatch may fall back only to an explicitly pinned single
executor; and a required per-action human authorization must pass a
native verifier under relying-party pins and bind the exact exercise-
action digest. Calls without an executor-domain binding are labeled
local_store_only and do not claim aggregate enforcement. A
configured state-domain digest is a deployment trust binding; the
code cannot by itself prove that two processes connect to the same
physical database.
The reference implementation now signs and requires revocation_mode,
records each capability's immediate parent, and implements direct and
cascade revocation in both the in-memory test store and PostgreSQL
Schrock Expires 10 March 2027 [Page 33]
Internet-Draft EP Bounded Capabilities September 2026
store. A descendant reservation resolves the complete registered
ancestor lineage. The PostgreSQL path locks those state rows in the
reservation transaction, so an ancestor revocation that commits first
refuses the reservation, while a reservation that commits first
remains owned and reconcilable. Missing, malformed, or migration-
incomplete ancestor state refuses at reservation. The tracked
migration quarantines legacy rows without an explicit mode rather
than inferring direct or cascade. Regression cases cover the signed
closed field, direct descendant survival, cascade refusal,
unavailable ancestor state, child allocation after revocation, and
both orderings of the revocation race. This is same-team
implementation evidence inside one authoritative atomic state domain;
it is not independent interoperability, revocation distribution, or
cross-domain cascade enforcement.
Entry-time direct and inherited revocation revalidation is not yet
implemented in these reference stores. They recheck the admission-
control epoch, applicable allowance state, ownership, and deadline at
provider entry, but currently resolve direct and ancestor revocation
at reservation. Those results do not establish the entry-time
revocation rule or its new ordering cases in Section 15, Paragraph 3.
The implementation and bounded revocation model therefore provide
partial experience, not conformance to that part of this revision.
The delegated-commit revocation recheck is also a protocol
requirement, not an implementation claim for the existing
reservation-time revocation path.
The -04 scope-profile contract and comparison-reporting rules are not
yet implemented. In particular, the reference implementation does
not yet emit per-component decidability records, relation
reflexivity, transitivity classification or basis, mechanical-
establishment provenance, or the local-only versus chain-composable
result. No implementation or conformance claim is made for those
additions. The -04 atomic root-issuance registration rule is also
not implemented as a conforming protocol operation because the
prototype does not yet bind and consume the full issuance
authorization described here. The capability-scoped operation key
and terminal budget-restoring not_entered behavior are implemented in
the reference stores, but that implementation evidence does not close
the other -04 gaps. The ed25519-operation-proof holder method is not
yet implemented by the reference capability API; no implementation
claim is made for it.
The reference implementation does reject repeated delegation
identifiers, repeated parent capability identifiers, a leaf named as
its own parent, and increasing amounts within the delegation chain
presented at mint or verification time. Those checks provide local
simple-path and monotonic amount enforcement. They do not discover
Schrock Expires 10 March 2027 [Page 34]
Internet-Draft EP Bounded Capabilities September 2026
omitted parents or establish the digest-linked, graph-wide lineage
required by Section 12, so they do not close the remaining
conformance gap.
The public repository contains two CI-gated bounded TLA+ models
relevant here. The capability-accounting model covers registration,
reservation, commitment, delegation, replay refusal, parent-funded
child registration, and aggregate sibling conservation. A separate
-03 revocation-inheritance model covers every direct/cascade
assignment over a root, child, and grandchild; complete ancestor-
state availability; future child allocation; and both serialized
orderings of revocation and reservation. Exact state and obligation
counts are emitted by governed proof-status artifacts. These are
bounded results about the models, not refinement proofs of the
TypeScript, SQL, transaction adapter, cryptography, lineage
verification, or complete protocol defined here. Arbitrary
implementation inputs still require the runtime traversal and refusal
rules in Section 12.
The main branch also runs a fixed-seed adversarial harness in per-
push CI over the actual JavaScript in-memory capability and
consumption stores. It includes a true-concurrency Promise.all race
target and a deliberately non-atomic comparison store that
demonstrates the race detector can expose over-commitment.
Additional targets exercise accounting and ownership invariants at
whole-method boundaries. This is regression evidence for those in-
process stores, not complete protocol conformance: it does not fuzz
the PostgreSQL capability transaction path, the atomic handshake RPC,
replica or connection failures, and no deeper nightly sweep is
scheduled.
20. Changes Since -04
* Moved the reserved-to-consumed budget transition to the atomic
provider-entry boundary for external effects and prohibited a
second debit at outcome commit.
* Required current capability and applicable allowance state to be
rechecked in the provider-entry transaction.
* Made provider entry the cutoff for direct and inherited cascade
revocation, preserved direct-mode descendant independence, and
added explicit ordering cases and the remaining implementation
limitation.
* Defined an optional admission-control domain and monotonic epoch
captured at reservation and rechecked at provider entry.
Schrock Expires 10 March 2027 [Page 35]
Internet-Draft EP Bounded Capabilities September 2026
* Defined serialized freeze, restoration, wrong-holder, non-entry,
and pre-freeze reconciliation behavior without claiming that
computation or already-entered effects are stopped.
* Bound idempotent freeze retries to the exact action and authority
instance and made the operation identifier non-authoritative by
itself.
* Specified the honest disconnected-edge stale-admission window and
added explicit receipt-absence and unsigned-event claim limits.
21. Acknowledgments
The author thanks Sumit P. Ahuja for the scope-comparison analysis
that led to the transitivity-basis, mechanical-establishment
provenance, and chain-composition requirements in Section 7.
22. IANA Considerations
This document has no IANA actions. A future revision may request a
media type and registries for receipt versions, scope profiles,
holder methods, and failure codes after implementation experience
stabilizes the protocol.
23. References
23.1. Normative References
[BCP14] Internet Engineering Task Force, "Key Words for Use in
RFCs to Indicate Requirement Levels", BCP 14, 2017,
<https://www.rfc-editor.org/info/bcp14>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
Schrock Expires 10 March 2027 [Page 36]
Internet-Draft EP Bounded Capabilities September 2026
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/info/rfc8785>.
23.2. Informative References
[AIP] Prakash, S., "Agent Identity Protocol (AIP): Verifiable
Delegation for AI Agent Systems", 2026,
<https://datatracker.ietf.org/doc/draft-prakash-aip/>.
[ATTENUATING]
Aimable, N., "Attenuating Authorization Tokens for Agentic
Delegation Chains", 2026,
<https://datatracker.ietf.org/doc/draft-niyikiza-oauth-
attenuating-agent-tokens/>.
[CB4A] Hartman, K. G., "Credential Broker for Agents (CB4A)",
2026, <https://datatracker.ietf.org/doc/draft-hartman-
credential-broker-4-agents/>.
[CBC] Huu, T. N., Nikitin, S., and J. O'Leary, "Condition-
Bounded Credentials for Workload and Agent Identity: Non-
Exfiltratable Keys and Validity by Presence", 2026,
<https://datatracker.ietf.org/doc/draft-winmagic-wimse-
condition-bounded-credentials/>.
[DRP] Nelson, R., "Delegation Receipt Protocol for AI Agent
Authorization", 2026, <https://datatracker.ietf.org/doc/
draft-nelson-agent-delegation-receipts/>.
[EP-QUORUM]
Schrock, I., "Multi-Party Authorization (Quorum) for the
EMILIA Protocol", 2026, <https://datatracker.ietf.org/doc/
draft-schrock-ep-quorum/>.
Schrock Expires 10 March 2027 [Page 37]
Internet-Draft EP Bounded Capabilities September 2026
[HAWKINS] Hawkins, W., "Attested Payment Authorization for
Autonomous Agents", Work in Progress, Internet-Draft,
draft-hawkins-scitt-attested-agent-payment-00, 2026,
<https://datatracker.ietf.org/doc/draft-hawkins-scitt-
attested-agent-payment/>.
[PEDIGREE] Rampalli, K., "PEDIGREE: Verifiable Delegation Identity
for Agentic AI Systems", 2026,
<https://datatracker.ietf.org/doc/draft-rampalli-
pedigree/>.
[RFC9396] Lodderstedt, T., Richer, J., and B. Campbell, "OAuth 2.0
Rich Authorization Requests", RFC 9396,
DOI 10.17487/RFC9396, May 2023,
<https://www.rfc-editor.org/info/rfc9396>.
[TOKEN-BUDGETS]
Khan, S., "Token Budgets: An Empirical Catalog of 63 LLM-
Agent Budget-Overrun Incidents, with an Affine-Typed Rust
Mitigation as a Case Study", arXiv 2606.04056, 2026,
<https://arxiv.org/abs/2606.04056>.
[TXN-TOKENS]
Tulshibagwale, A., Fletcher, G., and P. Kasselman,
"Transaction Tokens", 2026,
<https://datatracker.ietf.org/doc/draft-ietf-oauth-
transaction-tokens/>.
Author's Address
Iman Schrock
EMILIA Protocol, Inc.
United States of America
Email: team@emiliaprotocol.ai
Schrock Expires 10 March 2027 [Page 38]