Internet-Draft	AIP	March 2026
Prakash	Expires 28 September 2026	[Page]
Abstract

This document specifies the Agent Identity Protocol (AIP), a protocol\n for verifiable, delegable identity for AI agent systems. AIP introduces\n Invocation-Bound Capability Tokens (IBCTs) that bind identity,\n authorization, scope constraints, and provenance into a single\n cryptographic artifact. Two token modes are defined: a compact mode\n using JSON Web Tokens (JWT) with Ed25519 signatures for single-hop\n interactions, and a chained mode using Biscuit tokens with append-only\n blocks and Datalog policy evaluation for multi-hop delegation chains.\n Protocol bindings are specified for the Model Context Protocol (MCP),\n Agent-to-Agent Protocol (A2A), and generic HTTP APIs. The protocol\n addresses authentication gaps in current AI agent infrastructure where\n a survey of approximately 2,000 MCP servers found all lacked\n authentication.¶
\n \n
\n Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript.\n Please enable Javascript for full functionality.\n
\n \n \n \n \n\n\n\n
\n Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems\n
\n draft-prakash-aip-01\n

\n \n Status\n \n
\n \n Email expansions\n \n
\n \n History\n \n
\n\n \n\n\n\n Versions:\n \n\n \n\n\n\n\n
\n This document is an Internet-Draft (I-D).\n Anyone may submit an I-D to the IETF.\n This I-D is not endorsed by the IETF and has no formal standing in the\n IETF standards process.\n
\n\n\n
\n \n \n \n \n \n\n\n\n\n\n\n\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n
Document	Type		\n \n\n\n\n\n\n\n\n Active Internet-Draft\n (individual)\n \n\n \n \n \n
	Author	\n \n	\n \n \n Sunil Prakash \n \n \n \n
	Last updated		\n 2026-08-19\n \n
	\n RFC stream\n	\n \n	\n \n (None)\n \n
	\n Intended RFC status\n	\n \n	\n \n \n (None)\n \n \n
	\n Formats\n	\n	\n \n \n \n \n \n \n \n txt\n \n \n \n \n \n \n \n html\n \n \n \n \n \n \n \n xml\n \n \n \n \n \n \n \n htmlized\n \n \n \n \n \n \n \n bibtex\n \n \n \n \n \n \n \n bibxml\n \n \n \n \n \n\n \n
\n Stream\n	\n Stream state\n	\n	\n (No stream defined)\n
	\n Consensus boilerplate\n	\n \n	\n \n Unknown\n \n
	\n RFC Editor Note\n	\n \n	\n \n \n (None)\n \n \n
\n IESG\n	\n \n IESG state\n \n	\n \n	\n \n \n I-D Exists\n \n \n
	\n Telechat date\n	\n \n	\n \n \n (None)\n \n \n \n
	\n Responsible AD\n	\n \n	\n \n \n (None)\n \n \n
	\n Send notices to\n	\n \n	\n \n \n (None)\n \n \n
\n \n \n Email authors\n \n \n \n \n IPR\n \n \n \n \n References\n \n \n \n Referenced by\n \n \n \n Nits\n \n \n \n Nits v3\n \n \n \n Search email archive\n \n \n \n \n \n
\n \n
\n \n draft-prakash-aip-01\n \n
Individual Submission                                         S. Prakash\nInternet-Draft                                               Independent\nIntended status: Informational                            19 August 2026\nExpires: 20 February 2027\n\n   Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent\n                                Systems\n                          draft-prakash-aip-01\n\nAbstract\n\n   This document specifies the Agent Identity Protocol (AIP), a protocol\n   for verifiable, delegable identity for AI agent systems.  AIP\n   introduces Invocation-Bound Capability Tokens (IBCTs) that bind\n   identity, authorization, scope constraints, and provenance into a\n   single cryptographic artifact.  Two token modes are defined: a\n   compact mode using JSON Web Tokens (JWT) with Ed25519 signatures for\n   single-hop interactions, and a chained mode using Biscuit tokens with\n   append-only blocks and Datalog policy evaluation for multi-hop\n   delegation chains.  Protocol bindings are specified for the Model\n   Context Protocol (MCP), Agent-to-Agent Protocol (A2A), and generic\n   HTTP APIs.  The protocol addresses authentication gaps in current AI\n   agent infrastructure where a survey of approximately 2,000 MCP\n   servers found all lacked authentication.  This revision specifies a\n   normative verification algorithm, defines the canonical policy\n   encoding for chained mode, describes how AIP composes with workload\n   identity systems such as SPIFFE, and maps AIP against the cross-\n   organization delegation requirements enumerated in\n   [I-D.reece-wimse-cross-org-delegation].\n\nStatus of This Memo\n\n   This Internet-Draft is submitted in full conformance with the\n   provisions of BCP 78 and BCP 79.\n\n   Internet-Drafts are working documents of the Internet Engineering\n   Task Force (IETF).  Note that other groups may also distribute\n   working documents as Internet-Drafts.  The list of current Internet-\n   Drafts is at https://datatracker.ietf.org/drafts/current/.\n\n   Internet-Drafts are draft documents valid for a maximum of six months\n   and may be updated, replaced, or obsoleted by other documents at any\n   time.  It is inappropriate to use Internet-Drafts as reference\n   material or to cite them other than as "work in progress."\n\n   This Internet-Draft will expire on 20 February 2027.\n\nPrakash                 Expires 20 February 2027                [Page 1]\nInternet-Draft                     AIP                       August 2026\n\nCopyright Notice\n\n   Copyright (c) 2026 IETF Trust and the persons identified as the\n   document authors.  All rights reserved.\n\n   This document is subject to BCP 78 and the IETF Trust's Legal\n   Provisions Relating to IETF Documents (https://trustee.ietf.org/\n   license-info) in effect on the date of publication of this document.\n   Please review these documents carefully, as they describe your rights\n   and restrictions with respect to this document.\n\nTable of Contents\n\n   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3\n     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   4\n   2.  Identity Scheme . . . . . . . . . . . . . . . . . . . . . . .   4\n     2.1.  DNS-Based Identifiers . . . . . . . . . . . . . . . . . .   4\n     2.2.  Self-Certifying Identifiers . . . . . . . . . . . . . . .   4\n     2.3.  Identity Document . . . . . . . . . . . . . . . . . . . .   4\n   3.  Token Formats . . . . . . . . . . . . . . . . . . . . . . . .   5\n     3.1.  Compact Mode (JWT)  . . . . . . . . . . . . . . . . . . .   5\n     3.2.  Chained Mode (Biscuit)  . . . . . . . . . . . . . . . . .   6\n     3.3.  Scope Attenuation . . . . . . . . . . . . . . . . . . . .   6\n     3.4.  Policy Profiles . . . . . . . . . . . . . . . . . . . . .   6\n       3.4.1.  Canonical Block Encoding  . . . . . . . . . . . . . .   7\n     3.5.  Budget Semantics  . . . . . . . . . . . . . . . . . . . .   8\n   4.  Verification Algorithm  . . . . . . . . . . . . . . . . . . .   8\n     4.1.  Step V1: Chain Integrity  . . . . . . . . . . . . . . . .   9\n     4.2.  Step V2: Root Binding . . . . . . . . . . . . . . . . . .   9\n     4.3.  Step V3: Depth  . . . . . . . . . . . . . . . . . . . . .   9\n     4.4.  Step V4: Structural Attenuation Walk  . . . . . . . . . .   9\n     4.5.  Step V5: Delegation Context . . . . . . . . . . . . . . .  10\n     4.6.  Step V6: Policy Evaluation  . . . . . . . . . . . . . . .  10\n     4.7.  Step V7: Revocation with Bounded Staleness  . . . . . . .  11\n     4.8.  Verification Result . . . . . . . . . . . . . . . . . . .  11\n   5.  Trust Anchors and Workload Identity . . . . . . . . . . . . .  11\n     5.1.  Anchor Modes  . . . . . . . . . . . . . . . . . . . . . .  12\n     5.2.  Relationship to Token Exchange  . . . . . . . . . . . . .  12\n     5.3.  Proof of Possession . . . . . . . . . . . . . . . . . . .  13\n   6.  Protocol Bindings . . . . . . . . . . . . . . . . . . . . . .  13\n     6.1.  MCP Binding . . . . . . . . . . . . . . . . . . . . . . .  13\n     6.2.  A2A Binding . . . . . . . . . . . . . . . . . . . . . . .  14\n     6.3.  HTTP Binding  . . . . . . . . . . . . . . . . . . . . . .  14\n   7.  Delegation Lifecycle  . . . . . . . . . . . . . . . . . . . .  14\n     7.1.  Bounded Depth . . . . . . . . . . . . . . . . . . . . . .  14\n     7.2.  Delegation Context  . . . . . . . . . . . . . . . . . . .  14\n     7.3.  Ephemeral Agent Grants  . . . . . . . . . . . . . . . . .  14\n     7.4.  Key Rotation  . . . . . . . . . . . . . . . . . . . . . .  15\n\nPrakash                 Expires 20 February 2027                [Page 2]\nInternet-Draft                     AIP                       August 2026\n\n     7.5.  Revocation  . . . . . . . . . . . . . . . . . . . . . . .  15\n   8.  Provenance and Audit  . . . . . . . . . . . . . . . . . . . .  15\n     8.1.  Completion Blocks . . . . . . . . . . . . . . . . . . . .  15\n     8.2.  Verification Trust Levels . . . . . . . . . . . . . . . .  15\n     8.3.  Audit Tokens  . . . . . . . . . . . . . . . . . . . . . .  16\n   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  16\n     9.1.  Threat Model  . . . . . . . . . . . . . . . . . . . . . .  16\n     9.2.  Adversarial Evaluation  . . . . . . . . . . . . . . . . .  17\n     9.3.  Cryptographic Agility . . . . . . . . . . . . . . . . . .  17\n     9.4.  Transport Security  . . . . . . . . . . . . . . . . . . .  17\n   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17\n     10.1.  HTTP Authentication Scheme . . . . . . . . . . . . . . .  18\n     10.2.  Well-Known URI . . . . . . . . . . . . . . . . . . . . .  18\n     10.3.  Media Type . . . . . . . . . . . . . . . . . . . . . . .  18\n   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  18\n     11.1.  Normative References . . . . . . . . . . . . . . . . . .  18\n     11.2.  Informative References . . . . . . . . . . . . . . . . .  19\n   Appendix A.  Cross-Organization Delegation Requirements\n           Mapping . . . . . . . . . . . . . . . . . . . . . . . . .  20\n   Appendix B.  Changes from draft-prakash-aip-00  . . . . . . . . .  21\n   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  22\n   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  22\n\n1.  Introduction\n\n   AI agent systems are increasingly deployed in multi-agent\n   architectures where an orchestrator decomposes tasks and delegates\n   subtasks to specialist agents.  The protocols enabling this\n   communication, notably the Model Context Protocol (MCP) and the\n   Agent-to-Agent Protocol (A2A), solve the connectivity problem but do\n   not solve the identity problem.\n\n   MCP provides no built-in authentication layer.  A2A uses self-\n   declared identities with no attestation mechanism.  OAuth 2.1,\n   recently added to MCP, covers single-hop client-to-server\n   authentication but does not address multi-hop delegation chains.\n   When an orchestrator delegates to a specialist that calls a tool, the\n   delegation chain that led to the tool invocation is lost.\n\n   AIP fills this gap by introducing Invocation-Bound Capability Tokens\n   (IBCTs) that answer four questions for every agent action: who\n   authorized this action, through which delegation chain, with what\n   constraints at each hop, and what was the outcome.\n\nPrakash                 Expires 20 February 2027                [Page 3]\nInternet-Draft                     AIP                       August 2026\n\n1.1.  Requirements Language\n\n   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",\n   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and\n   "OPTIONAL" in this document are to be interpreted as described in BCP\n   14 [RFC2119] [RFC8174] when, and only when, they appear in all\n   capitals, as shown here.\n\n2.  Identity Scheme\n\n   AIP defines two identifier schemes for agent identity:\n\n2.1.  DNS-Based Identifiers\n\n   DNS-based identifiers follow the format:\n\n   aip:web:<domain>/<path>\n\n   Example: aip:web:example.com/agents/research-analyst\n\n   DNS-based identifiers are suitable for long-lived agents with stable\n   domain ownership.  Identity documents are resolved via HTTPS at a\n   well-known path.\n\n2.2.  Self-Certifying Identifiers\n\n   aip:key:ed25519:<multibase-encoded-public-key>\n\n   Self-certifying identifiers derive identity from the public key\n   itself.  They are suitable for ephemeral agents that do not require\n   DNS infrastructure.  The identifier is deterministically computed\n   from the Ed25519 public key using multibase encoding.\n\n2.3.  Identity Document\n\n   Each agent with a DNS-based identifier MUST publish an identity\n   document at:\n\n   https://<domain>/.well-known/aip/<path>.json\n\n   The identity document is a JSON object containing:\n\n   *  aip: Protocol version (MUST be "1.0")\n\n   *  id: The agent's AIP identifier\n\n   *  public_keys: Array of public key objects with validity windows\n\nPrakash                 Expires 20 February 2027                [Page 4]\nInternet-Draft                     AIP                       August 2026\n\n   *  name: Human-readable agent name\n\n   *  delegation: Delegation preferences\n\n   *  protocols: Supported protocol bindings\n\n   *  document_signature: Ed25519 signature over the canonicalized\n      document\n\n   *  expires: Document expiration timestamp\n\n   The document MUST be self-signed.  Verification uses JSON\n   Canonicalization Scheme (JCS) [RFC8785]: remove the\n   document_signature field, canonicalize the remaining JSON, and verify\n   the Ed25519 signature against a currently-valid public key.\n\n3.  Token Formats\n\n   AIP defines two token modes that share a common identity scheme but\n   differ in delegation capability.\n\n3.1.  Compact Mode (JWT)\n\n   Compact mode tokens are JSON Web Tokens [RFC7519] signed with Ed25519\n   (EdDSA).  They support single-hop interactions only.\n\n   Header:\n\n   {"alg": "EdDSA", "typ": "aip+jwt"}\n\n   Claims:\n\n   *  iss: Issuer AIP identifier (REQUIRED)\n\n   *  sub: Subject/holder AIP identifier (REQUIRED)\n\n   *  scope: Array of authorized capabilities (REQUIRED)\n\n   *  budget_usd: Authorization budget ceiling in USD (REQUIRED)\n\n   *  max_depth: Maximum delegation depth, 0 for no further delegation\n      (REQUIRED)\n\n   *  iat: Issued-at timestamp (REQUIRED)\n\n   *  exp: Expiration timestamp (REQUIRED)\n\nPrakash                 Expires 20 February 2027                [Page 5]\nInternet-Draft                     AIP                       August 2026\n\n   Token lifetime SHOULD be less than one hour.  Both iss and sub MUST\n   be valid AIP identifiers.\n\n3.2.  Chained Mode (Biscuit)\n\n   Chained mode tokens use Biscuit [BISCUIT] tokens with append-only\n   blocks and Datalog policy evaluation.  They support multi-hop\n   delegation with cryptographic scope attenuation.\n\n   A chained token consists of ordered blocks:\n\n   *  Block 0 (Authority): Root identity, initial capabilities, budget,\n      max_depth, expiration.  Signed by the root authority.\n\n   *  Blocks 1..N-1 (Delegation): Each block narrows scope.  Contains\n      delegator, delegate, attenuated capabilities (as Biscuit right\n      facts), attenuated budget, and a non-empty context field.  Signed\n      by the delegator.\n\n   *  Block N (Completion, optional): Execution outcome.  Contains\n      status, result_hash (SHA-256), verification_status, and optional\n      resource usage metrics.  Signed by the executing agent.\n\n3.3.  Scope Attenuation\n\n   Scope attenuation is a fundamental security property of AIP.  At each\n   delegation step, scope can only narrow or remain equal, never widen.\n   This applies across four dimensions:\n\n   *  Tools: Child scope MUST be a subset of parent scope\n\n   *  Budget: Child budget MUST be less than or equal to parent budget\n\n   *  Domains: Child domains MUST be a subset of parent domains\n\n   *  Time: Child expiration MUST be less than or equal to parent\n      expiration\n\n   Verifiers MUST check attenuation at every hop in the delegation\n   chain.  A wildcard (*) in the parent permits any specific value in\n   the child, but a specific value in the parent MUST NOT widen to a\n   wildcard in the child.\n\n3.4.  Policy Profiles\n\n   Chained mode tokens support three policy profiles of increasing\n   expressiveness:\n\nPrakash                 Expires 20 February 2027                [Page 6]\nInternet-Draft                     AIP                       August 2026\n\n   *  Simple: Templated rules requiring no Datalog knowledge.  The\n      library generates canonical Datalog for tool allowlists, budget\n      ceilings, delegation depth, and time expiry.\n\n   *  Standard: Curated Datalog subset without recursion and with\n      bounded evaluation.\n\n   *  Advanced: Full Datalog with a maximum 1000 iteration limit.  Opt-\n      in only.\n\n3.4.1.  Canonical Block Encoding\n\n   Interoperability of chained mode depends on every implementation\n   emitting the same Datalog for the same authorization intent.  Two\n   encodings that are individually defensible will not verify against\n   each other.  Implementations of the Simple profile MUST emit exactly\n   the forms below.\n\n   The authority block (block 0) MUST contain:\n\n   identity("<aip-identifier>");\n   principal("<identifier>");          ; OPTIONAL, on-behalf-of party\n   right("<scope>");                   ; one fact per granted scope\n   max_depth(<n>);\n   budget_ceiling(<cents>);            ; OPTIONAL, integer cents\n   check if tool($t), ["<scope>", ...].contains($t);\n   check if time($t), $t <= <expiry>;\n\n   Each delegation block (blocks 1 through N) MUST contain:\n\n   delegator("<aip-identifier>");\n   delegate("<aip-identifier>");\n   context("<non-empty string>");\n   budget_ceiling(<cents>);            ; OPTIONAL, integer cents\n   check if tool($t), ["<scope>", ...].contains($t);\n   check if time($t), $t <= <expiry>;  ; OPTIONAL, <= parent expiry\n\n   Scope narrowing follows from conjunction: because every block\n   contributes a check if tool($t) constraint and all checks in all\n   blocks MUST pass, the set of authorized tools is the intersection of\n   the per-block allowlists.  A delegation block cannot widen scope,\n   because naming a tool absent from an ancestor's allowlist produces an\n   empty intersection and authorizes nothing.\n\n   Budget is carried as a fact rather than a check.  A Datalog check of\n   the form check if budget($b), $b <= N binds to whatever budget facts\n   are in scope during evaluation, which is not the same question as\n   whether this block's ceiling narrows its parent's.  Encoding budget\n\nPrakash                 Expires 20 February 2027                [Page 7]\nInternet-Draft                     AIP                       August 2026\n\n   as a check therefore either rejects valid chains or, if the verifier\n   supplies a satisfying ambient fact, passes unconditionally.  Budget\n   attenuation is verified structurally instead, in step V4 of\n   Section 4.\n\n   Implementations MUST NOT emit a check statement over budget, and\n   verifiers MUST NOT inject an ambient budget fact during policy\n   evaluation.\n\n3.5.  Budget Semantics\n\n   Budget values in AIP tokens represent per-token authorization\n   ceilings, NOT running balances.  A delegator asserts "I authorize up\n   to $X for this task" at delegation time.\n\n   A budget ceiling is both declared and verified, and the two are\n   distinct operations:\n\n   *  Declared as a budget_ceiling fact in the block that establishes\n      it, in integer cents.\n\n   *  Verified structurally at every hop: a verifier MUST confirm that\n      each block's declared ceiling is non-negative and does not exceed\n      the nearest ancestor block that declares one.  A block that\n      declares no ceiling inherits its nearest ancestor's.  This check\n      is specified in step V4 of Section 4.\n\n   What the token does NOT do is track cumulative spending.  Nothing in\n   a delegation chain records how much of a ceiling has been consumed,\n   and a verifier evaluating a single request cannot know.  Enforcement\n   of actual spend against a ceiling is out of band, and is the\n   responsibility of the orchestration platform at dispatch time.\n   Completion blocks record actual cost_usd for audit purposes, which\n   supports after-the-fact reconciliation but is not an authorization\n   control.\n\n   Implementations MUST NOT present ceiling verification as spend\n   enforcement.  A chain that verifies establishes that no hop\n   authorized more than it held.  It does not establish that the\n   authorized amount remains available.\n\n4.  Verification Algorithm\n\n   This section is normative.  A verifier presented with an AIP token\n   MUST perform steps V1 through V7 in the order given before treating\n   any identity or capability asserted by the token as established.  The\n   ordering matters: no step that reads block content is permitted\n   before chain integrity is established in V1.\n\nPrakash                 Expires 20 February 2027                [Page 8]\nInternet-Draft                     AIP                       August 2026\n\n4.1.  Step V1: Chain Integrity\n\n   The verifier MUST deserialize the token from its wire form and verify\n   the signature on every block against the root public key.  In chained\n   mode this means verifying the full signature chain from block 0\n   through block N, not the signature on the presented leaf alone.\n\n   Verification MUST be performed against the serialized form as\n   received.  An implementation that holds a token in a parsed in-memory\n   representation MUST re-serialize and re-verify before relying on it,\n   rather than trusting the state of its own parsed object.\n\n   A verifier MUST NOT accept any fact, check, or claim from a block\n   that it has not verified as part of a chain rooted at the issuer's\n   key.  Failure returns aip_signature_invalid.\n\n4.2.  Step V2: Root Binding\n\n   The verifier MUST extract the issuer from the identity fact in block\n   0 and confirm that the root public key used in V1 is the key bound to\n   that identifier:\n\n   *  For aip:web: identifiers, by resolving the identity document as\n      specified in Section 2.3 and comparing the published key.\n\n   *  For aip:key: identifiers, by decoding the key from the identifier\n      itself and comparing.\n\n   An identifier that does not resolve, or that resolves to a different\n   key, returns aip_identity_unresolvable.  A verifier MUST NOT infer\n   the root key from the token.\n\n4.3.  Step V3: Depth\n\n   The verifier MUST confirm that the number of delegation blocks does\n   not exceed the max_depth declared in block 0.  Failure returns\n   aip_depth_exceeded.\n\n4.4.  Step V4: Structural Attenuation Walk\n\n   The verifier MUST walk the chain from block 1 to block N and confirm,\n   for each block i, that every capability dimension is narrower than or\n   equal to the corresponding dimension in block i-1:\n\n   *  Scope: the allowlist in block i MUST be a subset of the allowlist\n      in block i-1.  Failure returns aip_scope_insufficient.\n\nPrakash                 Expires 20 February 2027                [Page 9]\nInternet-Draft                     AIP                       August 2026\n\n   *  Budget: a budget_ceiling declared in block i MUST be non-negative\n      and MUST NOT exceed the ceiling declared by the nearest ancestor\n      that declares one.  Failure returns aip_budget_exceeded.\n\n   *  Time: an expiry declared in block i MUST NOT be later than the\n      expiry declared by the nearest ancestor that declares one, and no\n      block's expiry may be in the past.  Failure returns\n      aip_token_expired.\n\n   *  Domains: the domain set in block i MUST be a subset of the domain\n      set in block i-1.  Failure returns aip_scope_insufficient.\n\n   *  Principal: if block 0 declares a principal, no subsequent block\n      may declare a different one.  The on-behalf-of principal is\n      invariant along a chain: intermediaries narrow authority, they do\n      not substitute the party on whose behalf the chain acts.  Failure\n      returns aip_token_malformed.\n\n   A dimension absent from block i inherits the value of its nearest\n   ancestor.  A wildcard in an ancestor permits any specific value in a\n   descendant.  A specific value in an ancestor MUST NOT widen to a\n   wildcard in a descendant.\n\n   This step is REQUIRED and is not satisfied by the container format.\n   A verifier MUST NOT rely on the semantics of an append-only token\n   container to establish attenuation.  Container-level signature\n   chaining establishes that blocks were appended in order by successive\n   keyholders, which is a different property: it prevents a block from\n   being substituted, reordered, or forged, but it does not establish\n   that the capabilities asserted in block i are a subset of those held\n   by block i-1.  Attenuation is a property of the capability content\n   and MUST be checked as such, in addition to V1.\n\n4.5.  Step V5: Delegation Context\n\n   Every delegation block MUST carry a non-empty context fact.  A\n   verifier MUST reject a chain in which any delegation block omits it\n   or supplies an empty value, returning aip_token_malformed.\n\n4.6.  Step V6: Policy Evaluation\n\n   The verifier MUST evaluate the token's policies with the ambient\n   facts tool, time, and depth bound to the request under consideration,\n   and MUST require that every check in every block passes.\n\nPrakash                 Expires 20 February 2027               [Page 10]\nInternet-Draft                     AIP                       August 2026\n\n   The verifier MUST NOT introduce ambient facts beyond those named\n   above.  In particular it MUST NOT supply a budget fact: supplying one\n   causes any budget check in the chain to evaluate against verifier-\n   chosen data rather than against the token, which makes the check\n   meaningless.  Budget is handled in V4.\n\n   Failure returns aip_scope_insufficient.\n\n4.7.  Step V7: Revocation with Bounded Staleness\n\n   If the issuer's identity document advertises a revocation endpoint,\n   the verifier MUST check whether any key in the chain has been\n   revoked.  Revocation data MAY be cached.  A verifier MUST be\n   configurable with a maximum acceptable staleness for cached\n   revocation data, and MUST fail closed when its cached data is older\n   than that bound, returning aip_key_revoked rather than proceeding on\n   stale information.\n\n   Revocation responses MUST be signed by the issuer so that their\n   authenticity is verifiable without a trusted transport to the\n   revocation endpoint.\n\n4.8.  Verification Result\n\n   A token that passes V1 through V7 establishes: the identity of the\n   issuer, the identity of each delegator and delegate in the chain, the\n   capabilities available at the leaf, and that no hop in the chain\n   exceeded the authority of its predecessor.  It does not establish\n   that the presenting party is the party the leaf was issued to.  See\n   Section 5.3.\n\n5.  Trust Anchors and Workload Identity\n\n   AIP answers a different question from a workload identity system, and\n   the two compose rather than compete.\n\n   A workload identity system such as SPIFFE [SPIFFE], in the\n   architecture described by [I-D.ietf-wimse-arch], answers "which\n   workload is this?"  It attests a running process against the platform\n   it runs on and issues a credential that says so.  Its trust boundary\n   is the trust domain it administers, and it does not model authority\n   passing between parties.\n\n   AIP answers "on whose authority is this being done, how far back, and\n   can a party with no relationship to the origin verify it?"  It\n   carries delegation across hops and organizations, and it says nothing\n   about whether the process presenting the token is the one the\n   platform attested.\n\nPrakash                 Expires 20 February 2027               [Page 11]\nInternet-Draft                     AIP                       August 2026\n\n5.1.  Anchor Modes\n\n   Block 0 of a chain is signed by the issuer's key.  Three ways of\n   establishing trust in that key are defined:\n\n   *  DNS-anchored: the issuer is an aip:web: identifier and the key is\n      published in an identity document resolved over HTTPS.  Trust\n      derives from the Web PKI and DNS control.\n\n   *  Self-certifying: the issuer is an aip:key: identifier and the key\n      is the identifier.  Trust derives from whoever accepted the\n      identifier.\n\n   *  Workload-attested: the issuer's key is bound to a workload\n      identity credential issued by an external authority, and the\n      identity document records that binding.  Trust derives from that\n      authority's attestation.\n\n   In workload-attested mode, an identity document MAY carry a\n   workload_identity member naming the credential that attests the\n   issuer key, for example a SPIFFE ID.  A verifier that recognises the\n   naming authority MAY treat that attestation as the basis for\n   accepting the root key, in place of resolving the document over\n   HTTPS.  A verifier that does not recognise it MUST fall back to the\n   DNS-anchored or self-certifying path, and MUST NOT treat an\n   unrecognised attestation as an endorsement.\n\n   This is the deployment shape most likely in practice: a workload\n   identity system establishes that the orchestrator is what it claims\n   to be inside its own trust domain, and AIP carries what that\n   orchestrator was permitted to delegate onward, across boundaries the\n   workload identity system does not span.\n\n5.2.  Relationship to Token Exchange\n\n   A common deployment pattern carries delegation by repeated token\n   exchange [RFC8693], in which each hop presents its credential to an\n   authorization server and receives a narrowed token carrying an act\n   claim naming the acting party.\n\n   The mechanisms differ in where verification happens.  Token exchange\n   places an authorization server on the path at each hop, and the\n   relying party's assurance derives from trusting that server.  An AIP\n   chain is verified by the relying party directly from the token and\n   the issuer's published key, with no synchronous call to the\n   originating organization.  The two are not exclusive: an exchanged\n   token may serve as the credential that anchors block 0.\n\nPrakash                 Expires 20 February 2027               [Page 12]\nInternet-Draft                     AIP                       August 2026\n\n5.3.  Proof of Possession\n\n   An AIP token as specified in this document is a bearer credential.\n   Verification establishes what authority the chain conveys and that no\n   hop exceeded its predecessor.  It does not establish that the party\n   presenting the token is the party the leaf was delegated to.  A\n   captured or relayed token is usable by whoever holds it, within the\n   scope, time, and budget the chain permits.\n\n   Deployments requiring proof of possession MUST bind the token to a\n   key at the transport or message layer.  Mutual TLS, HTTP message\n   signatures, and workload proof tokens [I-D.ietf-wimse-wpt] are all\n   suitable.  Specifying that binding is out of scope for this document,\n   and is deliberately left to mechanisms already being standardized\n   rather than duplicated here.\n\n   Implementations MUST NOT describe AIP verification as authenticating\n   the presenter.\n\n6.  Protocol Bindings\n\n6.1.  MCP Binding\n\n   AIP tokens are transported in MCP via the X-AIP-Token HTTP header:\n\n   X-AIP-Token: <compact-or-chained-token>\n\n   For tokens exceeding 4KB, token-by-reference is supported:\n\n   X-AIP-Token-Ref: https://issuer/.well-known/aip/tokens/<id>\n\n   An MCP server extracts the token from the header, or fetches it from\n   the reference URL, and then verifies it according to Section 4.  On\n   success it injects the verified identity into the request context,\n   where the tool implementation MAY use it for authorization decisions,\n   logging, or audit.  The verification steps are not restated here; the\n   algorithm is binding-independent, and an MCP server that verifies\n   tokens differently from an A2A agent is a source of exactly the\n   divergence this document exists to prevent.\n\n   Nine error codes are defined with appropriate HTTP status mappings:\n   401 for authentication failures (token_missing, token_malformed,\n   signature_invalid, identity_unresolvable, token_expired, key_revoked)\n   and 403 for authorization failures (scope_insufficient,\n   budget_exceeded, depth_exceeded).\n\n   Servers declare AIP requirements via the require_aip field in their\n   identity document's protocols.mcp configuration.\n\nPrakash                 Expires 20 February 2027               [Page 13]\nInternet-Draft                     AIP                       August 2026\n\n6.2.  A2A Binding\n\n   In A2A interactions, AIP tokens are transported in the\n   metadata.aip_token field of task submissions.  Agent cards are\n   extended with an aip_identity object containing the agent's AIP\n   identifier and document URL.\n\n   The A2A verification flow adds a sixth step: the calling agent\n   appends a delegation block with attenuated scope before sending the\n   task, and the receiving agent verifies that the final delegation\n   block delegates to its own AIP identifier.\n\n6.3.  HTTP Binding\n\n   For generic HTTP APIs not using MCP or A2A, tokens are transported\n   via the Authorization header with the AIP scheme:\n\n   Authorization: AIP <base64url-encoded-token>\n\n   Token-by-reference uses the X-AIP-Token-Ref header with a 5-second\n   fetch timeout and SSRF protection (reject reference URLs outside\n   expected domain patterns).\n\n7.  Delegation Lifecycle\n\n7.1.  Bounded Depth\n\n   Block 0 declares max_depth (default: 3).  Each delegation block\n   increments effective depth by 1.  If current depth equals max_depth,\n   further delegation is forbidden.  In compact mode, max_depth of 0\n   means the holder MUST NOT delegate further.\n\n7.2.  Delegation Context\n\n   Each delegation block MUST include a non-empty context field\n   containing a human-readable description of the delegation purpose.\n   Verifiers MUST reject tokens with missing or empty context.  This\n   requirement ensures audit trail integrity.\n\n7.3.  Ephemeral Agent Grants\n\n   For short-lived sub-agents, a parent agent generates an Ed25519\n   keypair, creates an aip:key: identifier, and appends a delegation\n   block with scoped capabilities and a short TTL (5 minutes\n   RECOMMENDED).  The parent's identity document MAY set\n   delegation.allow_ephemeral_grants to false to prevent this.\n\nPrakash                 Expires 20 February 2027               [Page 14]\nInternet-Draft                     AIP                       August 2026\n\n7.4.  Key Rotation\n\n   DNS-based identifiers support zero-downtime key rotation through\n   overlapping validity windows on public keys.  A new key is published\n   with a future valid_from timestamp.  Both keys are valid during the\n   overlap period.  Recommended rotation period is 90 days.  Cache TTL\n   MUST NOT exceed 5 minutes.\n\n   Self-certifying identifiers cannot rotate keys; key rotation requires\n   identity replacement, which is acceptable for ephemeral agents.\n\n7.5.  Revocation\n\n   AIP prefers short-lived tokens over revocation infrastructure.\n   Compact mode tokens SHOULD have a TTL under 1 hour, making revocation\n   generally unnecessary.  For chained mode, key revocation (removing a\n   key from the identity document) invalidates all tokens signed by that\n   key.  Token-specific revocation via Certificate Revocation Lists is\n   deferred to v2.\n\n8.  Provenance and Audit\n\n8.1.  Completion Blocks\n\n   A completion block is the final block in a chained token, signed by\n   the executing agent.  It contains:\n\n   *  status: REQUIRED.  One of "completed", "failed", or "partial".\n\n   *  result_hash: REQUIRED.  SHA-256 hash of the output in format\n      "sha256:<hex>".\n\n   *  verification_status: REQUIRED.  One of "self_reported",\n      "tool_verified", "peer_verified", or "human_verified".\n\n   *  tokens_used: OPTIONAL.  LLM tokens consumed.\n\n   *  cost_usd: OPTIONAL.  Actual cost incurred.\n\n   *  duration_ms: OPTIONAL.  Wall-clock execution time.\n\n   *  ldp_provenance_id: OPTIONAL.  Back-link to LDP provenance record.\n\n8.2.  Verification Trust Levels\n\n   AIP defines three escalating trust levels for completion data:\n\nPrakash                 Expires 20 February 2027               [Page 15]\nInternet-Draft                     AIP                       August 2026\n\n   *  Level 1 (Self-Reported): Agent reports its own results with no\n      independent verification.  Default for trusted environments.\n\n   *  Level 2 (Counter-Signed): Delegator independently verifies the\n      result and appends a verification block.\n\n   *  Level 3 (Third-Party Attested): External verifier (LDP peer, human\n      reviewer, or audit service) signs an attestation block.\n\n8.3.  Audit Tokens\n\n   A completed chained token with a completion block appended is a self-\n   contained audit artifact.  It answers five questions without\n   requiring an external database: who authorized (Block 0), through\n   whom (delegation blocks), what constraints (Datalog policies), what\n   happened (completion block), and whether it was verified\n   (verification_status).  Audit tokens are tamper-evident, non-\n   repudiable, and verifiable offline using public keys from identity\n   documents.\n\n9.  Security Considerations\n\n   This section addresses the security properties and threat model for\n   AIP.\n\n9.1.  Threat Model\n\n   AIP is designed to resist the following attack categories:\n\n   *  Scope widening: An agent attempts to exceed its delegated\n      capabilities.  Prevented by cryptographic scope attenuation\n      verification at each hop.\n\n   *  Delegation depth violation: An agent attempts to delegate beyond\n      the maximum permitted depth.  Prevented by depth tracking in each\n      delegation block.\n\n   *  Token replay: A captured token is reused.  Mitigated by short TTLs\n      (under 1 hour recommended for compact mode).\n\n   *  Token forgery: An attacker constructs a token without holding the\n      private key.  Prevented by Ed25519 signature verification.\n\n   *  Identity spoofing: An agent claims a false identity.  Prevented by\n      identity document resolution and signature verification.\n\nPrakash                 Expires 20 February 2027               [Page 16]\nInternet-Draft                     AIP                       August 2026\n\n   *  Audit evasion: An agent delegates with empty context to avoid\n      audit trails.  Prevented by mandatory non-empty context on all\n      delegation blocks.\n\n   *  Ancestor substitution: An attacker holding a valid leaf block\n      attempts to present it beneath a different, more permissive\n      ancestor.  Prevented by V1, which verifies the full signature\n      chain from the root key rather than the leaf in isolation.  A\n      substituted ancestor breaks the chain, because each block's\n      signature is produced by the key its predecessor committed to.\n\n   Two of these deserve to be separated, because conflating them is a\n   common source of error.  Signature chaining (V1) prevents blocks from\n   being forged, reordered, or substituted.  Attenuation checking (V4)\n   prevents a block from asserting more than its predecessor held.  The\n   first is a property of the container; the second is a property of the\n   capability content.  Neither implies the other, and a verifier that\n   performs only the first will accept a chain in which a delegation\n   widened its own authority.  Both are REQUIRED.\n\n9.2.  Adversarial Evaluation\n\n   Experimental evaluation across 600 adversarial attempts in six attack\n   categories showed a 100% rejection rate.  Two attack categories\n   (delegation depth violation and audit evasion through empty context)\n   are uniquely addressed by AIP's chained token structure and cannot be\n   detected by standard JWT deployments.  Details are reported in the\n   companion paper [AIP-PAPER].\n\n9.3.  Cryptographic Agility\n\n   AIP v1 mandates Ed25519 exclusively.  No algorithm negotiation is\n   supported.  This is a deliberate design choice to eliminate downgrade\n   attacks and reduce implementation complexity.  Future versions MAY\n   introduce additional algorithms through the protocol version field.\n\n9.4.  Transport Security\n\n   Identity document resolution and token-by-reference fetching MUST use\n   HTTPS.  Implementations SHOULD enforce TLS 1.3 or later.  Token-by-\n   reference URLs MUST be validated against expected domain patterns to\n   prevent SSRF attacks.  Fetch timeout SHOULD be 5 seconds.\n\n10.  IANA Considerations\n\n   This document requests the following IANA registrations:\n\nPrakash                 Expires 20 February 2027               [Page 17]\nInternet-Draft                     AIP                       August 2026\n\n10.1.  HTTP Authentication Scheme\n\n   Registration of the "AIP" HTTP authentication scheme in the "HTTP\n   Authentication Scheme Registry":\n\n   *  Authentication Scheme Name: AIP\n\n   *  Reference: This document, Section 6.3\n\n10.2.  Well-Known URI\n\n   Registration of the "aip" well-known URI suffix in the "Well-Known\n   URIs" registry:\n\n   *  URI Suffix: aip\n\n   *  Change Controller: IETF\n\n   *  Reference: This document, Section 2.3\n\n10.3.  Media Type\n\n   Registration of the "aip+jwt" structured syntax suffix:\n\n   *  Type name: application\n\n   *  Subtype name: aip+jwt\n\n   *  Reference: This document, Section 3.1\n\n11.  References\n\n11.1.  Normative References\n\n   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate\n              Requirement Levels", BCP 14, RFC 2119, March 1997,\n              <https://www.rfc-editor.org/info/rfc2119>.\n\n   [RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token\n              (JWT)", RFC 7519, May 2015,\n              <https://www.rfc-editor.org/info/rfc7519>.\n\n   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC\n              2119 Key Words", BCP 14, RFC 8174, May 2017,\n              <https://www.rfc-editor.org/info/rfc8174>.\n\nPrakash                 Expires 20 February 2027               [Page 18]\nInternet-Draft                     AIP                       August 2026\n\n   [RFC8785]  Rundgren, A., Jordan, B., and S. Erdtman, "JSON\n              Canonicalization Scheme (JCS)", RFC 8785, June 2020,\n              <https://www.rfc-editor.org/info/rfc8785>.\n\n   [RFC8693]  Jones, M., Nadalin, A., Campbell, B., Bradley, J., and C.\n              Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, January\n              2020, <https://www.rfc-editor.org/info/rfc8693>.\n\n11.2.  Informative References\n\n   [SPIFFE]   Cloud Native Computing Foundation, "Secure Production\n              Identity Framework for Everyone (SPIFFE)", 2026,\n              <https://spiffe.io/>.\n\n   [I-D.ietf-wimse-arch]\n              IETF WIMSE Working Group, "Workload Identity in a Multi\n              System Environment (WIMSE) Architecture", Work in\n              Progress, Internet-Draft, draft-ietf-wimse-arch, 2026,\n              <https://datatracker.ietf.org/doc/html/draft-ietf-wimse-\n              arch>.\n\n   [I-D.ietf-wimse-wpt]\n              IETF WIMSE Working Group, "WIMSE Workload Proof Token",\n              Work in Progress, Internet-Draft, draft-ietf-wimse-wpt,\n              2026, <https://datatracker.ietf.org/doc/html/draft-ietf-\n              wimse-wpt>.\n\n   [I-D.reece-wimse-cross-org-delegation]\n              Reece, M., "Cross-Organizational Delegation for Workload\n              and Agent Identity: Problem Statement and Requirements",\n              Work in Progress, Internet-Draft, draft-reece-wimse-cross-\n              org-delegation-00, June 2026,\n              <https://datatracker.ietf.org/doc/html/draft-reece-wimse-\n              cross-org-delegation-00>.\n\n   [I-D.rampalli-pedigree]\n              Rampalli, K., "PEDIGREE: Verifiable Delegation Identity\n              for Agentic AI Systems", Work in Progress, Internet-Draft,\n              draft-rampalli-pedigree, 2026,\n              <https://datatracker.ietf.org/doc/html/draft-rampalli-\n              pedigree>.\n\n   [BISCUIT]  Music, G., "Biscuit Authorization Token", 2024,\n              <https://www.biscuitsec.org/>.\n\nPrakash                 Expires 20 February 2027               [Page 19]\nInternet-Draft                     AIP                       August 2026\n\n   [AIP-PAPER]\n              Prakash, S., "AIP: Agent Identity Protocol for Verifiable\n              Delegation Across MCP and A2A", 27 March 2026,\n              <https://arxiv.org/abs/2603.24775>.\n\nAppendix A.  Cross-Organization Delegation Requirements Mapping\n\n   [I-D.reece-wimse-cross-org-delegation] enumerates nine requirements\n   for delegation between organizations that share no operator, no\n   runtime, and no bilateral agreement.  This appendix maps AIP against\n   them.  Verdicts are stated conditionally where the mechanism depends\n   on deployment choices, and gaps are named rather than argued around.\n\n   Other proposals address overlapping parts of the same problem,\n   including [I-D.rampalli-pedigree].  The requirements themselves,\n   rather than any one mechanism, are the useful common ground, and\n   several of the gaps identified below are shared across proposals.\n\n   R1, Recursive attenuation: MET.  Step V4 of Section 4 requires a\n      structural walk confirming that each hop is a subset of its\n      predecessor across scope, budget, time, and domains, verifiable\n      from the conveyed authority alone.  The canonical encoding in\n      Section 3.4.1 additionally makes scope widening impossible by\n      construction, since the authorized set is the intersection of per-\n      block allowlists.\n\n   R2, Cross-organizational verification: MET.  An aip:web: issuer\n      publishes its key at a location derived from its own DNS name, and\n      a relying party resolves it over HTTPS with no prior arrangement.\n      An aip:key: issuer needs no resolution at all.  Neither requires a\n      federation relationship established in advance of the interaction.\n\n   R3, No runtime callback: MET, with caching.  Once the issuer's\n      identity document is held, verification is local.  Documents are\n      cacheable, so the originating organization is not on the critical\n      path.  The exception is revocation freshness, which R7 addresses.\n\n   R4, Proof of possession: NOT MET by this document.  An AIP token is a\n      bearer credential, as stated in Section 5.3.  Binding the token to\n      a key requires a transport or message layer mechanism.  This\n      document deliberately does not define one, and points instead at\n      [I-D.ietf-wimse-wpt] and HTTP message signatures.\n\n   R5, Principal binding and invariance: MET when declared.  Block 0 MAY\n      declare a principal, and V4 requires that no subsequent block\n      declare a different one.  A chain that omits the principal conveys\n      agent authority only and does not satisfy R5.\n\nPrakash                 Expires 20 February 2027               [Page 20]\nInternet-Draft                     AIP                       August 2026\n\n   R6, Dual-axis authorization: NOT MET, and out of scope.  AIP conveys\n      the agent's authority and the identity of the bound principal.  It\n      does not carry the principal's entitlements, and a verifier cannot\n      evaluate them from the token.  Composing the two axes is the\n      relying party's responsibility.  Naming this rather than claiming\n      it seems more useful to the working group.\n\n   R7, Authentic, bounded-staleness revocation: MET.  Step V7 requires\n      signed revocation responses, so authenticity does not depend on\n      transport trust, and requires verifiers to be configurable with a\n      maximum staleness and to fail closed beyond it.\n\n   R8, Tamper-evident, composable audit: MET.  Each delegation block\n      records delegator, delegate, and a non-empty context, and\n      completion blocks record outcome and cost.  Because blocks are\n      signed in sequence, a participant's own record cannot be altered\n      undetectably by a later participant, and the chain composes into\n      an end-to-end account.\n\n   R9, Format and transport agnosticism: MET.  Compact mode is a JWT and\n      chained mode is a Biscuit token; neither presupposes a transport.\n      Bindings are specified for MCP, A2A, and generic HTTP, and the\n      identity layer is uniform across them.\n\n   Summarising the gaps: AIP does not by itself prove possession (R4) or\n   evaluate principal entitlements (R6).  Both are shared with other\n   proposals in this space and both are better solved by composition\n   than by any one document.\n\nAppendix B.  Changes from draft-prakash-aip-00\n\n   *  Added Section 4, a normative verification algorithm with ordered\n      steps V1 through V7 and defined error codes.  Draft-00 asserted\n      that verifiers must check attenuation at every hop without\n      specifying how, which left the requirement open to divergent\n      readings.\n\n   *  Added Section 3.4.1, fixing the exact Datalog each implementation\n      must emit for the Simple profile.  Draft-00 named canonical\n      templates without normative form, and independent implementations\n      diverged.\n\n   *  Changed budget from a Datalog check to a budget_ceiling fact\n      verified structurally in V4, and stated plainly that ceiling\n      verification is not spend enforcement.  The previous encoding\n      could not express the intended comparison.\n\nPrakash                 Expires 20 February 2027               [Page 21]\nInternet-Draft                     AIP                       August 2026\n\n   *  Added an OPTIONAL principal fact with an invariance rule,\n      addressing principal binding along a chain.\n\n   *  Added Section 5 describing workload-attested anchoring, the\n      relationship to workload identity systems, and the relationship to\n      token exchange.\n\n   *  Stated explicitly that AIP tokens are bearer credentials and that\n      verification does not authenticate the presenter.\n\n   *  Added bounded-staleness and signed-response requirements for\n      revocation.\n\n   *  Added Appendix A.\n\nAcknowledgements\n\n   The Biscuit authorization token specification influenced the chained\n   mode design.  The MCP and A2A protocol teams provided the agent\n   communication infrastructure that AIP extends.\n\nAuthor's Address\n\n   Sunil Prakash\n   Independent\n   Email: sunil@sunilprakash.com\n   URI:   https://sunilprakash.com\n\nPrakash                 Expires 20 February 2027               [Page 22]\n
\n \n \n \n \n
Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems

Abstract

\nStatus of This Memo\n

\nCopyright Notice\n

\nTable of Contents\n

\n1. Introduction\n

\n1.1. Requirements Language\n

\n2. Identity Scheme\n

\n2.1. DNS-Based Identifiers\n

\n2.2. Self-Certifying Identifiers\n

\n2.3. Identity Document\n

\n3. Token Formats\n

\n3.1. Compact Mode (JWT)\n

\n3.2. Chained Mode (Biscuit)\n

\n3.3. Scope Attenuation\n

\n3.4. Policy Profiles\n

\n3.5. Budget Semantics\n

\n4. Protocol Bindings\n

\n4.1. MCP Binding\n

\n4.2. A2A Binding\n

\n4.3. HTTP Binding\n

\n5. Delegation Lifecycle\n

\n5.1. Bounded Depth\n

\n5.2. Delegation Context\n

\n5.3. Ephemeral Agent Grants\n

\n5.4. Key Rotation\n

\n5.5. Revocation\n

\n6. Provenance and Audit\n

\n6.1. Completion Blocks\n

\n6.2. Verification Trust Levels\n

\n6.3. Audit Tokens\n

\n7. Security Considerations\n

\n7.1. Threat Model\n

\n7.2. Adversarial Evaluation\n

\n7.3. Cryptographic Agility\n

\n7.4. Transport Security\n

\n8. IANA Considerations\n

\n8.1. HTTP Authentication Scheme\n

\n8.2. Well-Known URI\n

\n8.3. Media Type\n

\n9. References\n

\n9.1. Normative References\n

\n9.2. Informative References\n

\nAcknowledgements\n

\nAuthor's Address\n

\n Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems\n \n draft-prakash-aip-01\n

\n Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems\n
\n draft-prakash-aip-01\n
