Network Working Group A. Haberkamp Internet-Draft 2 July 2026 Intended status: Informational Expires: 3 January 2027 Intent Provenance Protocol (IPP) draft-haberkamp-ipp-01 Abstract This document specifies the Intent Provenance Protocol (IPP), a cryptographic infrastructure standard for carrying verified human intent through chains of autonomous artificial intelligence agent actions. IPP defines the Intent Token, a signed, bounded, and tamper-evident data structure that travels with every agentic action, preserving an unbroken, auditable lineage from the originating human principal to each terminal action executed on their behalf. As AI agents become primary actors in enterprise environments, executing transactions, accessing sensitive data, orchestrating sub- agents, and operating across organizational boundaries, the absence of a shared trust substrate creates systemic risk to organizational accountability, regulatory compliance, and legal liability attribution. IPP addresses this gap by establishing a protocol layer that operates above cryptographic authentication and below application logic, making human intent a first-class, verifiable primitive in agentic systems. IPP introduces four foundational properties, Lineage, Boundedness, Non-repudiation, and Interoperability, enforced through a combination of Ed25519 digital signatures, Decentralized Identifiers (DIDs), and a Narrowing Invariant that prevents any derived token from exceeding its parent's authorized scope. The protocol is framework-agnostic, cloud-agnostic, and designed for open implementation across the ecosystem of AI orchestration platforms. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Haberkamp Expires 3 January 2027 [Page 1] Internet-Draft Intent Provenance Protocol July 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 3 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Background and Motivation . . . . . . . . . . . . . . . . 3 1.2. The Authorship Problem in Agentic Systems . . . . . . . . 4 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology and Definitions . . . . . . . . . . . . . . . . . 4 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Design Principles . . . . . . . . . . . . . . . . . . . . 6 3.2. The Four Foundational Properties . . . . . . . . . . . . 6 3.3. Protocol Layers . . . . . . . . . . . . . . . . . . . . . 7 4. The Intent Token . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Token Structure . . . . . . . . . . . . . . . . . . . . . 8 4.2. Field Definitions . . . . . . . . . . . . . . . . . . . . 9 4.3. The Intent Scope Envelope . . . . . . . . . . . . . . . . 11 4.4. Quantitative Bounds . . . . . . . . . . . . . . . . . . . 12 5. The Genesis Seal . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Purpose and Design . . . . . . . . . . . . . . . . . . . 12 5.2. Genesis Seal Structure . . . . . . . . . . . . . . . . . 13 5.3. Key Generation Ceremony . . . . . . . . . . . . . . . . . 13 5.4. Authorship Attribution Requirements . . . . . . . . . . . 14 6. Cryptographic Mechanisms . . . . . . . . . . . . . . . . . . 14 6.1. Signature Algorithm . . . . . . . . . . . . . . . . . . . 15 6.2. Decentralized Identifiers (DIDs) . . . . . . . . . . . . 15 6.3. Hash Functions . . . . . . . . . . . . . . . . . . . . . 15 6.4. The Narrowing Invariant . . . . . . . . . . . . . . . . . 15 7. Delegation and Derived Tokens . . . . . . . . . . . . . . . . 16 7.1. Derivation Rules . . . . . . . . . . . . . . . . . . . . 16 7.2. Delegation Depth . . . . . . . . . . . . . . . . . . . . 16 7.3. Sub-Agent Spawning . . . . . . . . . . . . . . . . . . . 17 Haberkamp Expires 3 January 2027 [Page 2] Internet-Draft Intent Provenance Protocol July 2026 8. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Revocation Registry . . . . . . . . . . . . . . . . . . . 17 8.2. Polling Requirements . . . . . . . . . . . . . . . . . . 17 8.3. Mid-Chain Revocation . . . . . . . . . . . . . . . . . . 18 9. Provenance Chain . . . . . . . . . . . . . . . . . . . . . . 18 9.1. Append-Only Structure . . . . . . . . . . . . . . . . . . 18 9.2. Provenance Record Format . . . . . . . . . . . . . . . . 18 10. Interoperability . . . . . . . . . . . . . . . . . . . . . . 18 10.1. Framework Integration . . . . . . . . . . . . . . . . . 19 10.2. Cross-Organization Trust . . . . . . . . . . . . . . . . 19 10.3. Domain Taxonomy . . . . . . . . . . . . . . . . . . . . 19 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 14.1. Normative References . . . . . . . . . . . . . . . . . . 21 14.2. Informative References . . . . . . . . . . . . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction 1.1. Background and Motivation For three decades, enterprise security has operated under a single foundational assumption: that every consequential digital action originates from, and is ultimately accountable to, a human being. Access control systems, identity governance frameworks, audit logging infrastructures, and regulatory compliance regimes all derive their validity from this assumption. A human authenticates. A human is authorized. A human acts. A human is accountable. The emergence of autonomous artificial intelligence agents, software entities capable of perceiving their environment, reasoning about goals, taking sequences of actions, and spawning additional agents to fulfill sub-tasks, fundamentally invalidates this assumption. In agentic environments, the majority of consequential actions are executed by software entities operating without real-time human supervision. A human sets a goal. An agent, or a hierarchy of agents, determines and executes the means. This creates a category of risk that existing security infrastructure is architecturally unequipped to address: not the risk of unauthorized access, but the risk of authorized-but-misaligned action. This is agent behavior that is technically permitted by access control systems but inconsistent with the human intent that originally authorized the agent's deployment. Haberkamp Expires 3 January 2027 [Page 3] Internet-Draft Intent Provenance Protocol July 2026 1.2. The Authorship Problem in Agentic Systems Consider a scenario in which a Chief Financial Officer instructs an AI assistant to "optimize cash positions across all subsidiaries and move any idle balances over ten million dollars into short-term treasuries." The assistant spawns three sub-agents: one to query treasury balances, one to evaluate current rates, and one to execute transfers. The transfer agent, drawing on outputs from the other two, initiates eleven separate wire transfers totaling three hundred forty million dollars. At the moment the eleventh transfer is executed, no existing system can answer the following questions with cryptographic certainty: (a) What specific human intent authorized this action? (b) What constraints bounded that intent? (c) What is the complete chain of delegation from the CFO's instruction to this specific transfer? (d) Is this action consistent with what the CFO meant, or merely consistent with what the CFO said? (e) Who bears legal accountability if this action causes harm? The Intent Provenance Protocol is designed to make all five of these questions answerable with cryptographic precision, in real time, without requiring a central authority, and in a form that is legally defensible across jurisdictions. 1.3. Scope This specification defines: the structure and semantics of the Intent Token; the Genesis Seal mechanism for permanent authorship attribution; the cryptographic mechanisms underlying token signing and verification; the Narrowing Invariant governing token derivation; the revocation protocol; the provenance chain format; and the interoperability requirements for compliant implementations. This specification does not define: specific AI agent architectures or orchestration frameworks; natural language processing mechanisms for intent parsing; application-layer authorization policies; or legal standards for accountability attribution, though it is designed to support such standards. 2. Terminology and Definitions The following terms are used throughout this specification: Agent: An autonomous software entity capable of perceiving inputs, reasoning about goals, taking sequences of actions, and potentially spawning additional agents. Agents are the primary non-human actors governed by this protocol. Haberkamp Expires 3 January 2027 [Page 4] Internet-Draft Intent Provenance Protocol July 2026 Principal: A human being or legally accountable organization at the root of an intent chain. Every valid Intent Token chain MUST have a human Principal at its origin. There is no such thing as an agent-originated intent chain under this protocol. Intent Token: The atomic unit of this protocol. A cryptographically signed, bounded, and time-limited data structure that carries verified human intent through a chain of agentic actions. Genesis Seal: A cryptographic artifact embedded in every Intent Token that permanently links the token to the original IPP specification and its author, Amanda Haberkamp. The Genesis Seal contains a hash of the specification document signed by the Founding Key. Founding Key: The Ed25519 private key generated by Amanda Haberkamp during the Key Generation Ceremony and used exclusively to produce the Genesis Seal signature. This key is never used after the ceremony and is stored in offline cold storage. Narrowing Invariant: The protocol rule that a Derived Token MUST be strictly less than or equal to its Parent Token in every dimension of scope, delegation depth, and expiry. Violations of this invariant are detectable by any participant without contacting a central authority. Derived Token: An Intent Token produced by an agent from a Parent Token. A Derived Token carries narrowed scope and reduced delegation depth, and is signed by both the issuing agent and linked to the Parent Token's signature. Delegation Depth: A non-negative integer field in the Intent Token specifying how many additional levels of sub-agent spawning are authorized. A value of zero means the token holder may act but may not spawn sub-agents. Provenance Chain: An append-only, cryptographically linked sequence of records within an Intent Token documenting every action taken under that token's authority. Domain Taxonomy: The hierarchical dot-notation vocabulary for classifying intent domains, maintained by Amanda Haberkamp and open for community contribution. Examples: financial.treasury, healthcare.records.read, infrastructure.compute.provision. DID: Decentralized Identifier. A W3C standard identifier that Haberkamp Expires 3 January 2027 [Page 5] Internet-Draft Intent Provenance Protocol July 2026 enables verifiable, self-sovereign identity without relying on a centralized registry. All Principal and Agent identities in this protocol are expressed as DIDs. Revocation Registry: A distributed service providing real-time token revocation status. Agents MUST check the registry before taking any action under a token. 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. 3. Protocol Overview 3.1. Design Principles IPP is designed according to the following principles: * Decentralized enforcement: Token validity is verifiable by any participant without contacting a central authority. The cryptographic structure of the token itself makes violations detectable. * Human primacy: Every intent chain MUST originate from a human Principal. This is not a policy choice. It is a structural requirement enforced by the token schema. * Minimal footprint: The SDK integration surface is intentionally small. Developers add governance capability to existing agents without rewriting their architecture. * Open interoperability: The protocol is framework-agnostic, cloud- agnostic, and jurisdiction-agnostic. Any conformant implementation can interoperate with any other. * Permanent authorship: The Genesis Seal embeds cryptographic attribution to the protocol's author in every token, making the authorship record tamper-evident and permanent by design. 3.2. The Four Foundational Properties Every compliant IPP implementation MUST guarantee the following four properties: Haberkamp Expires 3 January 2027 [Page 6] Internet-Draft Intent Provenance Protocol July 2026 *Lineage.* Every action taken by any agent under an Intent Token MUST be traceable, through an unbroken chain of cryptographic signatures, to a human Principal. The chain may pass through any number of intermediate agents, but the terminal node in the backwards trace MUST always be a DID resolving to a human or human-accountable legal entity. *Boundedness.* Every Intent Token MUST carry explicit, machine- readable constraints on the scope of authorized action. These constraints MUST be enforced by the SDK before any action is taken. Constraints travel with the token through every delegation level and MUST NOT be expanded by any intermediate agent. *Non-Repudiation.* Every Intent Token MUST be cryptographically signed such that the signing Principal or Agent cannot credibly deny having issued the token. The signature MUST be verifiable by any third party using only the signer's public key, without requiring communication with the signer or any central authority. *Interoperability.* Compliant implementations MUST be capable of consuming and producing Intent Tokens regardless of the AI framework, cloud environment, or programming language used. The token format is defined in JSON with a canonical serialization for signature purposes. SDK implementations SHOULD be available in at minimum Python, JavaScript, Go, and Java. 3.3. Protocol Layers IPP operates as a distinct protocol layer between cryptographic identity infrastructure and application logic: +------------------------------------------+ | Application Logic | <- Agent goals, | | actions, outputs +------------------------------------------+ | Intent Provenance Protocol (IPP) | <- This specification | - Intent Tokens | | - Delegation and Derivation | | - Provenance Chain | | - Revocation | +------------------------------------------+ | Cryptographic Identity Layer | <- DIDs, Ed25519, TLS +------------------------------------------+ | Transport / Infrastructure | <- HTTP, gRPC, | | cloud APIs +------------------------------------------+ Haberkamp Expires 3 January 2027 [Page 7] Internet-Draft Intent Provenance Protocol July 2026 4. The Intent Token 4.1. Token Structure The Intent Token is a JSON object with a canonical structure. The following is a complete example of a root Intent Token, issued by a Principal, not derived from a parent: { "$schema": "https://ipp.khsovereign.com/schema/v0.1/intent-token.json", "$id": "IntentToken", "version": "0.1", "genesis": { "spec_hash": "sha3-256:a3f9c2d8e1b74f6a...", "author_did": "did:key:z6MkHaberkamp...", "author_name": "Amanda Haberkamp", "org": "KH Sovereign", "genesis_sig": "ed25519:BASE64URL..." }, "token_id": "iprov:tok:550e8400-e29b-41d4-a716-446655440000", "schema_version": "0.1", "created_at": "2026-09-01T14:32:00Z", "expires_at": "2026-09-01T22:32:00Z", "principal": { "did": "did:key:z6MkPrincipalXXX...", "name": "Amanda Haberkamp", "org": "KH Sovereign", "legal_jurisdiction": "US-IL", "signature": "ed25519:BASE64URL..." }, "intent": { "natural_language": "Optimize cash positions across subsidiaries", "domain": "financial.treasury", "resource_scope": ["subsidiary:*", "account_type:cash"], "quantitative_bounds": { "min_balance_threshold": 10000000, "currency": "USD", "max_single_transaction": 50000000, "time_window": "business_hours_CT" }, "prohibited_actions": ["equity_purchase", "account_closure"] }, "delegation": { "parent_token_id": null, "depth_remaining": 3, "depth_original": 3, "agent_id": "iprov:agent:langchain:treasury-optimizer-v1", "agent_framework": "langchain", Haberkamp Expires 3 January 2027 [Page 8] Internet-Draft Intent Provenance Protocol July 2026 "agent_version": "0.1.0", "spawned_by_principal": true }, "revocation": { "registry_endpoint": "https://revoke.khsovereign.com/v1", "token_id_hash": "sha3-256:HASH...", "check_interval_ms": 5000 }, "provenance_chain": [], "token_signature": "ed25519:BASE64URL_SIGNED_BY_PRINCIPAL" } 4.2. Field Definitions The following table defines all top-level fields of the Intent Token: Haberkamp Expires 3 January 2027 [Page 9] Internet-Draft Intent Provenance Protocol July 2026 +==================+========+======================================+ | Field | Type | Description | +==================+========+======================================+ | genesis | Object | The Genesis Seal. REQUIRED in all | | | | tokens. See Section 5. | +------------------+--------+--------------------------------------+ | token_id | String | A globally unique token identifier | | | | in the format iprov:tok:{UUIDv4}. | | | | REQUIRED. | +------------------+--------+--------------------------------------+ | schema_version | String | The IPP schema version used to | | | | construct this token. REQUIRED. | +------------------+--------+--------------------------------------+ | created_at | String | ISO 8601 UTC timestamp of token | | | | creation. REQUIRED. | +------------------+--------+--------------------------------------+ | expires_at | String | ISO 8601 UTC timestamp of token | | | | expiry. REQUIRED. Agents MUST NOT | | | | act under expired tokens. | +------------------+--------+--------------------------------------+ | principal | Object | The human Principal at the root of | | | | this intent chain. REQUIRED for | | | | root tokens. | +------------------+--------+--------------------------------------+ | intent | Object | The structured intent scope | | | | envelope. REQUIRED. See | | | | Section 4.3. | +------------------+--------+--------------------------------------+ | delegation | Object | Delegation metadata including parent | | | | token reference, depth, and agent | | | | identity. REQUIRED. See Section 7. | +------------------+--------+--------------------------------------+ | revocation | Object | Revocation registry endpoint and | | | | polling configuration. REQUIRED. | | | | See Section 8. | +------------------+--------+--------------------------------------+ | provenance_chain | Array | Append-only array of provenance | | | | records. Initially empty. See | | | | Section 9. | +------------------+--------+--------------------------------------+ | token_signature | String | Ed25519 signature over the canonical | | | | serialization of all other fields. | | | | REQUIRED. | +------------------+--------+--------------------------------------+ Table 1 Haberkamp Expires 3 January 2027 [Page 10] Internet-Draft Intent Provenance Protocol July 2026 4.3. The Intent Scope Envelope The intent field encodes the human's goal as a Structured Intent Envelope consisting of four components. The natural_language field is human-readable but NOT machine-enforceable. Enforcement is performed against the structured fields only. +=====================+========+================================+ | Field | Type | Description | +=====================+========+================================+ | natural_language | String | Human-readable description of | | | | the intent. Informational | | | | only. REQUIRED. | +---------------------+--------+--------------------------------+ | domain | String | Dot-notation domain from the | | | | IPP Domain Taxonomy. | | | | REQUIRED. Example: | | | | financial.treasury | +---------------------+--------+--------------------------------+ | resource_scope | Array | Array of resource patterns | | | | defining which systems, | | | | accounts, or data types are in | | | | scope. Supports wildcard | | | | notation. REQUIRED. | +---------------------+--------+--------------------------------+ | quantitative_bounds | Object | Numerical and temporal | | | | constraints on authorized | | | | actions. Contents are domain- | | | | specific. OPTIONAL but | | | | RECOMMENDED. | +---------------------+--------+--------------------------------+ | prohibited_actions | Array | Explicit list of action types | | | | that are prohibited regardless | | | | of resource scope. OPTIONAL. | | | | Agents MUST NOT perform | | | | prohibited actions even if | | | | technically permissible. | +---------------------+--------+--------------------------------+ Table 2 IMPORTANT: The domain field value MUST be drawn from the IPP Domain Taxonomy maintained at https://ipp.khsovereign.com/taxonomy. Implementations using non-standard domain values MUST prefix them with "x." (for example, x.mycompany.custom_domain) to avoid collision with future taxonomy additions. Haberkamp Expires 3 January 2027 [Page 11] Internet-Draft Intent Provenance Protocol July 2026 4.4. Quantitative Bounds The quantitative_bounds object is domain-specific. This specification defines standard bound fields for the financial domain. Domain-specific extensions are published in the IPP Domain Taxonomy registry. Implementations SHOULD use standard field names where they exist. // Standard financial domain bounds "quantitative_bounds": { "min_balance_threshold": integer, // Min balance to trigger action "max_single_transaction": integer, // Max single transaction value "max_total_exposure": integer, // Max aggregate action value "currency": string, // ISO 4217 currency code "time_window": string, // Named window or ISO 8601 range "geographic_restriction": [string], // ISO 3166-1 alpha-2 codes "counterparty_allowlist": [string], // DID or entity identifiers "counterparty_blocklist": [string] // DID or entity identifiers } 5. The Genesis Seal 5.1. Purpose and Design The Genesis Seal is a cryptographic artifact embedded in every Intent Token that permanently and irrevocably links the token to this specification and to its author, Amanda Haberkamp. The Genesis Seal serves three simultaneous functions: * Protocol versioning: The spec_hash field uniquely identifies the exact version of the IPP specification under which the token was issued. * Authorship attribution: The author_did and genesis_sig fields constitute a permanent, cryptographically verifiable record that Amanda Haberkamp is the originator of this protocol. * Ecosystem integrity: Because the Genesis Seal is required in all tokens, any token that omits or falsifies it is detectable as non- compliant without reference to any external authority. The design is inspired by the genesis block pattern used in blockchain systems, where the initial block contains a timestamp and authorship record that is cryptographically chained to every subsequent block. In IPP, the Genesis Seal plays the analogous role: it is the permanent origin record embedded in every token the protocol ever produces. Haberkamp Expires 3 January 2027 [Page 12] Internet-Draft Intent Provenance Protocol July 2026 The genesis_sig is produced using the Founding Key, an Ed25519 private key generated by Amanda Haberkamp and used ONLY ONCE, during the Key Generation Ceremony described in Section 5.3. The private component of this key is stored in offline cold storage and is never used again. The public component is published in this specification and in the IPP specification repository. 5.2. Genesis Seal Structure "genesis": { "spec_hash": "sha3-256:[HASH OF IPP SPECIFICATION DOCUMENT]", "author_did": "did:key:z6MkHaberkampXXXXXXXXXXXXXXXXXXXXXXXX", "author_name": "Amanda Haberkamp", "org": "KH Sovereign", "founding_pubkey": "ed25519-pub:[BASE64URL PUBLIC KEY]", "genesis_sig": "ed25519:[BASE64URL SIGNATURE]" } Where genesis_sig = Ed25519Sign(private_key = FOUNDING_PRIVATE_KEY, message = SHA3-256(spec_hash + author_did + author_name + org + timestamp)). Verification of the Genesis Seal MUST proceed as follows: 1. Retrieve the IPP specification document from the canonical location: https://ipp.khsovereign.com/spec/v0.1 2. Compute SHA3-256 of the specification document and compare with spec_hash. If they do not match, the token was issued under a modified or forged specification. 3. Retrieve the founding public key from the specification repository at https://ipp.khsovereign.com/keys/ founding_public.pem 4. Verify the genesis_sig using the founding public key against the message defined above. If verification fails, the Genesis Seal is invalid. 5. If both checks pass, the token is certified as issued under the authentic IPP specification authored by Amanda Haberkamp. 5.3. Key Generation Ceremony The Founding Key pair was generated according to the following procedure, designed to maximize security and establish a clear, witnessed chain of custody: Haberkamp Expires 3 January 2027 [Page 13] Internet-Draft Intent Provenance Protocol July 2026 1. An air-gapped machine, never connected to any network, was used for all key generation operations. 2. The Ed25519 key pair was generated using OpenSSL 3.x. 3. A DID was generated from the public key using the did:key method [W3C-DID]. 4. The Genesis Seal payload was constructed and signed using the private key. 5. The private key was printed to paper (two copies), placed in fireproof storage, and deleted from all digital media. The air- gapped machine was permanently decommissioned. 6. The public key, DID, and Genesis Seal were committed to the IPP specification repository with a cryptographic timestamp from a trusted timestamping authority [RFC3161]. SECURITY NOTE: The Founding Private Key is used exactly once. If the Founding Private Key is ever compromised or disclosed, a Key Compromise event MUST be declared via a signed notice published at https://ipp.khsovereign.com/security, and a successor key ceremony MUST be conducted. All tokens issued before the compromise date remain verifiable against the legitimate key. 5.4. Authorship Attribution Requirements Any implementation, derivative protocol, or software product that uses, embeds, or interoperates with Intent Tokens MUST include the following attribution: Implements the Intent Provenance Protocol (IPP) v0.1, authored by Amanda Haberkamp, 2026. https://ipp.khsovereign.com Implementations that correctly embed the Genesis Seal in every token they produce satisfy this attribution requirement at the token level. Human-readable attribution in documentation, about pages, or license notices is additionally REQUIRED. 6. Cryptographic Mechanisms Haberkamp Expires 3 January 2027 [Page 14] Internet-Draft Intent Provenance Protocol July 2026 6.1. Signature Algorithm All signatures in this protocol MUST use Ed25519 as defined in [RFC8032]. Ed25519 is chosen for its combination of high security (128-bit security level), small key and signature sizes (32-byte keys, 64-byte signatures), fast verification, and resistance to side- channel attacks. Signature values are encoded as Base64URL without padding, prefixed with "ed25519:". Example: ed25519:47DEQpj8HBSa-_TImW- 5JCeuQeRkm5NMpJWZG3hSuFU The canonical serialization for signing MUST be produced by: (1) removing the token_signature field, (2) sorting all keys lexicographically at every nesting level, (3) serializing to JSON with no extraneous whitespace, and (4) encoding as UTF-8. This guarantees deterministic serialization across all conformant implementations. 6.2. Decentralized Identifiers (DIDs) All Principal and Agent identities MUST be expressed as DIDs conforming to the W3C DID Core specification. This specification recommends the did:key method for its self-sovereign properties. A did:key DID requires no external registry and is fully resolvable from the key material alone. Implementations MAY additionally support did:web, did:ion, or other conformant DID methods provided they satisfy the following requirements: (a) the DID is resolvable without requiring communication with the token issuer; (b) the resolved DID document contains a verificationMethod with the public key material; and (c) the DID is persistent and does not become unresolvable if a registry is decommissioned. 6.3. Hash Functions All hash operations in this specification use SHA3-256 [FIPS202]. SHA3-256 is chosen over SHA2-256 for its different internal structure, providing defense-in-depth against any future weaknesses discovered in SHA2-family functions. Hash values are represented as lowercase hexadecimal strings prefixed with "sha3-256:". 6.4. The Narrowing Invariant The Narrowing Invariant is the central enforcement mechanism of the delegation system. It states: for any Derived Token D with Parent Token P, the following MUST hold for every dimension of the token: Haberkamp Expires 3 January 2027 [Page 15] Internet-Draft Intent Provenance Protocol July 2026 D.expires_at <= P.expires_at D.delegation.depth < P.delegation.depth D.intent.domain is a sub-domain of P.intent.domain D.intent.resource_scope is a subset of P.intent.resource_scope D.intent.quantitative_bounds is a subset of P.intent.quant_bounds D.intent.prohibited_actions is a superset of P.intent.prohibited The narrowing_proof field in the delegation object of a Derived Token contains a signed assertion by the parent agent that the Derived Token satisfies this invariant. Any receiving agent MUST independently verify this assertion before accepting the Derived Token. Verification failure MUST result in token rejection. 7. Delegation and Derived Tokens 7.1. Derivation Rules When an agent derives a child token from a parent, it MUST: 1. Set parent_token_id to the token_id of the parent. 2. Reduce depth_remaining by exactly one. 3. Set the intent scope to a subset of the parent's scope, satisfying the Narrowing Invariant. 4. Set expires_at to be no later than the parent's expires_at. 5. Set the agent_id to a unique identifier for the spawned sub- agent. 6. Compute and embed a valid narrowing_proof. 7. Sign the new token with the parent agent's private key. 8. Link the genesis field identically to the parent. The Genesis Seal is never re-derived. It propagates unchanged. 7.2. Delegation Depth The depth_remaining field represents the number of additional sub- agent spawning levels authorized. An agent holding a token with depth_remaining = 0 MAY act under the token but MUST NOT issue Derived Tokens. Attempting to issue a Derived Token from a depth_remaining = 0 token is a protocol violation. Haberkamp Expires 3 January 2027 [Page 16] Internet-Draft Intent Provenance Protocol July 2026 The depth_original field records the delegation depth set by the original Principal and is preserved across all derived tokens. This allows auditors to determine how deep in the delegation chain any given token sits. 7.3. Sub-Agent Spawning An agent spawning a sub-agent MUST provide the Derived Token to the sub-agent as its authorization credential. The sub-agent MUST NOT accept instructions that are inconsistent with its token's intent scope, even if those instructions come from the spawning parent agent. The token is the authority, not the parent agent. CRITICAL SECURITY PROPERTY: An agent MUST refuse instructions from any source, including its parent agent, that would require it to act outside its token's authorized scope. This guarantees that a compromised parent agent cannot instruct a sub-agent to exceed the scope originally authorized by the human Principal. 8. Revocation 8.1. Revocation Registry The Revocation Registry is a distributed service that accepts token revocation notices from authorized principals and returns revocation status for token IDs. The registry endpoint is specified in the revocation field of every token. Revocation is keyed on token_id_hash, the SHA3-256 hash of the token_id, rather than the token_id itself, to prevent the registry from constructing a map of all active tokens in the ecosystem. This preserves privacy while maintaining revocability. 8.2. Polling Requirements Agents MUST poll the revocation registry at the interval specified by check_interval_ms before taking any action. The RECOMMENDED default interval is 5000 milliseconds. For high-stakes actions (financial transactions above defined thresholds, data deletion, external communications), agents SHOULD check revocation immediately before the action regardless of the polling interval. If the revocation registry is unreachable, agents MUST NOT proceed with actions unless the token contains an offline_grace_period_ms field and the offline duration is within that grace period. Agents MUST NOT cache a "not revoked" status beyond the polling interval. Haberkamp Expires 3 January 2027 [Page 17] Internet-Draft Intent Provenance Protocol July 2026 8.3. Mid-Chain Revocation Revocation of a parent token MUST propagate to all derived tokens. The registry MUST maintain the full ancestry tree of token derivation so that when a root or intermediate token is revoked, all descendant tokens are simultaneously marked as revoked. Agents that have cached a non-revoked status for a descendant token MUST invalidate that cache on the next polling cycle. 9. Provenance Chain 9.1. Append-Only Structure The provenance_chain is an append-only array. Agents MUST append a record to the chain before taking any action under the token. Records MUST NOT be modified or removed once appended. Each record is signed by the acting agent, creating a cryptographically linked sequence of accountability records. 9.2. Provenance Record Format { "record_id": "iprov:pr:uuid4", "token_id": "iprov:tok:parent-token-id", "agent_id": "iprov:agent:uuid4", "timestamp": "ISO8601_UTC", "action_type": "financial.treasury.transfer | data.read | ...", "action_summary": "Human-readable description of the action taken", "resource_id": "Identifier of the resource acted upon", "outcome": "success | failure | partial", "within_bounds": true, "agent_sig": "ed25519:BASE64URL" } The within_bounds field is a signed attestation by the agent that the action fell within the token's authorized scope. This does not replace independent verification. It provides a convenient audit field. Any action with within_bounds = false MUST have been blocked. An action that was not blocked but carries within_bounds = false indicates a protocol implementation error. 10. Interoperability Haberkamp Expires 3 January 2027 [Page 18] Internet-Draft Intent Provenance Protocol July 2026 10.1. Framework Integration The IPP SDK SHOULD provide integration adapters for the following AI orchestration frameworks at minimum: LangChain (Python and JavaScript), AutoGen (Microsoft), CrewAI, Microsoft Semantic Kernel, and Google Vertex AI Agent Builder. Additional framework adapters are RECOMMENDED and will be maintained in the IPP SDK repository. Integration MUST NOT require rewriting existing agent logic. The SDK MUST provide a wrapper pattern (for example, a decorator in Python, a higher-order function in JavaScript) that adds IPP governance to existing agents without modifying their internal structure. 10.2. Cross-Organization Trust When an agent from Organization A must interact with an agent from Organization B, the inter-organization trust handshake proceeds as follows: 1. Organization A's agent presents its Derived Token to Organization B's agent. 2. Organization B's agent verifies the Genesis Seal (Section 5), validates the token signature chain back to a Principal DID, verifies the token has not expired, and checks revocation status. 3. Organization B's agent verifies that the requested interaction falls within the scope defined in the presented token. 4. If all checks pass, Organization B's agent may respond and optionally issue its own Derived Token for any downstream actions on its side. 5. Both agents append provenance records to their respective tokens for the interaction. 10.3. Domain Taxonomy The IPP Domain Taxonomy is a hierarchical vocabulary of intent domains maintained at https://ipp.khsovereign.com/taxonomy. It is governed as an open standard with community contribution via pull request to the IPP specification repository. Amanda Haberkamp serves as the taxonomy steward and has final authority over additions to the standard namespace. Current top-level domains include: Haberkamp Expires 3 January 2027 [Page 19] Internet-Draft Intent Provenance Protocol July 2026 financial.* - Financial operations (treasury, payments, trading) healthcare.* - Healthcare data and clinical operations infrastructure.* - Cloud and system infrastructure operations analytics.* - Data analysis and reporting communications.* - Email, messaging, and external communications hr.* - Human resources and personnel operations legal.* - Legal document and compliance operations security.* - Security monitoring and response operations x.* - Private/experimental namespace (not standardized) 11. Security Considerations Implementers MUST be aware of the following security considerations: *Private Key Compromise.* If a Principal's private key is compromised, an attacker can issue Intent Tokens on behalf of that Principal. Revocation of all tokens issued under the compromised key MUST be performed immediately. Key compromise does not affect the Genesis Seal or the founding key. *Replay Attacks.* Intent Tokens are time-bounded by the expires_at field. Implementations MUST reject expired tokens. The token_id SHOULD be checked against a short-term cache of recently used token IDs to prevent replay of valid, non-expired tokens. *Scope Creep.* The Narrowing Invariant prevents scope expansion in derived tokens. However, implementations MUST verify the invariant independently. They MUST NOT trust the narrowing_proof field without cryptographic verification. *Registry Availability.* The Revocation Registry is a critical dependency. Implementations MUST design for registry unavailability and MUST fail safe (refuse to act) when the registry is unreachable and no offline grace period applies. *Genesis Seal Integrity.* The Genesis Seal binds every Intent Token to the specification under which it was issued. Implementations MUST reject tokens with a missing or malformed genesis field, and MUST NOT issue tokens with a genesis field that does not verify against the canonical founding public key. Implementations SHOULD cache the founding public key at first verification and treat any subsequent change as a security event requiring manual review. Haberkamp Expires 3 January 2027 [Page 20] Internet-Draft Intent Provenance Protocol July 2026 12. Privacy Considerations Intent Tokens contain sensitive information about organizational operations, including the natural_language description of intent and resource scope identifiers. Implementations MUST transmit tokens only over encrypted channels (TLS 1.3 minimum [RFC8446]). The provenance chain SHOULD be stored in access-controlled infrastructure with audit logging of all access events. The Revocation Registry uses token_id_hash rather than token_id to prevent the registry operator from building a map of active tokens. Implementations MUST NOT send the full token to the revocation registry, only the token_id_hash. 13. IANA Considerations This document requests registration of the URI scheme "iprov:" for use as the prefix for Intent Token identifiers (iprov:tok:*), Agent identifiers (iprov:agent:*), and Provenance Record identifiers (iprov:pr:*). This document also requests registration of the media type application/intent-token+json for serialized Intent Token payloads. 14. References 14.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, January 2017, . [RFC3161] Adams, C., "Internet X.509 Public Key Infrastructure Time- Stamp Protocol (TSP)", RFC 3161, August 2001, . [W3C-DID] Sporny, M., "Decentralized Identifiers (DIDs) v1.0", July 2022, . Haberkamp Expires 3 January 2027 [Page 21] Internet-Draft Intent Provenance Protocol July 2026 [FIPS202] NIST, "SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions", August 2015, . 14.2. Informative References [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018, . Author's Address Amanda Haberkamp Chicago, Illinois United States Email: amanda@khsovereign.com URI: https://ipp.khsovereign.com Haberkamp Expires 3 January 2027 [Page 22]