]> Imara Labs

United States hatakora@imaralabs.dev

Security Individual Submission AI agents delegation capabilities attenuation end-to-end encryption audit 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.

Introduction

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 and 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 , Biscuit , UCAN , OAuth 2.0 Token Exchange , GNAP ) 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 , 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.

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.

Relationship to draft-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 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 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: addresses synchronous trust transport, addresses asynchronous store-and-forward transport, addresses cross-domain delegation headers, addresses OAuth-based chained delegation tokens, addresses constrained client-issued delegated authorization tokens, addresses decentralized agent identity and delegation, addresses governed intent/execution control, and 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.

Relationship to the SADP Capsule Protocol The companion document 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 .

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 when, and only when, they appear in all capitals, as shown here.

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

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

Delegation Chain (Chain):

A grant together with its transitively embedded parent grants, ending at a root grant ().

Attenuation:

Deriving a child grant from a parent grant such that the child's authority is a strict subset of the parent's ().

Caveat:

A named restriction carried by a grant that the receiving application must honor ().

Task Capsule (Capsule):

The SADP message envelope carrying a task, its grants, its context references, and its audit record . 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 ().

Audit Record:

A hash commitment linking a capsule to its delegation parent and to a running chain hash ().

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.

Data Model

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:

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 ;
• no insignificant whitespace is emitted;
• binary values are base64url without padding ;
• timestamps are RFC 3339 strings in documents and integer epoch seconds inside signing inputs.

This profile is intentionally close to JCS ; 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.

Capability Grant Structure A grant is a JSON object: 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 (). 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 (). 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 signature over the signing input defined in . REQUIRED.

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: where parent_grant_hash is:

• null for a root grant; otherwise
• base64url (no padding) of SHA-256 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 . 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.

Delegation Chains

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 , and parent set to the full parent grant;
2. computes parent_grant_hash over the parent as defined in ;
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.

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 + "/" ().
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 and carried into public key delegation systems by Biscuit and UCAN . Unlike bearer-token attenuation, each link here is bound to a named holder key, so possession of chain bytes alone conveys no authority.

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

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 is checked per link.

Caveats

Processing Model Caveats are first-party restrictions in the Macaroons sense : 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 .

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 ), regardless of remaining max_delegation_depth.

These are behavioral obligations on the holder; cryptography cannot force a holder to honor them after plaintext release (). Their value is that they are signed, non-droppable, verifier-checked statements of the authorized behavior, which makes violations attributable.

Scoped Context Disclosure

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

Hierarchical Resource Naming Resource identifiers are /-separated hierarchies rooted in a typed name, for example: Rule 3 of 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.

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 (authority only) and to channel-encryption approaches such as MLS-based agent transports (information scoped per channel, not per delegation).

Audit Chain

Audit Record Every capsule carries an audit record: 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.

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

Chain Hash encoded base64url without padding.

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.

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 , including agent-action receipt profiles , and signed provenance chains in the style of , are the intended hardening path and are out of scope for this version. This limitation is restated normatively in .

Carriage in Encrypted Task Capsules Grants and audit records are fields of the task capsule. In the v0.2 capsule profile of , 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 MUST ensure the envelope provides end-to-end integrity over the capsule fields referenced by the verification algorithm () and confidentiality against intermediaries, and SHOULD bind capsule identity and endpoint principals into the envelope's authenticated data.

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 ;
• freshness errors: any expired link;
• binding errors: holder/recipient mismatch, task mismatch, action/resource mismatch;
• caveat errors: unrecognized caveat identifier.

A capsule whose chain fails verification MUST NOT have its payload released to application code.

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 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 , 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 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 (, ) 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.

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.

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.

SADP Capability Caveats Registry Registration policy: Specification Required . 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: Initial SADP Capability Caveat registrations

Caveat Identifier	Reference	Description
no_external_network	This document	Holder must not make non-SADP network requests while performing the authorized task
delete_after_result	This document	Holder must delete decrypted content and derivatives after result delivery
no_further_delegation	This document	Holder must not derive child grants; attenuation from this grant is invalid

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. Federal Information Processing Standard, FIPS This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Informative References This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. The Grant Negotiation and Authorization Protocol (GNAP) defines a mechanism for delegating authorization to a piece of software and conveying the results and artifacts of that delegation to the software. This delegation can include access to a set of APIs as well as subject information passed directly to the software. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two clients need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy (FS) and post-compromise security (PCS) for groups in size ranging from two to thousands. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. Attenu AI agents increasingly delegate tasks to other agents. Each delegation should convey only a subset of the delegating party's authority, that subset should be bounded in scope, magnitude, and time, and any enforcement point should be able to verify -- offline, with no call to an authorization server -- that a token presented at hop N carries authority no greater than the token at hop N-1, back to a trusted root. OAuth 2.0 Token Exchange (RFC 8693) models two-party delegation and records prior actors in a nested "act" claim, but that claim is informational only and cannot enforce attenuation across a chain of depth two or more. This document defines the Agent Delegation Chain: a profile of OAuth 2.0 JWT access tokens (RFC 9068) that carries authority as Rich Authorization Requests (RFC 9396), links each delegation to its parent by a cryptographic byte- commitment, and specifies a deterministic offline verification algorithm that enforces monotonic attenuation, bounded depth, and monotonic expiry. It reuses existing JOSE, proof-of-possession (RFC 9449), and status-list machinery (the OAuth Status List draft) and introduces no new cryptography. Palo Alto Networks Zscaler University of the Bundeswehr Munich The increasing prevalence of cloud computing and micro service architectures has led to the rise of complex software functions being built and deployed as workloads, where a workload is defined as software executing for a specific purpose, potentially comprising one or more running instances. This document discusses an architecture for designing and standardizing protocols and payloads for conveying workload identity and security context information. NordenSoft This document profiles the IETF SCITT (Supply Chain Integrity, Transparency, and Trust) architecture for AI-agent action receipts: tamper-evident, signed, offline-verifiable records of what an autonomous agent was recorded as doing at the governed boundary, under which recorded principal class, with what recorded verdict, and -- where the issuer records one -- under which policy identity. Each receipt is a signed record over a canonical JSON payload, hash- chained so that each record commits to its predecessor, and presented either bare -- the payload with its own native signature -- or enveloped in a COSE_Sign1. This revision specifies how such a receipt is carried as a SCITT Signed Statement, with the protected claims a Transparency Service requires, so that a receipt can be registered. Registration obtains a Transparency Service's signed proof that the statement was registered in its log -- a property a self-signed chain cannot provide alone. It does not, by itself, give an offline holder non-equivocation: that requires consistency proofs and monitoring of the log, which this profile does not specify. The profile makes a deliberately narrow, checkable claim: this is an issuer-authenticated, signature-verifiable, tamper-evident record of the action, the recorded principal class, the recorded verdict, and any policy identity the receipt carries. It explicitly does not claim that the agent was correct, safe, or wise, that the recorded inputs were true or complete, that a named approver authorized this exact action before it ran, that a downstream controller succeeded, or that any physical effect occurred. This revision separates those last three as distinct claims with independent failure behaviour, states the boundary of a shared action digest, and keeps a deterministic offline policy-replay capability out of scope. n.d. n.d. n.d. n.d. n.d. n.d. n.d. n.d. UCAN Working Group SPIFFE Project Agentic AI Foundation Model Context Protocol Project

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: 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: The child's signing input carries "parent_grant_hash": "u5Zt...b64url-sha256-of-root...". Attenuation check against : 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). 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.

Comparison with Related Delegation Mechanisms Delegation mechanism comparison (informative)

Property	Macaroons	Biscuit / UCAN	RFC 8693	draft-asor	This document
Offline attenuation	Yes	Yes	No (STS round trip)	Yes	Yes
Public key holder binding	No (HMAC bearer)	Yes	Bearer/PoP options	Yes	Yes
Enforced constraint subsumption	Caveats	Yes	No (act is history)	Yes	Yes (rules 1-6)
Anti-splicing parent hash	N/A	Varies	N/A	par_hash	Yes (grant hash)
Bound to E2EE task/context payload	No	No	No	No	Yes
Joint attenuation of information (context keys)	No	No	No	No	Yes
Revocation	No	Varies	Token lifetime	Status list	Not in v0.2

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.