Capability-Bound Delegation Chains with Scoped Context Disclosure for AI Agents
draft-atakora-wimse-sadp-delegation-00
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 | Hamdy Atakora | ||
| Last updated | 2026-09-21 | ||
| 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-atakora-wimse-sadp-delegation-00
Individual Submission H. Atakora
Internet-Draft Imara Labs
Intended status: Experimental 20 September 2026
Expires: 24 March 2027
Capability-Bound Delegation Chains with Scoped Context Disclosure for AI
Agents
draft-atakora-wimse-sadp-delegation-00
Abstract
Autonomous AI agents increasingly act on behalf of users and of one
another, passing tasks, documents, tool access, and authority across
chains of delegation. Existing delegation-token systems express and
verify attenuated authority, but they assume the delegation evidence
and the task content are visible to the infrastructure that carries
them. This document specifies a capability grant format, delegation-
chain construction and verification rules, a caveat processing model,
and a hash-linked audit record format designed to bind authority to
end-to-end encrypted task capsules, so that authority can be verified
and delegation lineage can be checked relative to an authenticated
chain head without exposing task or context plaintext to brokers,
queues, gateways, or orchestration services. It further specifies
scoped context disclosure: a model in which a delegatee receives
cryptographic access to only the subset of task context that its
capability names. This mechanism complements, and is intended to be
reconcilable with, the delegation chains defined in draft-asor-wimse-
agent-delegation-chain.
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/.
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 24 March 2027.
Atakora Expires 24 March 2027 [Page 1]
Internet-Draft SADP Delegation Chains September 2026
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. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Design Goals . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Relationship to
draft-asor-wimse-agent-delegation-chain . . . . . . . . . 4
1.4. Relationship to the SADP Capsule Protocol . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Principal Identifiers . . . . . . . . . . . . . . . . . . 7
3.2. Canonical JSON Encoding . . . . . . . . . . . . . . . . . 7
3.3. Capability Grant Structure . . . . . . . . . . . . . . . 8
3.4. Grant Signing Input . . . . . . . . . . . . . . . . . . . 9
4. Delegation Chains . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Chain Construction . . . . . . . . . . . . . . . . . . . 10
4.2. Attenuation Rules . . . . . . . . . . . . . . . . . . . . 10
4.3. Chain Verification Algorithm . . . . . . . . . . . . . . 11
4.4. Depth Limits . . . . . . . . . . . . . . . . . . . . . . 13
5. Caveats . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Processing Model . . . . . . . . . . . . . . . . . . . . 13
5.2. Initial Caveat Definitions . . . . . . . . . . . . . . . 13
6. Scoped Context Disclosure . . . . . . . . . . . . . . . . . . 14
6.1. Context References . . . . . . . . . . . . . . . . . . . 14
6.2. Hierarchical Resource Naming . . . . . . . . . . . . . . 14
6.3. The Joint Attenuation Property . . . . . . . . . . . . . 15
7. Audit Chain . . . . . . . . . . . . . . . . . . . . . . . . . 15
7.1. Audit Record . . . . . . . . . . . . . . . . . . . . . . 15
7.2. Capsule Hash . . . . . . . . . . . . . . . . . . . . . . 15
7.3. Chain Hash . . . . . . . . . . . . . . . . . . . . . . . 16
7.4. Receiver Verification . . . . . . . . . . . . . . . . . . 16
7.5. Trust Model of the Audit Chain . . . . . . . . . . . . . 16
8. Carriage in Encrypted Task Capsules . . . . . . . . . . . . . 17
9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 17
Atakora Expires 24 March 2027 [Page 2]
Internet-Draft SADP Delegation Chains September 2026
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
12.1. SADP Capability Caveats Registry . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix A. Worked Example: Two-Hop Delegation with Context
Narrowing . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix B. Comparison with Related Delegation Mechanisms . . . 26
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 27
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
1.1. Problem
Agentic systems compose work across many principals: a user delegates
a task to a personal agent; that agent delegates a narrower subtask
to a specialist agent; the specialist invokes tools through hosted
infrastructure. Each hop transfers two distinct things that today's
deployments conflate:
* authority: what the recipient is allowed to do, and
* information: what the recipient is allowed to see.
Deployed agent interoperability protocols such as A2A [A2A] and MCP
[MCP] secure hops with transport-layer TLS and bearer-style
authorization. The brokers, queues, orchestration servers, and
gateways between the endpoints see task plaintext and hold
effectively unattenuated authority evidence. Delegation-token
systems (Macaroons [MACAROONS], Biscuit [BISCUIT], UCAN [UCAN], OAuth
2.0 Token Exchange [RFC8693], GNAP [RFC9635]) solve the authority
problem: they let a holder derive a strictly weaker token offline and
let a verifier check the derivation. They do not address the
information problem, and they generally assume the token and the
request it authorizes are visible to intermediaries.
This document specifies the delegation layer of the Secure Agent
Delegation Protocol (SADP): signed capability grants whose delegation
chains are bound to end-to-end encrypted task capsules [SADP-PROTO],
verified entirely by the receiving endpoint, and linked to a tamper-
evident audit hash chain that infrastructure can store and compare
without reading task or context plaintext. In the v0.2 capsule
profile, grants and audit records are authenticated outer fields and
may reveal delegation metadata to brokers that store complete
capsules; a future private-delegation-evidence profile is expected to
Atakora Expires 24 March 2027 [Page 3]
Internet-Draft SADP Delegation Chains September 2026
encrypt grant bodies and detailed audit records while exposing only
commitments needed for routing, replay, and omission detection. It
additionally defines scoped context disclosure, in which the resource
named by a capability is a hierarchical identifier for an encrypted
context object, and decryption keys for context are released only
against a valid capability chain. Attenuating authority therefore
simultaneously attenuates information access.
1.2. Design Goals
1. Offline-verifiable attenuation. A receiver MUST be able to
verify that every link in a delegation chain is a monotonic
narrowing of the previous link, given only the chain itself and a
means of resolving principal signing keys.
2. No task or context plaintext for infrastructure. Nothing in this
specification requires a broker or transport to read task
payloads or context objects. The v0.2 outer capsule profile does
expose grant and audit metadata; deployments that need to hide
that metadata require a future private-delegation-evidence
profile.
3. Joint attenuation of authority and information. Narrowing a
capability's resource identifier narrows the context a delegatee
can decrypt.
4. Auditable lineage without content exposure. Delegation lineage
MUST be verifiable through hash commitments over capsule bytes,
not through plaintext disclosure.
5. Fail-closed extensibility. A verifier that encounters a
restriction it does not understand MUST refuse, never ignore.
1.3. Relationship to draft-asor-wimse-agent-delegation-chain
[I-D.asor-wimse-agent-delegation-chain] defines verifiable attenuated
delegation chains for AI agents using JWT/RAR capability tokens, a
par_hash linking each token to the JWS signing input of its parent,
offline-verifiable constraint subsumption, and status-list
revocation. This document shares that design lineage. The
parent_grant_hash link defined here serves the same anti-splicing
purpose as par_hash, and the attenuation rules in Section 4.2 are a
constraint-subsumption discipline. This document is deliberately
framed to be reconcilable with that work rather than to compete with
it.
The contributions of this document beyond
[I-D.asor-wimse-agent-delegation-chain] are:
Atakora Expires 24 March 2027 [Page 4]
Internet-Draft SADP Delegation Chains September 2026
1. carriage and verification of delegation chains inside end-to-end
encrypted task workflows, so that task and context verification
does not require exposing payload plaintext to any intermediary;
and
2. scoped context disclosure, which binds information release
(decryption of context objects) to the same attenuation
discipline that bounds authority.
The grant syntax in this document is a compact canonical-JSON
structure chosen for byte-exact signing across implementations. A
future revision may define a JWT/RAR profile of the same semantics so
that a single chain can be consumed by verifiers of either syntax.
Related work is also developing around transport and receipt models:
[I-D.sharif-attp] addresses synchronous trust transport,
[I-D.sharif-agent-transport-protocol] addresses asynchronous store-
and-forward transport, [I-D.hamr-oauth-agent-delegation] addresses
cross-domain delegation headers, [I-D.liu-oauth-chain-delegation]
addresses OAuth-based chained delegation tokens,
[I-D.li-oauth-delegated-authorization] addresses constrained client-
issued delegated authorization tokens,
[I-D.singla-agent-identity-protocol] addresses decentralized agent
identity and delegation, [I-D.vandoulas-aidp] addresses governed
intent/execution control, and [I-D.nelson-agent-delegation-receipts]
addresses log-anchored delegation receipts. This document is
narrower than a general transport and broader than authority-only
delegation: it binds attenuated authority to encrypted task and
context delivery.
1.4. Relationship to the SADP Capsule Protocol
The companion document [SADP-PROTO] specifies SADP's encrypted task
capsules, session establishment, and broker profile. This document
is self-contained for grant syntax, chain verification, caveats,
audit records, and context disclosure; it relies on the companion
document only for how capsules are encrypted and routed. A
deployment MAY use the delegation layer defined here over a different
secure envelope, provided the envelope authenticates the capsule
fields referenced in Section 8.
2. Terminology
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.
Atakora Expires 24 March 2027 [Page 5]
Internet-Draft SADP Delegation Chains September 2026
Principal: An entity that can hold keys and appear as an issuer,
holder, sender, or recipient: a user, agent, runtime, tool,
workspace, or broker.
Principal Identifier: A slash-separated sequence of kind:name
segments identifying a principal, for example user:alice/
device:phone or agent:contract-reviewer/runtime:prod-a
(Section 3.1).
Subject: The principal identifier with a trailing runtime:* or
device:* segment removed; the stable actor behind multiple
runtimes or devices.
Capability Grant (Grant): A signed statement that an issuer
authorizes a holder to perform an action on a resource for a task,
until an expiry, under caveats (Section 3.3).
Delegation Chain (Chain): A grant together with its transitively
embedded parent grants, ending at a root grant (Section 4).
Attenuation: Deriving a child grant from a parent grant such that
the child's authority is a strict subset of the parent's
(Section 4.2).
Caveat: A named restriction carried by a grant that the receiving
application must honor (Section 5).
Task Capsule (Capsule): The SADP message envelope carrying a task,
its grants, its context references, and its audit record
[SADP-PROTO]. In the v0.2 capsule profile, grants and audit
records are authenticated outer fields rather than encrypted inner
fields.
Context Reference: A pointer to an encrypted context object, keyed
by a hierarchical resource identifier (Section 6).
Audit Record: A hash commitment linking a capsule to its delegation
parent and to a running chain hash (Section 7).
Trusted Issuer: A principal whose signing key the receiver accepts
as a valid root of authority, configured out of band or resolved
through a registry the receiver trusts for key binding.
3. Data Model
Atakora Expires 24 March 2027 [Page 6]
Internet-Draft SADP Delegation Chains September 2026
3.1. Principal Identifiers
A principal identifier is one or more segments separated by /. Each
segment is kind:name, where kind is one of user, device, agent,
runtime, tool, workspace, broker, memory, or context, and name is a
non-empty token of characters from the set a-z A-Z 0-9 . _ -.
Implementations MUST reject identifiers with empty segments, unknown
kinds, or characters outside this set.
Examples:
user:alice/device:phone
agent:contract-reviewer/runtime:prod-a
tool:pdf-parser/runtime:prod-b
3.2. Canonical JSON Encoding
All signing inputs and hash inputs in this document are computed over
canonical JSON bytes produced from the value being signed or hashed:
* text is UTF-8;
* object member names are sorted lexicographically by Unicode code
point at every nesting level;
* duplicate member names are invalid and MUST be rejected on parse;
* arrays preserve their order;
* strings use standard JSON escaping [RFC8259];
* no insignificant whitespace is emitted;
* binary values are base64url without padding [RFC4648];
* timestamps are RFC 3339 [RFC3339] strings in documents and integer
epoch seconds inside signing inputs.
This profile is intentionally close to JCS [RFC8785]; a future
revision may adopt JCS by reference once number canonicalization
requirements are confirmed against deployed implementations.
Verifiers MUST rebuild signing inputs from parsed, validated values
rather than signing or verifying raw received bytes, which removes
parse/serialize mismatch as an attack surface.
Atakora Expires 24 March 2027 [Page 7]
Internet-Draft SADP Delegation Chains September 2026
3.3. Capability Grant Structure
A grant is a JSON object:
{
"issuer": "user:alice/device:phone",
"holder": "agent:contract-reviewer/runtime:prod-a",
"action": "read",
"resource": "blob:contract_pdf",
"task_id": "task_01J00000000000000000000000",
"expires_at": "2026-09-19T13:00:00Z",
"max_delegation_depth": 1,
"caveats": ["delete_after_result"],
"parent_grant_hash": null,
"parent": null,
"signature": "base64url-ed25519-signature"
}
Fields:
issuer: Principal identifier of the granting party. REQUIRED.
holder: Principal identifier of the authorized party. REQUIRED.
action: A token naming the permitted operation (for example read,
write, delegate). REQUIRED.
resource: A hierarchical resource identifier (Section 6.2).
REQUIRED.
task_id: The task this grant is bound to. A grant is not
transferable across tasks. REQUIRED.
expires_at: RFC 3339 expiry. REQUIRED.
max_delegation_depth: Integer in the range 0..8. The number of
further delegation hops the holder may create. REQUIRED.
caveats: Array of caveat identifiers (Section 5). REQUIRED (may be
empty).
parent: The complete parent grant object, including its signature,
or null for a root grant. OPTIONAL; absent is equivalent to null.
parent_grant_hash: null for a root grant, otherwise the base64url
Atakora Expires 24 March 2027 [Page 8]
Internet-Draft SADP Delegation Chains September 2026
SHA-256 hash over the canonical JSON of the complete parent grant
object including its signature. REQUIRED by the signing input;
MAY be omitted on the wire only for root grants, where omission is
equivalent to null.
signature: base64url Ed25519 [RFC8032] signature over the signing
input defined in Section 3.4. REQUIRED.
3.4. Grant Signing Input
The signing scheme identifier is sadp-cap-ed25519-v0.2.
The Ed25519 signing input is the concatenation of a domain-separation
prefix and canonical JSON:
"SADP capability grant v0.2\n" || canonical_json({
"scheme": "sadp-cap-ed25519-v0.2",
"issuer": issuer,
"holder": holder,
"action": action,
"resource": resource,
"task_id": task_id,
"expires_at_epoch_seconds": expires_at_epoch_seconds,
"max_delegation_depth": max_delegation_depth,
"caveats": caveats,
"parent_grant_hash": parent_grant_hash
})
where parent_grant_hash is:
* null for a root grant; otherwise
* base64url (no padding) of SHA-256 [RFC6234] over the canonical
JSON of the complete parent grant object including its signature
field.
Hashing the parent including its signature commits the child to one
specific signed parent instance, not merely to parent field values; a
chain therefore cannot be spliced onto a different signature over
identical fields. This is the same anti-splicing discipline as
par_hash in [I-D.asor-wimse-agent-delegation-chain].
The signature field of the grant being signed is never part of its
own signing input. The domain-separation prefix is versioned;
signatures made under this scheme cannot be confused with SADP
session, prekey, broker request, or audit signatures, which use
distinct prefixes.
Atakora Expires 24 March 2027 [Page 9]
Internet-Draft SADP Delegation Chains September 2026
4. Delegation Chains
4.1. Chain Construction
A root grant is created and signed by an original authority
(typically a user device or a workspace owner) with parent absent or
null.
A delegated grant is created by the holder of an existing grant. The
delegator:
1. constructs the child grant with issuer set to the parent's
holder, fields attenuated per Section 4.2, and parent set to the
full parent grant;
2. computes parent_grant_hash over the parent as defined in
Section 3.4;
3. signs the child with its own Ed25519 signing key.
A chain on the wire is thus a single grant object whose parent field
nests the entire ancestry. The nesting depth of a chain MUST NOT
exceed 8; parsers MUST reject deeper nesting before signature
verification.
4.2. Attenuation Rules
Given parent grant P and child grant C, all of the following MUST
hold. A delegator MUST NOT create, and a verifier MUST reject, any
chain link that violates any rule:
1. Issuer continuity: C.issuer == P.holder.
2. Action equality: C.action == P.action. Action broadening or
substitution is not permitted in this version.
3. Resource narrowing: C.resource == P.resource, or C.resource
begins with P.resource + "/" (Section 6.2).
4. Expiry narrowing: C.expires_at <= P.expires_at.
5. Depth decrement: P.max_delegation_depth >= 1 and
C.max_delegation_depth <= P.max_delegation_depth - 1.
6. Caveat accumulation: every caveat present in P.caveats MUST be
present in C.caveats (caveats may be added, never dropped), and
P.caveats MUST NOT contain no_further_delegation.
Atakora Expires 24 March 2027 [Page 10]
Internet-Draft SADP Delegation Chains September 2026
These rules make authority monotonically non-increasing along the
chain, in the tradition of caveat-based attenuation introduced by
Macaroons [MACAROONS] and carried into public key delegation systems
by Biscuit [BISCUIT] and UCAN [UCAN]. Unlike bearer-token
attenuation, each link here is bound to a named holder key, so
possession of chain bytes alone conveys no authority.
4.3. Chain Verification Algorithm
Inputs: a grant G (the leaf), a set of trusted issuer keys
trusted_issuers mapping principal identifiers to Ed25519 public keys,
a key resolution function resolve_key(principal) for intermediate
holders, a verification time now, and the receiving capsule's to,
task_id, and requested action/resource use.
Atakora Expires 24 March 2027 [Page 11]
Internet-Draft SADP Delegation Chains September 2026
verify_chain(G, trusted_issuers, resolve_key, now, capsule):
1. Flatten: chain = [G, G.parent, G.parent.parent, ...],
stopping at the root (parent == null).
Reject if length > 8.
2. Root authority: let R = last element of chain.
Reject unless trusted_issuers contains R.issuer.
Reject unless ed25519_verify(trusted_issuers[R.issuer],
signing_input(R, parent_grant_hash = null), R.signature).
3. Links, from the root downward, for each (parent P, child C):
a. Reject unless C.parent_grant_hash ==
b64url(SHA-256(canonical_json(P including P.signature))).
b. Reject unless C.issuer == P.holder.
c. Let K = resolve_key(C.issuer); reject if unresolvable.
Reject unless ed25519_verify(K,
signing_input(C, C.parent_grant_hash), C.signature).
d. Reject unless attenuation rules 1-6 hold for (P, C).
4. Freshness: for every link L in chain,
reject unless now < epoch_seconds(L.expires_at).
5. Leaf binding:
a. Reject unless G.holder equals capsule.to or equals the
subject of capsule.to.
b. Reject unless G.task_id == capsule.task_id.
c. Reject unless G.action and G.resource authorize the
requested use (action equality; resource equal to or an
ancestor of the requested resource under rule 3 semantics).
d. Reject if G.caveats contains any identifier the receiver
does not recognize ({{caveat-processing}}).
6. Output: on success, return the set of recognized caveats
(the EnforcedCaveats) to the application layer.
resolve_key binds intermediate issuer principals to signing keys. In
SADP deployments it is served by the broker registry's issuer-key
lookup or by a locally configured trust list; the trust model for
that binding is workload identity infrastructure in the sense of
[I-D.ietf-wimse-arch] and [SPIFFE], and is out of scope for this
document beyond the requirement that the receiver, not any
intermediary, performs the binding check.
Verification is deterministic and offline given the chain, the
trusted issuer set, and resolved keys: no interaction with the issuer
or delegators is required at verification time.
Atakora Expires 24 March 2027 [Page 12]
Internet-Draft SADP Delegation Chains September 2026
4.4. Depth Limits
max_delegation_depth bounds authority spread; the structural nesting
bound of 8 bounds verification cost. Both limits are enforced
independently: structural depth is checked before any cryptographic
work, and rule 5 of Section 4.2 is checked per link.
5. Caveats
5.1. Processing Model
Caveats are first-party restrictions in the Macaroons sense
[MACAROONS]: named conditions the receiving application must honor
when exercising the grant.
Processing rules:
1. Verifiers MUST reject a leaf grant carrying any caveat identifier
they do not recognize (fail closed). An unknown restriction that
was ignored would silently broaden authority.
2. Recognized caveats MUST be surfaced to the application layer as a
structured value (EnforcedCaveats) by the validation API, so that
application code cannot obtain task plaintext without also
receiving the restrictions attached to it.
3. Caveats accumulate along the chain per rule 6 of Section 4.2.
5.2. Initial Caveat Definitions
no_external_network: While performing the task authorized by this
grant, the holder MUST NOT make network requests other than SADP
protocol exchanges required to return results or delegate within
the chain's bounds.
delete_after_result: The holder MUST delete all decrypted task
content, context, and derived artifacts after delivering the task
result, and MUST NOT persist them in long-lived memory or logs.
no_further_delegation: The holder MUST NOT derive child grants from
this grant. Attenuation from a grant carrying this caveat is
invalid (rule 6 of Section 4.2), regardless of remaining
max_delegation_depth.
Atakora Expires 24 March 2027 [Page 13]
Internet-Draft SADP Delegation Chains September 2026
These are behavioral obligations on the holder; cryptography cannot
force a holder to honor them after plaintext release (Section 10).
Their value is that they are signed, non-droppable, verifier-checked
statements of the authorized behavior, which makes violations
attributable.
6. Scoped Context Disclosure
6.1. Context References
Task context (documents, memory slices, tool inputs) is passed by
encrypted reference rather than inline. A context reference names an
encrypted context object:
{
"ref": "blob:contract_pdf/sections_3_8",
"content_type": "application/pdf",
"encrypted_key_ref": "keyref_abc"
}
The context object is encrypted under a content key;
encrypted_key_ref identifies the wrapped content key. The content
key for a context object MUST be released only to a principal
presenting (or known by the releasing endpoint to hold) a valid
capability chain whose leaf authorizes read on the object's resource
identifier or an ancestor of it.
Key release is performed by an endpoint that already holds the
content key. This is typically the delegator, which re-wraps the
content key to the delegatee inside the encrypted capsule, or a
context store acting as a partially trusted principal. The broker is
never a key-release party and never holds content keys.
6.2. Hierarchical Resource Naming
Resource identifiers are /-separated hierarchies rooted in a typed
name, for example:
blob:contract_pdf
blob:contract_pdf/sections_3_8
blob:contract_pdf/sections_3_8/redacted
Rule 3 of Section 4.2 makes the hierarchy the unit of attenuation: a
delegator holding read on blob:contract_pdf may grant read on
blob:contract_pdf/sections_3_8, and MUST NOT grant read on any
identifier outside that subtree. Because key release is bound to the
same identifiers, narrowing the resource in the chain narrows the
ciphertexts whose keys the delegatee can obtain.
Atakora Expires 24 March 2027 [Page 14]
Internet-Draft SADP Delegation Chains September 2026
A delegator that materializes a sub-resource (for example, extracting
sections 3 and 8 into a new context object) MUST encrypt the sub-
resource under a fresh content key. Granting a child access to a
sub-resource never requires disclosing the parent object's key.
6.3. The Joint Attenuation Property
The intended invariant, stated informally: for every principal p and
context object c, p can decrypt c only if some valid chain reaching p
authorizes read on c's resource identifier or an ancestor of it.
Authority narrowing (the chain) and information narrowing (key
release) are therefore the same operation performed on the same
identifiers. Systems that scope only authority leave information
exposure to convention; systems that encrypt only channels disclose
everything on the channel to every channel member. This mechanism is
the distinguishing contribution of this document relative to
[I-D.asor-wimse-agent-delegation-chain] (authority only) and to
channel-encryption approaches such as MLS-based agent transports
[RFC9420] (information scoped per channel, not per delegation).
7. Audit Chain
7.1. Audit Record
Every capsule carries an audit record:
{
"capsule_id": "cap_01J00000000000000000000000",
"capsule_hash": "base64url-sha256",
"parent_capsule_hash": null,
"previous_chain_hash": null,
"chain_hash": "base64url-sha256"
}
Delegation capsules (delegate_create) additionally carry
parent_audit: the audit record of the capsule being delegated from.
Result capsules that continue a thread use the same parent-link form.
7.2. Capsule Hash
capsule_hash = SHA-256(canonical_json(
capsule with its top-level "audit" field removed))
encoded base64url without padding. The audit field is excluded
because it would otherwise hash itself. Because the capsule body
includes the capability chain, the encrypted payload, and the header,
capsule_hash commits to the exact grants under which a delegation was
made, without revealing them to anyone holding only the hash.
Atakora Expires 24 March 2027 [Page 15]
Internet-Draft SADP Delegation Chains September 2026
7.3. Chain Hash
chain_hash = SHA-256(
"sadp-audit-chain-v0.1\n" ||
"capsule_hash:" || capsule_hash || "\n" ||
"parent_capsule_hash:" || (parent_capsule_hash or "null") || "\n" ||
"previous_chain_hash:" || (previous_chain_hash or "null"))
encoded base64url without padding.
7.4. Receiver Verification
A receiver of a delegation capsule MUST verify:
1. audit.capsule_id equals the delivered capsule's identifier;
2. audit.capsule_hash equals the recomputed capsule hash;
3. parent_audit.chain_hash is internally valid (recomputable from
parent_audit's own fields);
4. audit.chain_hash is internally valid;
5. audit.parent_capsule_hash == parent_audit.capsule_hash;
6. audit.previous_chain_hash == parent_audit.chain_hash.
7.5. Trust Model of the Audit Chain
Audit records are hash commitments, not signatures. They are tamper-
evident relative to a trusted head: a party that has authenticated
any capsule in a lineage (for example, the user who created the root
task and retains its chain_hash) can detect substitution, reordering,
or omission below that point, and a broker's stored audit view can be
checked for omissions against receipts. A fabricated but internally
consistent chain is detectable only by comparison against an
authentic head. Receivers in this version verify one-hop parent
linkage (capsule plus parent_audit); anchoring full lineages to an
external transparency log in the style of SCITT [RFC9943], including
agent-action receipt profiles [I-D.noa-scitt-ai-agent-receipt], and
signed provenance chains in the style of [HDP], are the intended
hardening path and are out of scope for this version. This
limitation is restated normatively in Section 10.
Atakora Expires 24 March 2027 [Page 16]
Internet-Draft SADP Delegation Chains September 2026
8. Carriage in Encrypted Task Capsules
Grants and audit records are fields of the task capsule. In the v0.2
capsule profile of [SADP-PROTO], the capabilities, audit, and
parent_audit fields are authenticated outer capsule fields: they are
integrity-protected by signatures and audit hashes and are verified
by the recipient before encrypted payload plaintext is released, but
brokers that store complete capsules may observe their metadata. The
encrypted payload and encrypted context objects remain confidential
from infrastructure.
A future private-delegation-evidence profile may carry grant bodies,
context references, and detailed audit records inside an encrypted
inner body while leaving only public commitments in the outer
capsule. Such a profile MUST still bind, at minimum, the capsule
identifier and the sender and recipient principals into authenticated
data and MUST provide equivalent verification inputs to the receiver
before task plaintext is released.
Deployments carrying this delegation layer over an envelope other
than [SADP-PROTO] MUST ensure the envelope provides end-to-end
integrity over the capsule fields referenced by the verification
algorithm (Section 4.3) and confidentiality against intermediaries,
and SHOULD bind capsule identity and endpoint principals into the
envelope's authenticated data.
9. Error Handling
Verifiers MUST reject, and SHOULD distinguish for diagnostics
(without leaking to untrusted parties which check failed on private
fields):
* structural errors: nesting depth exceeded, malformed principal
identifiers, duplicate JSON keys, unknown scheme identifiers;
* signature errors: root issuer untrusted, unresolvable intermediate
key, signature verification failure, parent hash mismatch;
* attenuation errors: any violation of rules 1-6 of Section 4.2;
* freshness errors: any expired link;
* binding errors: holder/recipient mismatch, task mismatch, action/
resource mismatch;
* caveat errors: unrecognized caveat identifier.
Atakora Expires 24 March 2027 [Page 17]
Internet-Draft SADP Delegation Chains September 2026
A capsule whose chain fails verification MUST NOT have its payload
released to application code.
10. Security Considerations
What chain verification provides. A verified chain proves that a
trusted root authorized the leaf holder, through named
intermediaries, for exactly the stated action, resource subtree,
task, and validity window, under accumulated caveats, with each link
signed by the principal that held the parent authority. Splicing a
subtree onto a different parent fails the parent_grant_hash check;
broadening any field fails attenuation checking; using another
principal's chain fails holder binding; replaying a chain on a
different task fails task binding.
What it does not provide:
Revocation. This version has no capability revocation; expiry is the
only lifetime bound. Issuers SHOULD keep expires_at short
(minutes to hours, matched to task duration). A future revision
is expected to adopt a status-list mechanism in the style of
[I-D.asor-wimse-agent-delegation-chain] so that issuers and
intermediate delegators can revoke sub-chains. Runtime revocation
at the registry (removing a principal's key binding) bounds future
chains but not already-issued ones.
Post-disclosure control. Caveats such as delete_after_result and
no_external_network are attributable obligations, not enforced
confinement. A holder that has decrypted context can misuse it;
this is the endpoint-compromise boundary shared by all end-to-end
encrypted systems.
Collusion. Two authorized delegatees, or a delegatee and an outside
party, can pool what each legitimately decrypts. Scoped context
disclosure bounds what each principal receives; it cannot bound
what recipients do with received plaintext.
Audit fabrication. Per Section 7, audit records are unsigned
commitments; verification is relative to a trusted head, and only
one-hop linkage is normatively verified in this version.
Deployments requiring third-party-auditable lineage MUST anchor
chain heads in a signed or transparency-logged structure.
Key resolution trust. The verification algorithm is only as strong
Atakora Expires 24 March 2027 [Page 18]
Internet-Draft SADP Delegation Chains September 2026
as resolve_key and the trusted-issuer set. A registry that can
substitute signing keys for a principal can mint chains for that
principal's name. Registries MUST be treated as partially trusted
identity infrastructure, with key changes auditable; workload-
identity systems ([I-D.ietf-wimse-arch], [SPIFFE]) are the
appropriate substrate.
Holder key compromise. A compromised holder key permits full use and
(if depth remains) further attenuated delegation of that holder's
grants until expiry. Short expiry and no_further_delegation on
leaf grants limit the blast radius.
Clock skew. Expiry comparison is exact epoch-second comparison
against the verifier's clock. Implementations MAY apply a small
negative skew allowance (treating nearly-expired grants as
expired) but MUST NOT extend validity beyond expires_at.
Denial of service. The structural depth cap (8) bounds signature
verifications and hash computations per chain to a small constant
before any expensive work is attempted.
Cross-protocol confusion. All SADP signature and hash domains carry
distinct versioned domain-separation prefixes; a capability
signature cannot verify as a session, prekey, broker-request, or
audit value.
11. Privacy Considerations
Grants name principals and resources. In the v0.2 outer capsule
profile, brokers that store complete capsules can observe grant and
audit metadata, including resource names and lineage shape; the
encrypted task payload and context objects remain confidential. The
receiving endpoint also sees the full ancestry of its authority,
including upstream principal identifiers and resource names.
Deployments SHOULD use opaque or pseudonymous segment names for
resources whose identifiers are themselves sensitive (blob:d41d8cd9/
s3-8 rather than blob:acme_acquisition_agreement/indemnity), since
hierarchical names leak structure to every party that can observe the
grant and every downstream delegatee.
Key-release endpoints and context stores observe which principals
request which resource identifiers; this metadata SHOULD be minimized
and retained per the deployment's audit policy. Audit hashes reveal
lineage shape (fan-out, depth, timing) but not content; parties for
whom lineage shape is sensitive should treat audit stores as
metadata-bearing.
Atakora Expires 24 March 2027 [Page 19]
Internet-Draft SADP Delegation Chains September 2026
12. IANA Considerations
This document makes no request of IANA at Internet-Draft stage. If
published, it would request creation of a new registry group, "Secure
Agent Delegation Protocol (SADP)", containing the following registry.
12.1. SADP Capability Caveats Registry
Registration policy: Specification Required [RFC8126]. The
designated experts are instructed to require: a precise statement of
the behavioral obligation on the holder; whether violation is
detectable and by whom; and confirmation that the caveat is a
restriction (never an expansion) of authority.
Initial registrations:
+=======================+===========+===========================+
| Caveat Identifier | Reference | Description |
+=======================+===========+===========================+
| no_external_network | This | Holder must not make non- |
| | document | SADP network requests |
| | | while performing the |
| | | authorized task |
+-----------------------+-----------+---------------------------+
| delete_after_result | This | Holder must delete |
| | document | decrypted content and |
| | | derivatives after result |
| | | delivery |
+-----------------------+-----------+---------------------------+
| no_further_delegation | This | Holder must not derive |
| | document | child grants; attenuation |
| | | from this grant is |
| | | invalid |
+-----------------------+-----------+---------------------------+
Table 1: Initial SADP Capability Caveat registrations
13. References
13.1. Normative References
[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/rfc/rfc2119>.
Atakora Expires 24 March 2027 [Page 20]
Internet-Draft SADP Delegation Chains September 2026
[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/rfc/rfc3339>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/rfc/rfc4648>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/rfc/rfc6234>.
[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/rfc/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/rfc/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
13.2. Informative References
[A2A] Agentic AI Foundation, "Agent2Agent (A2A) Protocol
Specification", 2026,
<https://a2a-protocol.org/latest/specification/>.
[BISCUIT] Couprie, G., "Biscuit: Bearer Tokens with Offline
Attenuation and Decentralized Verification", 2021,
<https://www.biscuitsec.org/>.
[HDP] "A Lightweight Cryptographic Protocol for Human Delegation
Provenance", April 2026,
<https://arxiv.org/abs/2604.04522>.
[I-D.asor-wimse-agent-delegation-chain]
Asor, R., "Verifiable Attenuated Delegation for AI Agent
Chains", Work in Progress, Internet-Draft, draft-asor-
wimse-agent-delegation-chain-01, 3 September 2026,
<https://datatracker.ietf.org/doc/html/draft-asor-wimse-
agent-delegation-chain-01>.
Atakora Expires 24 March 2027 [Page 21]
Internet-Draft SADP Delegation Chains September 2026
[I-D.hamr-oauth-agent-delegation]
"An Attenuated Delegation Profile for Automated Agents",
Work in Progress, Internet-Draft, draft-hamr-oauth-agent-
delegation, n.d., <https://datatracker.ietf.org/doc/draft-
hamr-oauth-agent-delegation/>.
[I-D.ietf-wimse-arch]
Salowey, J. A., Rosomakho, Y., and H. Tschofenig,
"Workload Identity in a Multi System Environment (WIMSE)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-wimse-arch-08, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-08>.
[I-D.li-oauth-delegated-authorization]
"OAuth 2.0 Delegated Authorization", Work in Progress,
Internet-Draft, draft-li-oauth-delegated-authorization,
n.d., <https://datatracker.ietf.org/doc/draft-li-oauth-
delegated-authorization/>.
[I-D.liu-oauth-chain-delegation]
"OAuth Chain Delegation for AI Agents", Work in Progress,
Internet-Draft, draft-liu-oauth-chain-delegation, n.d.,
<https://datatracker.ietf.org/doc/draft-liu-oauth-chain-
delegation/>.
[I-D.nelson-agent-delegation-receipts]
"Delegation Receipt Protocol for AI Agent Authorization",
Work in Progress, Internet-Draft, draft-nelson-agent-
delegation-receipts, n.d.,
<https://datatracker.ietf.org/doc/draft-nelson-agent-
delegation-receipts/>.
[I-D.noa-scitt-ai-agent-receipt]
Toraman, T., "A SCITT Profile for AI-Agent Action
Receipts", Work in Progress, Internet-Draft, draft-noa-
scitt-ai-agent-receipt-01, 14 August 2026,
<https://datatracker.ietf.org/doc/html/draft-noa-scitt-ai-
agent-receipt-01>.
[I-D.sharif-agent-transport-protocol]
"Agent Transport Protocol: Asynchronous Store-and-Forward
Messaging for Autonomous AI Agents", Work in Progress,
Internet-Draft, draft-sharif-agent-transport-protocol,
n.d., <https://datatracker.ietf.org/doc/draft-sharif-
agent-transport-protocol/>.
Atakora Expires 24 March 2027 [Page 22]
Internet-Draft SADP Delegation Chains September 2026
[I-D.sharif-attp]
"ATTP: Agent Trust Transport Protocol", Work in Progress,
Internet-Draft, draft-sharif-attp, n.d.,
<https://datatracker.ietf.org/doc/draft-sharif-attp/>.
[I-D.singla-agent-identity-protocol]
"Agent Identity Protocol (AIP): Decentralized Identity and
Delegation for AI Agents", Work in Progress, Internet-
Draft, draft-singla-agent-identity-protocol, n.d.,
<https://datatracker.ietf.org/doc/draft-singla-agent-
identity-protocol/>.
[I-D.vandoulas-aidp]
"Agent Interaction and Delegation Protocol (AIDP)", Work
in Progress, Internet-Draft, draft-vandoulas-aidp, n.d.,
<https://datatracker.ietf.org/doc/draft-vandoulas-aidp/>.
[MACAROONS]
Birgisson, A., Politz, J. G., Erlingsson, U., Taly, A.,
Vrable, M., and M. Lentczner, "Macaroons: Cookies with
Contextual Caveats for Decentralized Authorization in the
Cloud", DOI 10.14722/ndss.2014.23212, February 2014,
<https://research.google/pubs/pub41892/>.
[MCP] Model Context Protocol Project, "Model Context Protocol
Specification", 2025, <https://modelcontextprotocol.io/
specification/2025-06-18>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
[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/rfc/rfc8785>.
[RFC9420] Barnes, R., Beurdouche, B., Robert, R., Millican, J.,
Omara, E., and K. Cohn-Gordon, "The Messaging Layer
Security (MLS) Protocol", RFC 9420, DOI 10.17487/RFC9420,
July 2023, <https://www.rfc-editor.org/rfc/rfc9420>.
Atakora Expires 24 March 2027 [Page 23]
Internet-Draft SADP Delegation Chains September 2026
[RFC9635] Richer, J., Ed. and F. Imbault, "Grant Negotiation and
Authorization Protocol (GNAP)", RFC 9635,
DOI 10.17487/RFC9635, October 2024,
<https://www.rfc-editor.org/rfc/rfc9635>.
[RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande,
Y., and S. Lasker, "An Architecture for Trustworthy and
Transparent Digital Supply Chains", RFC 9943,
DOI 10.17487/RFC9943, June 2026,
<https://www.rfc-editor.org/rfc/rfc9943>.
[SADP-PROTO]
Atakora, H., "The Secure Agent Delegation Protocol (SADP):
End-to-End Encrypted Task Capsules", Work in Progress,
Internet-Draft, draft-atakora-sadp-protocol-00, September
2026, <https://datatracker.ietf.org/doc/html/draft-
atakora-sadp-protocol-00>.
[SPIFFE] SPIFFE Project, "Secure Production Identity Framework For
Everyone (SPIFFE)", 2024, <https://spiffe.io/>.
[UCAN] UCAN Working Group, "UCAN: User-Controlled Authorization
Networks Specification", 2024,
<https://github.com/ucan-wg/spec>.
Appendix A. Worked Example: Two-Hop Delegation with Context Narrowing
Alice asks her contract-reviewer agent to review a contract,
permitting it to consult a legal-reviewer agent on sections 3 and 8
only.
Step 1. Root grant. Alice's device signs a root grant to the
contract-reviewer runtime:
{
"issuer": "user:alice/device:phone",
"holder": "agent:contract-reviewer/runtime:prod-a",
"action": "read",
"resource": "blob:contract_pdf",
"task_id": "task_01J00000000000000000000000",
"expires_at": "2026-09-19T13:00:00Z",
"max_delegation_depth": 1,
"caveats": ["delete_after_result"],
"parent_grant_hash": null,
"parent": null,
"signature": "MEd...root-sig..."
}
Atakora Expires 24 March 2027 [Page 24]
Internet-Draft SADP Delegation Chains September 2026
Signing input (elided): "SADP capability grant v0.2\n" followed by
the canonical JSON of the signed structure with "parent_grant_hash":
null and "expires_at_epoch_seconds": 1789822800.
The grant travels as an authenticated outer capsule field to the
contract-reviewer runtime, alongside an encrypted task payload
carrying the context reference for blob:contract_pdf and its wrapped
content key. The broker can observe the grant metadata in v0.2, but
routes opaque encrypted task and context bytes.
Step 2. Attenuated child grant. The contract-reviewer runtime
extracts sections 3 and 8 into a new context object, encrypts it
under a fresh content key with resource identifier blob:contract_pdf/
sections_3_8, and signs a child grant to the legal-reviewer:
{
"issuer": "agent:contract-reviewer/runtime:prod-a",
"holder": "agent:legal-reviewer/runtime:prod-b",
"action": "read",
"resource": "blob:contract_pdf/sections_3_8",
"task_id": "task_01J00000000000000000000000",
"expires_at": "2026-09-19T12:45:00Z",
"max_delegation_depth": 0,
"caveats": ["delete_after_result", "no_further_delegation"],
"parent_grant_hash": "u5Zt...b64url-sha256-of-root...",
"parent": { ...the complete root grant, including its signature... },
"signature": "MEd...child-sig..."
}
The child's signing input carries "parent_grant_hash":
"u5Zt...b64url-sha256-of-root...".
Attenuation check against Section 4.2: issuer continuity (child
issuer is the root holder); action equality (read); resource
narrowing (blob:contract_pdf/sections_3_8 extends blob:contract_pdf +
/); expiry narrowed (12:45 <= 13:00); depth decremented (0 <= 1 - 1);
caveats accumulated (delete_after_result retained,
no_further_delegation added).
Atakora Expires 24 March 2027 [Page 25]
Internet-Draft SADP Delegation Chains September 2026
Step 3. Verification at the legal-reviewer. The legal-reviewer
runtime receives the delegation capsule, flattens the chain (depth
2), checks Alice's device is a trusted issuer and verifies the root
signature, resolves the contract-reviewer's signing key via the
registry, verifies the parent hash link and the child signature,
checks all six attenuation rules, checks both links unexpired, checks
it is the holder, the task matches, and that read on
blob:contract_pdf/sections_3_8 covers its intended use, and
recognizes both caveats. Only then is the payload decrypted, and the
validation API returns EnforcedCaveats = {delete_after_result,
no_further_delegation} together with the plaintext.
The legal-reviewer never receives the content key for
blob:contract_pdf, cannot decrypt the full contract, and cannot
delegate further: rule 6 makes any grant it might mint invalid at
every honest verifier.
Step 4. Audit linkage. The delegation capsule carries parent_audit
(the root task capsule's audit record) and its own audit record with
parent_capsule_hash and previous_chain_hash linking to it. Alice,
who retains the root chain_hash, can later verify that the legal-
reviewer's result capsule descends from her original task and that no
intermediate delegation was substituted without any party disclosing
task plaintext to the broker or audit store.
Appendix B. Comparison with Related Delegation Mechanisms
+================+===========+=======+========+============+========+
| Property | Macaroons |Biscuit|RFC 8693| draft-asor |This |
| | |/ UCAN | | |document|
+================+===========+=======+========+============+========+
| Offline | Yes |Yes |No (STS | Yes |Yes |
| attenuation | | |round | | |
| | | |trip) | | |
+----------------+-----------+-------+--------+------------+--------+
| Public key | No (HMAC |Yes |Bearer/ | Yes |Yes |
| holder | bearer) | |PoP | | |
| binding | | |options | | |
+----------------+-----------+-------+--------+------------+--------+
| Enforced | Caveats |Yes |No (act | Yes |Yes |
| constraint | | |is | |(rules |
| subsumption | | |history)| |1-6) |
+----------------+-----------+-------+--------+------------+--------+
| Anti-splicing | N/A |Varies |N/A | par_hash |Yes |
| parent hash | | | | |(grant |
| | | | | |hash) |
+----------------+-----------+-------+--------+------------+--------+
| Bound to E2EE | No |No |No | No |Yes |
Atakora Expires 24 March 2027 [Page 26]
Internet-Draft SADP Delegation Chains September 2026
| task/context | | | | | |
| payload | | | | | |
+----------------+-----------+-------+--------+------------+--------+
| Joint | No |No |No | No |Yes |
| attenuation | | | | | |
| of | | | | | |
| information | | | | | |
| (context | | | | | |
| keys) | | | | | |
+----------------+-----------+-------+--------+------------+--------+
| Revocation | No |Varies |Token | Status |Not in |
| | | |lifetime| list |v0.2 |
+----------------+-----------+-------+--------+------------+--------+
Table 2: Delegation mechanism comparison (informative)
Acknowledgments
This design draws on the attenuation lineage of Macaroons, Biscuit,
and UCAN; on the agent delegation chain construction of draft-asor-
wimse-agent-delegation-chain; and on the secure messaging tradition
whose envelope constructions the companion SADP protocol document
adapts. Errors are the author's own.
Author's Address
Hamdy Atakora
Imara Labs
United States
Email: hatakora@imaralabs.dev
Atakora Expires 24 March 2027 [Page 27]