Capability-Bound Delegation Chains with Scoped Context Disclosure for AI Agents

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 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:¶

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.¶

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.¶

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 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.¶

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.¶

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.¶

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.¶

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.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.¶

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.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.¶

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.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.¶

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.¶

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:¶

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>.

[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>.

[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/>.

[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>.

[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-02, September 2026, <https://datatracker.ietf.org/doc/html/draft-atakora-sadp-protocol-02>.

[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>.