Agent Identity Protocol (AIP): Verifiable Delegation for AI Agent Systems

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

1.2. Terminology

Delegation chain token:

A token carrying an ordered list of links, L0 through LN, in one of the encodings of Section 5.¶

Authority link:

L0, the link signed by the issuer's root key.¶

Delegation link:

Any link Li with i of 1 or more. N, the number of delegation links, is the delegation depth of the chain.¶

Relying party:

The party that verifies a chain before acting on it, for example an MCP server or an A2A agent.¶

Effective value:

For a link and a dimension, the value the link declares, or, if it declares none, the effective value of its parent. See Section 3.2.¶

2.1. DNS-Based Identifiers

DNS-based identifiers follow the format:¶

aip:web:<domain>/<path>

Example: aip:web:example.com/agents/research-analyst¶

DNS-based identifiers are suitable for long-lived agents with stable domain ownership. Identity documents are resolved via HTTPS at a well-known path.¶

2.2. Self-Certifying Identifiers

aip:key:ed25519:<multibase-encoded-public-key>

Self-certifying identifiers derive identity from the public key itself. They are suitable for ephemeral agents that do not require DNS infrastructure. The identifier is computed from the 32-byte Ed25519 [RFC8032] public key encoded as multibase base58btc (a "z" prefix followed by the base58btc encoding of the key).¶

2.3. Identity Document

Each agent with a DNS-based identifier MUST publish an identity document at:¶

https://<domain>/.well-known/aip/<path>.json

The identity document is a JSON object containing:¶

• aip: Protocol version (MUST be "1.0")¶
• id: The agent's AIP identifier¶
• public_keys: Array of public key objects, each with id, type, public_key_multibase (the Ed25519 key in multibase base58btc, as in Section 2.2), and optional valid_from and valid_until¶
• name: Human-readable agent name¶
• delegation: Delegation preferences¶
• protocols: Supported protocol bindings¶
• revocation: OPTIONAL revocation endpoint (see Section 4.7)¶
• document_signature: Ed25519 signature over the canonicalized document, encoded as base64url without padding (Section 5 of [RFC4648])¶
• expires: Document expiration timestamp¶

The document MUST be self-signed. Verification uses JSON Canonicalization Scheme (JCS) [RFC8785]: remove the document_signature field, canonicalize the remaining JSON, and verify the Ed25519 signature against a currently-valid public key.¶

3.1. Links

A chain is an ordered list of links L0, L1, ..., LN. L0 is the authority link. L1 through LN are delegation links. Each link has the following fields:¶

• issuer and delegate are AIP identifiers (Section 2). The issuer of L0 is the party whose root key signs the chain. In the JWT chain encoding the verifier checks that the issuer of Li equals the delegate of L(i-1) (Section 5.1.3). In the Biscuit encoding L0 has no delegate, delegator and delegate are assertions (Section 5.2.4), and this equality is not checked.¶
• tools is an allowlist of tool names or patterns (Section 3.4).¶
• domains is an allowlist of domain names.¶
• budget_ceiling is a non-negative integer number of cents (Section 3.5). The token does not name a currency; issuer and relying party agree on it out of band.¶
• expiry is a point in time after which the link conveys no authority.¶
• context is a human-readable statement of the purpose of the delegation.¶
• principal is the identifier of the party on whose behalf the chain acts.¶
• max_depth is a non-negative integer bounding N.¶
• holder key is the public key of the delegate, used to sign the next link and to prove possession (Section 8). The Biscuit encoding has no holder key.¶

When tools or domains is present in any link, it MUST be non-empty. An empty list is malformed, and a verifier MUST reject a chain containing one with aip_token_malformed. Absence means the link inherits; it never means "nothing permitted".¶

3.2. Inheritance

The effective value of a dimension at L0 is the value L0 declares. The effective value at Li is the value Li declares if it declares one, and otherwise the effective value at L(i-1). The effective values at LN are the authority the chain conveys to its final holder.¶

An effective domains value that is undefined at every link means the chain places no constraint on domains. The same holds for budget_ceiling and principal. A delegation link MAY declare a domains list, a budget ceiling, or a principal when no ancestor declares one; doing so narrows the chain.¶

3.3. Attenuation Invariant

For every i of 1 or more, and for every dimension (tools, domains, budget_ceiling, expiry, and principal), the effective value at Li MUST be narrower than or equal to the effective value at L(i-1): every tool Li permits MUST be permitted at L(i-1); every domain Li permits MUST be permitted at L(i-1); the budget ceiling at Li MUST NOT exceed that at L(i-1); the expiry at Li MUST NOT be later than that at L(i-1); and once a link declares a principal, no later link may declare a different one. A chain that violates this invariant at any hop conveys no authority, and verifiers MUST reject it as specified in step V4 of Section 4.¶

The invariant is a property of the capability content. It is not established by the signature structure of either encoding, and it is checked separately (Section 4.4).¶

3.4. Wildcards and Matching

A tools entry "*" covers every tool. Any other entry ending in "*" covers every tool whose name starts with the text before the "*"; for example "tool:*" covers "tool:search". Any other entry covers only the identical name.¶

Narrowing compares an entry in Li against the entries at L(i-1) with the same rule, treating the Li entry as a literal string. An ancestor wildcard therefore permits a specific value or a narrower prefix pattern in a descendant ("tool:*" permits "tool:s*"). A specific value in an ancestor MUST NOT widen to a wildcard in a descendant: "tool:search" does not cover "tool:*", because "tool:*" does not start with "tool:search".¶

Domains are matched exactly in this revision. There is no wildcard or suffix matching for domains.¶

3.5. Budget Semantics

Budget values in AIP tokens represent per-chain authorization ceilings, not running balances. A delegator asserts "I authorize up to this amount for this task" at delegation time.¶

A budget ceiling is both declared and verified, and the two are distinct operations:¶

• Declared by the link that establishes it, as an integer number of cents.¶
• Verified structurally at every hop: a verifier MUST confirm that each declared ceiling is non-negative and does not exceed the effective ceiling of the parent link. A link that declares no ceiling inherits. This check is step V4 of Section 4.¶

What the token does not do is track cumulative spending. Nothing in a delegation chain records how much of a ceiling has been consumed, and a verifier evaluating a single request cannot know. Enforcement of actual spend against a ceiling is out of band, and is the responsibility of the orchestration platform at dispatch time.¶

Implementations MUST NOT present ceiling verification as spend enforcement. A chain that verifies establishes that no hop authorized more than it held. It does not establish that the authorized amount remains available.¶

4.1. Step V1: Chain Integrity

The verifier MUST verify the signature on every link, as defined by the encoding (Section 5.1.3 and Section 5.2.3), starting from the root public key. Verifying the signature on the presented leaf alone is not sufficient.¶

Verification MUST be performed against the serialized form as received. An implementation that holds a token in a parsed in-memory representation MUST re-serialize and re-verify before relying on it, rather than trusting the state of its own parsed object.¶

A verifier MUST NOT accept any field from a link that it has not verified as part of a chain rooted at the issuer's key. Failure returns aip_signature_invalid.¶

4.2. Step V2: Root Binding

The verifier MUST take the issuer of L0 and confirm that the root public key used in V1 is the key bound to that identifier:¶

• For aip:web: identifiers, by resolving the identity document as specified in Section 2.3 and comparing the published key.¶
• For aip:key: identifiers, by decoding the key from the identifier itself and comparing.¶
• In the workload-attested anchor mode (Section 6.1), by the attestation the verifier recognises.¶

An identifier that does not resolve, or that resolves to a different key, returns aip_identity_unresolvable. A verifier MUST NOT infer the root key from the token.¶

V2 establishes which key speaks for the issuer. It does not establish that the issuer is entitled to grant authority over the relying party's resources: anyone can create an aip:key: identifier and sign a chain under it. A relying party MUST accept chains only from issuers it has chosen, by its own policy, to trust as sources of authority for the resource, and MUST reject chains from any other issuer. When the relying party holds a fixed set of trusted issuer keys this is detected in V1 and returns aip_signature_invalid; otherwise it returns aip_identity_unresolvable.¶

4.3. Step V3: Depth

The verifier MUST confirm that L0 declares a max_depth of 0 or more and that N, the number of delegation links, does not exceed it. A missing max_depth returns aip_token_malformed. N greater than max_depth returns aip_depth_exceeded.¶

4.4. Step V4: Structural Attenuation Walk

The verifier MUST confirm that L0 declares tools and expiry, that no tools or domains list in any link is empty, and that no delegation link declares max_depth. Failure returns aip_token_malformed.¶

The verifier MUST then check L0 and walk the chain from L1 to LN, comparing each declared value with the effective value of the parent link (Section 3.2):¶

• Tools: every entry declared by Li MUST be covered (Section 3.4) by some entry of the effective tools at L(i-1). Failure returns aip_scope_insufficient.¶
• Domains: if the effective domains at L(i-1) is defined, every domain declared by Li MUST be a member of it. If no ancestor declares domains, Li MAY declare any non-empty list. Failure returns aip_scope_insufficient.¶
• Budget: every declared budget_ceiling, including that of L0, MUST be non-negative, and a ceiling declared by Li MUST NOT exceed the effective ceiling at L(i-1). Failure returns aip_budget_exceeded.¶
• Time: the expiry of L0 MUST NOT be earlier than the current time. An expiry declared by Li MUST NOT be later than the effective expiry at L(i-1) and MUST NOT be earlier than the current time. All of these failures return aip_token_expired.¶
• Principal: if a link declares a principal and an earlier link has already declared one, the two MUST be identical. The on-behalf-of principal is invariant along a chain: intermediaries narrow authority, they do not substitute the party on whose behalf the chain acts. Failure returns aip_token_malformed.¶

This step is REQUIRED and is not satisfied by the container format. Signature chaining establishes that links were appended in order by successive keyholders. It prevents a link from being substituted, reordered, or forged, but it does not establish that the capabilities asserted in Li are a subset of those held at L(i-1). V4 is a comparison of declared values and MUST NOT be replaced by evaluation of the token's policy language.¶

4.5. Step V5: Delegation Context

Every delegation link MUST carry a context that is non-empty and not only whitespace. A verifier MUST reject a chain in which any delegation link omits it or supplies an empty value, returning aip_token_malformed.¶

4.6. Step V6: Request Authorization

V6 decides whether the specific request falls within the authority at the leaf. It has a structural part, which applies to both encodings, and a policy part, which applies to the Biscuit encoding only.¶

Structural part: the requested tool MUST be covered by the effective tools at LN. If the request names a domain and the effective domains at LN is defined, the domain MUST be a member of it. A request that names no domain is not constrained by the domains dimension; a relying party that needs domain enforcement MUST supply the domain of every request. Failure returns aip_scope_insufficient.¶

Policy part (Biscuit encoding): the verifier MUST evaluate the token's Datalog with the ambient facts tool, time, and depth bound to the request under consideration, and MUST require that every check in every block passes. The verifier MUST NOT introduce ambient facts beyond those named. In particular it MUST NOT supply a budget fact: doing so causes any budget check in the chain to evaluate against verifier-chosen data rather than against the token. Budget is handled in V4. Failure returns aip_scope_insufficient.¶

Some requests name no tool, for example an MCP initialize or tools/list. For those, a verifier MUST still perform V1 through V5 and V7, and skips V6.¶

4.7. Step V7: Revocation with Bounded Staleness

If the issuer's identity document advertises a revocation endpoint, the verifier MUST check whether any key in the chain has been revoked. Revocation data MAY be cached. A verifier MUST be configurable with a maximum acceptable staleness for cached revocation data, and MUST fail closed when its cached data is older than that bound, returning aip_key_revoked rather than proceeding on stale information.¶

Revocation responses MUST be signed by the issuer so that their authenticity is verifiable without a trusted transport to the revocation endpoint.¶

This revision does not specify the format of the revocation endpoint, its responses, how revoked keys are identified, or how freshness is represented, so V7 cannot yet be implemented interoperably. No known implementation performs it (Section 11).¶

4.8. Verification Result

A token that passes V1 through V7 establishes: the identity of the issuer, the capabilities available at the leaf, and that no hop in the chain exceeded the authority of its predecessor.¶

Whether it also establishes the identity of each delegator and delegate depends on the encoding. In the JWT chain encoding each delegation link is signed by the key that the previous link named in cnf, so the chain of keys is authenticated. The pairing of that key with the identifier in sub is asserted by the signer of the previous link. Delegator and delegate identity are therefore established only if the verifier also confirms, for each link, that the cnf key is bound to the sub identifier, by decoding an aip:key: identifier or by resolving the identity document of an aip:web: identifier. A verifier that relies on delegator identity MUST perform that check. In the Biscuit encoding delegation blocks are appended under keys the token itself supplies, so delegator and delegate are asserted by whoever appended the block, not authenticated (Section 5.2.4).¶

In neither encoding does verification establish that the presenting party is the party the leaf was issued to. See Section 8 and Section 12.2.¶

5.1. JWT Chain Encoding

<link0>~<link1>~...~<linkN>

{"alg":"EdDSA","typ":"aip-link+jwt"}

5.2. Biscuit Encoding

The Biscuit encoding uses Biscuit tokens [BISCUIT] with append-only blocks and Datalog policy. Block 0 is L0 and is signed by the root key. Block i is Li.¶

identity("<aip-identifier>");
principal("<identifier>");        ; OPTIONAL, on-behalf-of party
right("<tool>");                  ; one fact per tools entry
domain("<domain>");               ; OPTIONAL, one fact per domain
max_depth(<n>);
budget_ceiling(<cents>);          ; OPTIONAL, integer cents
check if <tool-constraint>;
check if time($t), $t <= <expiry>;

delegator("<aip-identifier>");
delegate("<aip-identifier>");
context("<non-empty string>");
domain("<domain>");               ; OPTIONAL, one fact per domain
principal("<identifier>");        ; OPTIONAL
budget_ceiling(<cents>);          ; OPTIONAL, integer cents
check if <tool-constraint>;       ; OPTIONAL, absent = inherit
check if time($t), $t <= <expiry>;  ; OPTIONAL, absent = inherit

5.3. Distinguishing the Encodings

A JWS Compact Serialization starts with the base64url encoding of a JSON object, so a JWT chain starts with "eyJ". A verifier receiving a token in a binding that does not label its type treats a token that starts with "eyJ" as a JWT chain, and a token that is a single JWS with header typ "aip+jwt" as the deprecated draft-01 form (Section 5.1.4). Any other token is parsed as Biscuit. The header is read without verification only to choose the verifier; nothing in it is trusted before V1.¶

6.1. Anchor Modes

L0 is signed by the issuer's key. Four ways of establishing trust in that key, or in the authority behind it, are defined:¶

• DNS-anchored: the issuer is an aip:web: identifier and the key is published in an identity document resolved over HTTPS. Trust derives from the Web PKI and DNS control.¶
• Self-certifying: the issuer is an aip:key: identifier and the key is the identifier. Trust derives from whoever accepted the identifier.¶
• Workload-attested: the issuer's key is bound to a workload identity credential issued by an external authority, and the identity document records that binding. Trust derives from that authority's attestation.¶
• AIMS-anchored: in the JWT chain encoding, L0 carries an aip_anchor claim (Section 5.1.5) binding the chain to an access token or transaction token. This supplements one of the other modes; it does not replace V2.¶

In workload-attested mode, an identity document MAY carry a workload_identity member naming the credential that attests the issuer key, for example a SPIFFE ID. A verifier that recognises the naming authority MAY treat that attestation as the basis for accepting the root key, in place of resolving the document over HTTPS. A verifier that does not recognise it MUST fall back to the DNS-anchored or self-certifying path, and MUST NOT treat an unrecognised attestation as an endorsement.¶

In this deployment a workload identity system establishes that the orchestrator is what it claims to be inside its own trust domain, and AIP carries what that orchestrator was permitted to delegate onward, across boundaries the workload identity system does not span.¶

9.1. MCP Binding

AIP tokens are transported in MCP via the X-AIP-Token HTTP header:¶

X-AIP-Token: <jwt-chain-or-biscuit-token>

For tokens exceeding 4KB, token-by-reference is supported:¶

X-AIP-Token-Ref: https://issuer/.well-known/aip/tokens/<id>

An MCP server extracts the token from the header, or fetches it from the reference URL, determines the encoding as in Section 5.3, and verifies it according to Section 4. For tools/call the requested tool is the string "tool:" followed by the tool name in the request, so tools entries for MCP are written in that form (for example "tool:search" or "tool:*"). On success the server injects the verified identity into the request context, where the tool implementation MAY use it for authorization decisions, logging, or audit.¶

Nine error codes are defined with HTTP status mappings: 401 for authentication failures (aip_token_missing, aip_token_malformed, aip_signature_invalid, aip_identity_unresolvable, aip_token_expired, aip_key_revoked) and 403 for authorization failures (aip_scope_insufficient, aip_budget_exceeded, aip_depth_exceeded).¶

A server MAY apply local policy after verification, for example a lower depth or budget limit than the chain allows. Failures of such policy are not part of this specification. The reference proxy reports them as aip_audit_failed with status 403.¶

Servers declare AIP requirements via the require_aip field in their identity document's protocols.mcp configuration.¶

9.2. A2A Binding

In A2A interactions, AIP tokens are transported in the metadata.aip_token field of task submissions. Agent cards are extended with an aip_identity object containing the agent's AIP identifier and document URL.¶

The calling agent appends a delegation link with attenuated authority before sending the task. In addition to Section 4, the receiving agent verifies that the chain has at least one delegation link and that the delegate of the leaf link is its own AIP identifier. The receiving agent determines the requested tool for V6 from the task, for example the skill the task asks it to perform.¶

9.3. HTTP Binding

For generic HTTP APIs not using MCP or A2A, tokens are transported via the Authorization header with the AIP scheme:¶

Authorization: AIP <token>

The token is sent as is. Both a JWT chain and a Biscuit token in its base64url form consist only of characters permitted in the token68 syntax of Section 11.2 of [RFC9110]. Token-by-reference uses the X-AIP-Token-Ref header with a 5-second fetch timeout and SSRF protection (reject reference URLs outside expected domain patterns).¶

10.1. Bounded Depth

L0 declares max_depth, which is REQUIRED. Each delegation link increments the depth by 1. A holder whose link is at depth equal to max_depth MUST NOT delegate further. A max_depth of 0 means the first holder MUST NOT delegate.¶

10.2. Delegation Context

Each delegation link MUST include a non-empty context containing a human-readable description of the delegation purpose. Verifiers MUST reject tokens with missing or empty context (V5). This keeps the reason for each hop in the audit record.¶

10.3. Ephemeral Agent Grants

For short-lived sub-agents, a parent agent generates an Ed25519 keypair, creates an aip:key: identifier, and appends a delegation link with scoped capabilities and a short TTL (5 minutes RECOMMENDED). In the JWT chain encoding the new key is the cnf of that link. The parent's identity document MAY set delegation.allow_ephemeral_grants to false to prevent this.¶

10.4. Key Rotation

DNS-based identifiers support zero-downtime key rotation through overlapping validity windows on public keys. A new key is published with a future valid_from timestamp. Both keys are valid during the overlap period. Recommended rotation period is 90 days. Cache TTL MUST NOT exceed 5 minutes.¶

Self-certifying identifiers cannot rotate keys; key rotation requires identity replacement, which is acceptable for ephemeral agents.¶

10.5. Revocation

AIP prefers short-lived tokens over revocation infrastructure. Single-link chains SHOULD have a lifetime under 1 hour, which bounds the window in which a compromised key or captured token can be used; whether that window is acceptable is a deployment decision. Key revocation (removing a key from the identity document) invalidates all chains rooted in that key. Step V7 defines the requirements on revocation checking. Token-specific revocation lists are not specified.¶

10.6. Future Work

Signed records of the outcome of a delegated action, appended by the executing agent, are a possible extension. Draft-01 defined completion blocks for this purpose; they were never implemented and are removed from this revision.¶

11.1. Python Reference Implementation

Organization:

The author.¶

Name:

agent-identity-protocol (Python), https://github.com/sunilp/aip¶

Licensing:

Apache-2.0.¶

Maturity:

Reference implementation. The code described here is on a development branch and not yet in a released version; the latest release (0.5.0) implements draft-01.¶

Coverage:

Both encodings on one link model. V1, V3, V4, V5, and both parts of V6, including domains and the rules for empty allowlists, repeated single-valued Biscuit facts, and cnf key syntax, and rejection of Biscuit blocks missing identity, delegator, or delegate. MCP middleware, an MCP proxy, and an A2A verifier that accept either encoding.¶

Draft-01 compact tokens: the library verifier for JWT chains maps a token with typ "aip+jwt" onto the link model as in Section 5.1.4. The MCP middleware and proxy do not use that path; for such tokens they keep draft-01 compact semantics: signature and expiry checks, an exact match of the requested tool against scope with no wildcards, and no V3 or V4. The compact verifier rejects any typ other than "aip+jwt" as malformed. The A2A verifier does not accept compact tokens.¶

V2: the library takes the root key from its caller and does not resolve identity documents over HTTPS. Only the MCP proxy compares the issuer a chain declares with the issuer its key is configured for, and only when trusted keys are configured as a mapping from issuer to key; with a single unbound key it skips the comparison and logs a warning. The MCP middleware and the A2A verifier take one key and do not compare issuers. The JWT chain verifier does not check that links carry iat and jti, which Section 5.1.2 requires of issuers. V7 is not implemented. The workload-attested anchor mode, the token-by-reference header, and the HTTP Authorization binding are not implemented. aip_anchor is carried but not checked. No binding supplies a request domain, so domain constraints are enforced in V4 but not against requests. The JWT chain verifier does not check that each cnf key is bound to its sub identifier (Section 4.8). The MCP proxy, middleware and A2A verifier do not verify proof of possession, so JWT chains presented to them are subject to truncation (Section 12.2).¶

Identity document signatures are decoded as base64url (standard base64 is also accepted for documents written by earlier versions). Canonicalization uses sorted-key compact JSON, which agrees with JCS for documents whose strings are ASCII and whose numbers are integers. The document is first parsed into a fixed model, so members the model does not define (including workload_identity of Section 6.1) and members whose value is null are dropped from the bytes that are verified. The signature is checked against the first listed key only.¶

Testing:

At commit 989a4f2, 311 unit and integration tests (python -m pytest in the python directory), including a suite that runs the same forged-delegation cases (tool widening, domain widening, budget increase, principal substitution, missing context) through both encodings and requires the same error code from each.¶

A further 26 cross-language tests between the Python and Rust implementations, in three groups: 4 exchange Biscuit chains with a delegation block between the implementations, two checking acceptance and two checking that a tool removed by delegation is rejected; 2 check that draft-01 compact JWTs minted by either verify in the other; and 20 check that both render the same Datalog for the tool, budget and depth parts of an authority block and that neither emits a forbidden budget or depth check. Eight of those 20 use an empty tools list, which this revision makes malformed. None of them covers the JWT chain encoding or domains.¶

Contact:

sunil@sunilprakash.com¶

11.2. Rust Implementation

Organization:

The author.¶

Name:

aip-core, aip-token, and aip-mcp crates, same repository.¶

Licensing:

Apache-2.0.¶

Coverage:

The Biscuit encoding at the draft-01 level: V1, V3, the tools, budget, and principal parts of V4, V5, and the policy part of V6, with expiry enforced by the Datalog time check only. It interoperates with the Python implementation for tokens without domains. It has no JWT chain encoding, no domains, and does not reject repeated single-valued facts or max_depth in delegation blocks. It mints and accepts an authority block with no tool check when given an empty tools list, which imposes no tool constraint; this revision makes such a block malformed. It verifies principal invariance but cannot mint a principal fact. It decodes identity document signatures as hex, which does not match Section 2.3. V7 is not implemented.¶

Testing:

At commit 989a4f2, 80 tests (cargo test in the rust directory).¶

Contact:

sunil@sunilprakash.com¶

12.1. Threat Model

AIP is designed to resist the following attack categories:¶

• Scope widening: an agent attempts to exceed its delegated capabilities. A link that widens is rejected by the structural attenuation walk (V4). In the JWT chain encoding a downstream holder can still regain an ancestor's wider authority by truncating the chain, unless the relying party verifies proof of possession (Section 12.2).¶
• Delegation depth violation: an agent attempts to delegate beyond the maximum permitted depth. Prevented by V3.¶
• Token replay: a captured token is reused. Mitigated by short lifetimes, and prevented only where the relying party verifies proof of possession (Section 8).¶
• Token forgery: an attacker constructs a token without holding the private key. Prevented by Ed25519 signature verification.¶
• Identity spoofing: an agent claims a false issuer identity. Prevented by V2. In the JWT chain encoding the chain of holder keys is authenticated, and delegator identity is protected only when the verifier also checks each key against its identifier (Section 4.8). The Biscuit encoding does not protect delegator identity.¶
• Audit evasion: an agent delegates with empty context to avoid audit trails. Prevented by V5.¶
• Ancestor substitution: an attacker holding a valid leaf attempts to present it beneath a different, more permissive ancestor. Prevented by V1, which verifies the full signature chain from the root key. In the JWT chain encoding each link also commits to its parent through prev.¶

Signature chaining and attenuation checking are different properties. Signature chaining (V1) prevents links from being forged, reordered, or substituted. Attenuation checking (V4) prevents a link from asserting more than its predecessor held. The first is a property of the container; the second is a property of the capability content. Neither implies the other, and a verifier that performs only the first will accept a chain in which a delegation widened its own authority. Both are REQUIRED.¶

12.2. Truncation of JWT Chains

Any prefix L0 through Lk of a valid JWT chain is itself a valid chain. It carries the authority held by the delegate of Lk, which is wider than or equal to the authority at the leaf. A holder of a longer chain can therefore remove its own and later links and present the prefix. Signature verification and V4 will both succeed.¶

Proof of possession closes this: the prefix names the key of an earlier holder in its leaf cnf, which the truncating party does not hold. A relying party that relies on attenuation holding against downstream holders MUST verify proof of possession of the key named in the leaf link's cnf, as stated in Section 8. Without it, a JWT chain conveys no more assurance than a bearer grant from its root.¶

The Biscuit encoding resists truncation, because the token carries only the private key for its last block, and presenting a shorter chain requires the key for an earlier block, which a downstream holder does not have. It remains a bearer credential in every other respect.¶

12.3. Identity Guarantees Depend on the Encoding

In the JWT chain encoding a delegation link can only be produced by the holder of the key the previous link named, so the chain of keys is authenticated. The identifier paired with each key is the previous signer's assertion until the verifier checks the binding (Section 4.8). Without that check, a delegator can name another party's identifier in sub next to its own key in cnf and sign the next link under that name. In the Biscuit encoding any holder can append a block naming any delegator. Relying parties and auditors MUST NOT treat a Biscuit delegator fact as evidence that the named party delegated.¶

12.4. Datalog Encoding

• Named rules shared between blocks do not attenuate. Datalog takes the union of rules with the same head, so a delegation block's narrower rule is added to the ancestor's broader rule rather than replacing it, and the broader rule then satisfies the delegation block's check. Each block's tool constraint MUST be one self-contained check, as in Section 5.2.2.¶
• Budget MUST be a structural fact, not a check, and verifiers MUST NOT inject ambient budget facts (Section 5.2.2).¶
• Block and authorizer sources are Datalog text. A string value containing a double quote, a backslash, or a control character can close its own term and append facts, checks, or policies, either to a signed block or to the authorizer that decides a request. Implementations MUST reject such values in identifiers, tools, domains, and context before they become Datalog, and MUST bind the requested tool in V6 as a parameter or validate it the same way. Earlier versions of the reference implementation had authorization bypasses of this kind.¶

12.5. Agreement Is Not Conformance

Two implementations that accept each other's tokens can both be wrong in the same way. During the development of draft-01, the Python and Rust implementations passed their cross-language tests while both failed to perform checks this document requires. Implementers should test against the MUST statements of this document, including negative cases, and not only against another implementation.¶

12.6. Adversarial Evaluation

The companion paper [AIP-PAPER] reports an evaluation of an earlier version of the reference implementation against six attack categories. That evaluation predates this revision and the JWT chain encoding, and is not evidence about either.¶

12.7. Cryptographic Agility

This revision mandates Ed25519 exclusively, and the JWT chain encoding pins the alg header. No algorithm negotiation is supported. This is a deliberate choice to eliminate downgrade attacks and reduce implementation complexity. Future revisions MAY introduce additional algorithms through a new typ value or the protocol version field.¶

12.8. Transport Security

Identity document resolution and token-by-reference fetching MUST use HTTPS. Implementations SHOULD enforce TLS 1.3 or later. Token-by-reference URLs MUST be validated against expected domain patterns to prevent SSRF attacks. Fetch timeout SHOULD be 5 seconds.¶

14.1. HTTP Authentication Scheme

Registration of the "AIP" HTTP authentication scheme in the "HTTP Authentication Schemes" registry:¶

• Authentication Scheme Name: AIP¶
• Reference: This document, Section 9.3¶

14.2. Well-Known URI

Registration of the "aip" well-known URI suffix in the "Well-Known URIs" registry:¶

• URI Suffix: aip¶
• Change Controller: IETF¶
• Reference: This document, Section 2.3¶

14.3. Media Types

Registration of the following media types in the "Media Types" registry, using the template of [RFC6838]. The following fields are the same for each:¶

• Type name: application¶
• Required parameters: N/A¶
• Optional parameters: N/A¶
• Encoding considerations: 7bit; the value consists of ASCII characters only¶
• Security considerations: see Section 12 of this document¶
• Interoperability considerations: N/A¶
• Published specification: this document¶
• Applications that use this media type: AI agent systems and the services they call¶
• Fragment identifier considerations: N/A¶
• Additional information: Deprecated alias names for this type: N/A; Magic number(s): N/A; File extension(s): N/A; Macintosh file type code(s): N/A¶
• Person and email address to contact for further information: Sunil Prakash, sunil@sunilprakash.com¶
• Intended usage: COMMON, except "aip+jwt", which is OBSOLETE¶
• Restrictions on usage: none¶
• Author: Sunil Prakash¶
• Change controller: IETF¶

The subtypes are:¶

• Subtype name "aip-chain+jwt": a JWT chain (Section 5.1.1).¶
• Subtype name "aip-link+jwt": a single link of a JWT chain. The JWT typ header value "aip-link+jwt" is this media type with the "application/" prefix omitted, as described in Section 4.1.9 of [RFC7515].¶
• Subtype name "aip+jwt": the draft-01 compact form, deprecated (Section 5.1.4). This registration was requested by draft-01 and is kept so that the deprecated typ value remains defined.¶

14.4. JSON Web Token Claims

Registration of the following claims in the "JSON Web Token Claims" registry established by [RFC7519]. For all of them the Change Controller is IETF and the Specification Document is Section 5.1.2 of this document.¶