AIP Specification v0.2.0

AIP Core: Identity Scheme and Resolution

Version: 0.1.0-draft

Status: Draft

Date: 2026-03-22

1. Introduction

This document defines the AIP identity scheme, identity document format, self-signature mechanism, resolution algorithm, and version compatibility rules. All identifiers, documents, and resolution behavior described here are normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. Identifier Format

AIP defines two identifier schemes: DNS-based identifiers for long-lived agents and self-certifying identifiers for ephemeral agents.

2.1 ABNF Grammar

The identifier format is defined using ABNF (RFC 5234):

aip-identifier  = aip-web-id / aip-key-id

aip-web-id      = "aip:web:" domain "/" path
domain          = 1*( ALPHA / DIGIT / "-" / "." )
path            = segment *( "/" segment )
segment         = 1*( ALPHA / DIGIT / "-" / "_" )

aip-key-id      = "aip:key:" algorithm ":" multibase-key
algorithm       = "ed25519"          ; v1 supports Ed25519 only
multibase-key   = "z" 1*BASE58CHAR  ; multibase with base58btc prefix
BASE58CHAR      = %x31-39 / %x41-48 / %x4A-4E / %x50-5A
                / %x61-6B / %x6D-7A
                ; 1-9, A-H, J-N, P-Z, a-k, m-z (no 0, I, O, l)

2.2 DNS-Based Identifiers (aip:web:)

DNS-based identifiers are for long-lived agents with stable domain-backed identities.

Format:

aip:web:<domain>/<path>

Example:

aip:web:jamjet.dev/agents/research-analyst

Requirements:

• The domain component MUST be a valid DNS hostname.
• The path component MUST contain at least one segment.
• Implementations MUST resolve aip:web: identifiers via HTTPS as defined in Section 5.

2.3 Self-Certifying Identifiers (aip:key:)

Self-certifying identifiers are for ephemeral agents. The identifier IS the public key. No resolution is needed; verification is immediate.

Format:

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

Example:

aip:key:ed25519:z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP

Requirements:

• The algorithm component MUST be ed25519 in v1.
• The multibase-key MUST use base58btc encoding (prefix z).
• The decoded key MUST be exactly 32 bytes (Ed25519 public key length).
• Implementations MUST NOT attempt DNS resolution for aip:key: identifiers.

3. Identity Document

An AIP identity document describes an agent's identity, public keys, delegation preferences, protocol support, and extensions.

3.1 JSON Schema

Identity documents MUST conform to the following structure:

{
  "aip": "1.0",
  "id": "aip:web:jamjet.dev/agents/research-analyst",
  "public_keys": [
    {
      "id": "key-1",
      "type": "Ed25519",
      "public_key_multibase": "z6Mkf5rGMoatrSj1f4CyvuHBeXJELe9RPdzo2PKGNCKVtZxP",
      "valid_from": "2026-03-01T00:00:00Z",
      "valid_until": "2026-06-01T00:00:00Z"
    }
  ],
  "name": "Research Analyst",
  "delegation": {
    "max_depth": 3,
    "allow_ephemeral_grants": true
  },
  "protocols": {
    "mcp": { "header": "X-AIP-Token" },
    "a2a": { "agent_card_field": "aip_identity" }
  },
  "revocation": {
    "endpoint": "https://jamjet.dev/.well-known/aip/revocations",
    "method": "crl"
  },
  "extensions": {
    "ldp": "aip:web:jamjet.dev/agents/research-analyst#ldp",
    "oauth": { "issuer": "https://auth.jamjet.dev", "client_id": "research-analyst" }
  },
  "document_signature": "<Ed25519 signature of canonical document by key-1>",
  "expires": "2026-06-22T00:00:00Z"
}

3.2 Field Definitions

3.3 Self-Certifying Identity Documents

For aip:key: identifiers, the identity document is self-constructed by the agent rather than fetched via DNS. The document MUST contain:

• aip: "1.0"
• id: the full aip:key:ed25519:<multibase-key> identifier
• public_keys: a single entry derived from the identifier itself
• document_signature: signed by the embedded key
• expires: REQUIRED

All other fields are OPTIONAL.

4. Self-Signature Mechanism

4.1 Canonicalization

Identity documents MUST be canonicalized using RFC 8785 JSON Canonicalization Scheme (JCS) before signing. JCS produces a deterministic byte representation by:

• Sorting all object keys lexicographically by Unicode code point.
• Using no whitespace between tokens.
• Applying deterministic number serialization.

4.2 Signing Process

• Construct the identity document with all fields populated EXCEPT document_signature.
• Serialize the document using RFC 8785 JCS canonicalization.
• Sign the canonical byte sequence using the Ed25519 private key corresponding to one of the listed public_keys.
• Set document_signature to the base64url-encoded (no padding) Ed25519 signature.

4.3 Verification Process

• Parse the identity document.
• Remove the document_signature field from the parsed object.
• Re-canonicalize the remaining fields using RFC 8785 JCS.
• Verify the document_signature against the canonical bytes using each public_keys entry whose valid_from <= current time <= valid_until.
• If any currently-valid key produces a successful verification, the document is authentic.

Requirements:

• Identity documents MUST include a document_signature field.
• Verifiers MUST check the document signature before trusting any fields in the document.
• If the signature does not verify against any currently-valid key, the document MUST be rejected.

4.4 Security Properties

The self-signature provides content authentication independent of transport security. Even if the hosting domain is compromised (DNS hijack, CDN compromise), an attacker cannot forge a valid identity document without the private key. HTTPS authenticates the transport; the signature authenticates the content.

5. Resolution Algorithm

5.1 aip:web: Resolution

To resolve a DNS-based AIP identifier:

• Parse the identifier to extract <domain> and <path>.
• Construct the resolution URL: https://<domain>/.well-known/aip/<path>.json
• Fetch the URL via HTTPS GET.
• Parse the response as JSON.
• Verify the aip version field (see Section 6).
• Verify the document_signature (see Section 4.3).
• Verify that expires is in the future.
• Verify that at least one key in public_keys is currently valid (valid_from <= now <= valid_until).
• Return the verified identity document.

Example:

Identifier: aip:web:jamjet.dev/agents/research-analyst

Resolves via:

GET https://jamjet.dev/.well-known/aip/agents/research-analyst.json

Requirements:

• Resolution MUST use HTTPS. HTTP MUST NOT be accepted.
• Implementations SHOULD cache resolved identity documents. Cache TTL SHOULD NOT exceed 5 minutes.
• If resolution fails (network error, non-200 status, invalid JSON, signature failure), the identifier MUST be treated as unresolvable.

5.2 aip:key: Resolution

Self-certifying identifiers require no network resolution:

• Parse the identifier to extract the algorithm and multibase-encoded public key.
• Decode the public key from multibase.
• Construct a minimal identity document with the extracted key.
• The identity is immediately usable for signature verification.

Requirements:

• Implementations MUST NOT perform any network request for aip:key: identifiers.
• The decoded public key MUST be validated (correct length for the algorithm).

6. Version Compatibility

6.1 Version Field

The aip field in identity documents uses a major.minor format (e.g., "1.0").

6.2 Rules

• Implementations MUST parse the aip field as a semver major.minor string.
• An implementation MUST reject documents with a higher major version than it supports.
• An implementation MAY accept documents with a higher minor version than it implements, provided the major version matches.
• Unknown fields in identity documents MUST be ignored (forward compatibility).
• This allows the spec to add optional fields in minor versions without breaking existing implementations.

7. Design Decisions

• Ed25519 only for v1. Fast, small signatures, widely supported. No algorithm negotiation complexity.
• Extensions field. LDP, OAuth, or any future protocol can link here without polluting the core schema.
• Expires field. Forces rotation. No permanent identities.
• Multiple keys with validity windows. Enables zero-downtime key rotation.
• Document self-signature. Protects against domain compromise. HTTPS authenticates the transport; the signature authenticates the content.

AIP Tokens: Compact and Chained Token Formats

Version: 0.1.0-draft

Status: Draft

Date: 2026-03-22

1. Introduction

This document defines the two AIP token formats -- compact mode (JWT wire format) and chained mode (Biscuit wire format) -- their structure, mode detection, claim mapping, budget semantics, policy profiles, and token size guidance.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. Token Modes Overview

AIP supports two token modes:

Both modes use the same transport mechanism: X-AIP-Token header or Authorization: AIP <token>.

3. Compact Mode (JWT Wire Format)

3.1 JWT Header

Compact mode tokens MUST use the following JWT header:

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

Requirements:

• The alg field MUST be "EdDSA" (Ed25519 signatures).
• The typ field MUST be "aip+jwt" to distinguish AIP tokens from other JWTs.

3.2 JWT Claims

The payload MUST include the following registered and private claims:

{
  "iss": "aip:web:jamjet.dev/agents/orchestrator",
  "sub": "aip:web:jamjet.dev/agents/research-analyst",
  "scope": ["tool:search", "tool:browse"],
  "budget_usd": 0.50,
  "max_depth": 0,
  "iat": 1711100000,
  "exp": 1711103600
}

3.3 Claim Definitions

Requirements:

• iss and sub MUST be valid AIP identifiers as defined in the AIP Core specification.
• scope MUST contain at least one entry.
• max_depth of 0 means the token holder MUST NOT delegate further. This is a constraint on the holder, not a counter of hops taken.
• exp SHOULD be set to a short duration. Compact mode tokens SHOULD have a lifetime of less than 1 hour.

4. Chained Mode (Biscuit Wire Format)

4.1 Overview

Chained mode uses the Biscuit token format: an append-only block chain where each block is signed with Ed25519. This enables multi-hop delegation with scope attenuation at each hop and provenance binding via completion blocks.

4.2 Block Structure

A chained mode token consists of an ordered sequence of blocks:

Block 0 (Authority) -- signed by the root identity (human or system):

Block 0 (Authority) -- signed by root (human/system)
  identity: aip:web:jamjet.dev/agents/orchestrator
  capabilities: [tool:*, delegate:*, budget:5.00]
  max_depth: 3
  expires: 2026-03-22T12:00:00Z

Block 1..N-1 (Delegation) -- each signed by the delegator:

Block 1 (Delegation) -- signed by orchestrator
  delegator: aip:web:jamjet.dev/agents/orchestrator
  delegate: aip:web:jamjet.dev/agents/research-analyst
  attenuate: [tool:search, tool:browse, budget:0.50]
  context: "research subtask for query X"

Block N (Completion) -- signed by the executing agent (see AIP Provenance specification):

Block N (Completion) -- signed by ephemeral sub-agent
  status: completed
  result_hash: sha256:abc123...
  verification_status: tool_verified
  tokens_used: 1200
  cost_usd: 0.03

4.3 Block 0 (Authority) Facts

Block 0 MUST contain the following Biscuit facts:

4.4 Delegation Block Facts

Each delegation block (Block 1..N-1) MUST contain:

Requirements:

• Each delegation block MUST be signed by the delegator.
• The context field MUST be non-empty. Verifiers MUST reject tokens with missing or empty context fields.
• Scope attenuation is enforced cryptographically: each block's capabilities MUST be a subset of the parent block's capabilities.

5. Mode Detection and Upgrade

5.1 Mode Detection

Receivers MUST detect the token mode by inspecting the token content:

• Compact mode: Token decodes as a JWT with header typ: "aip+jwt".
• Chained mode: Token begins with Biscuit magic bytes.

Implementations MUST support both detection methods.

5.2 Compact-to-Chained Mapping

When upgrading from compact to chained mode, the issuer creates a new chained token (Block 0) using the same key and equivalent claims. The compact JWT claims map to Biscuit authority facts as follows:

Requirements:

• Upgrade from compact to chained REQUIRES re-issuance. The original compact JWT is NOT embedded in the chained token.
• The new chained token MUST be signed by the same key that signed the compact JWT.
• All claims from the compact token MUST be faithfully represented in the chained token's Block 0 facts.

6. Budget Semantics

Budget fields (budget_usd in compact mode, budget facts in chained mode) represent per-token authorization limits, not running balances.

6.1 Enforcement Model

Budget is enforced by the delegator at delegation time and the verifier at invocation time, not tracked across invocations:

• At delegation time: When Agent A delegates to Agent B with budget:0.50, Agent A is asserting "I authorize B to spend up to $0.50 on this task." Agent A is responsible for partitioning its own budget across sub-delegations.
• At invocation time: The verifier (MCP server, A2A receiver) checks that the declared budget in the token is non-negative. It does NOT track cumulative spend.
• At completion time: The completion block records actual cost_usd spent. This is for audit, not enforcement.
• Aggregate enforcement is the responsibility of the runtime (e.g., an orchestration platform's cost tracking), not the token. AIP tokens authorize a ceiling; runtimes enforce the floor.

6.2 Analogy

This is analogous to a credit card authorization: the token says "authorized up to $X", the merchant checks the limit, but the bank (runtime) tracks the running balance.

6.3 Requirements

• Budget values in delegation blocks MUST be less than or equal to the parent block's budget.
• Verifiers MUST check that the declared budget is non-negative.
• Verifiers MUST NOT track cumulative spend across invocations using the token alone.
• Completion blocks SHOULD record actual cost_usd for audit purposes.

7. Policy Profiles (Chained Mode)

Datalog policies in chained mode blocks use one of three profiles. Policy profiles apply only to chained mode tokens.

7.1 Simple Profile

Templated rules requiring no Datalog knowledge. Users specify values and the library generates canonical Datalog. The canonical Datalog templates are normative: implementations MUST generate exactly these patterns.

Tool allowlist template:

check if tool($tool), ["search", "browse"].contains($tool);

Budget ceiling template:

check if budget($b), $b <= 0.50;

Delegation depth template:

check if depth($d), $d <= 3;

Time expiry template:

check if time($t), $t <= 2026-03-22T12:00:00Z;

Requirements:

• Implementations MUST generate exactly the canonical Datalog patterns shown above for Simple profile policies.
• The templates are fixed across implementations to ensure interoperability.
• Users specify configuration values (e.g., tools: [search, browse], budget: 0.50, max_depth: 3) and the library generates the canonical Datalog.

7.2 Standard Profile

Curated Datalog subset. No recursion. Bounded evaluation.

check if tool($tool), delegator($d),
  trust_domain($d, $domain),
  ["research", "internal"].contains($domain);

Requirements:

• Standard profile policies MUST NOT use recursive rules.
• Evaluation MUST be bounded.

7.3 Advanced Profile

Full Datalog for enterprise policies. Opt-in, with evaluation depth limits.

Requirements:

• Advanced profile is opt-in. Implementations MAY choose not to support it.
• Evaluation MUST be limited to a maximum of 1000 iterations.
• Implementations that support Advanced profile MUST enforce the iteration limit.

8. Token Size Considerations

8.1 Size Guidance

8.2 Token-by-Reference

For chains exceeding 4KB, implementations MAY use a token reference instead of inlining the full token:

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

Requirements:

• The reference URL MUST use HTTPS.
• The response at the reference URL MUST include the token's self-authenticating signature chain. No additional trust beyond the token's own signatures is required.
• Receivers MUST fetch and verify the full token from the reference URL before processing.

8.3 Recommended Chain Depth

The recommended maximum chain depth is 5 blocks (authority + 3 delegations + completion). This is a SHOULD, not a MUST. Implementations SHOULD warn when tokens approach this depth.

AIP Delegation and Lifecycle

Version: 0.1.0-draft

Status: Draft

Date: 2026-03-22

1. Introduction

This document defines AIP delegation rules, scope attenuation, bounded depth, delegation context requirements, ephemeral agent grants, key rotation, and revocation mechanisms.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. Scope Attenuation Rules

2.1 Fundamental Rule

Scope can only narrow, never widen. Each delegation block MUST represent a subset of the capabilities granted by its parent block. This is enforced cryptographically: each block is signed by the delegator, and the verifier checks attenuation at every hop.

2.2 Attenuation Dimensions

Attenuation applies along all capability dimensions:

2.3 Example

Block 0: tools:[*], budget:5.00, domains:[*]
  Block 1: tools:[search,browse], budget:0.50, domains:[research]
    Block 2: tools:[search], budget:0.10, domains:[research]

In this chain:

• Block 1 narrows tools from [] to [search, browse], budget from 5.00 to 0.50, and domains from [] to [research].
• Block 2 further narrows tools to [search] only and budget to 0.10.

2.4 Requirements

• Each delegation block MUST contain capabilities that are a subset of its parent block's capabilities.
• Attempting to widen scope (adding tools, increasing budget, expanding domains, extending expiration) MUST cause verification to fail.
• Verifiers MUST check attenuation at every hop in the delegation chain.
• A wildcard capability (*) in a parent block permits any specific capability in child blocks.
• A specific capability in a parent block MUST NOT be widened to a wildcard in a child block.

3. Bounded Depth

3.1 Depth Limit

Block 0 declares the maximum delegation chain depth via the max_depth field.

3.2 Default Depth

The default max_depth is 3. This means up to 3 delegation blocks may be appended after Block 0 (the authority block), for a total of 4 blocks before the optional completion block.

3.3 Compact Mode Depth

In compact mode, max_depth: 0 means the token holder MUST NOT delegate further. This is a constraint on the holder, not a counter of hops taken.

3.4 Requirements

• Block 0 MUST include a max_depth field.
• If max_depth is absent, implementations MUST use the default value of 3.
• Delegation beyond the declared max_depth MUST be rejected by verifiers.
• Each delegation block increments the effective depth by 1. The depth of Block N (where Block 0 has depth 0) is N.
• If the current depth equals max_depth, further delegation MUST NOT be permitted.

4. Delegation Context

4.1 Context Requirement

Each delegation block MUST include a non-empty context field describing why the delegation is happening. This is required for audit trail integrity.

4.2 Requirements

• The context field MUST be a non-empty string.
• Verifiers MUST reject tokens where any delegation block has a missing or empty context field.
• The context field SHOULD be a human-readable description of the delegation purpose (e.g., "research subtask for query X", "spawned for search subtask").
• The context field is not constrained to any particular format, but it MUST NOT be an empty string or whitespace-only string.

5. Ephemeral Agent Grants

5.1 Overview

When an agent spawns a short-lived sub-agent, it can issue an ephemeral grant using a self-certifying (aip:key:) identity for the sub-agent.

5.2 Grant Flow

• Parent agent generates an Ed25519 keypair for the sub-agent.
• Sub-agent's identity is aip:key:ed25519:<pubkey> (self-certifying, no DNS needed).
• Parent appends a delegation block with scoped capabilities and short TTL.
• Sub-agent uses the token for its work.
• Token auto-expires.

5.3 Ephemeral Grant Block

Block N (Ephemeral Grant) -- signed by parent
  delegate: aip:key:ed25519:z6Mkf...
  attenuate: [tool:search, budget:0.10]
  expires: 2026-03-22T10:05:00Z  (5 minutes)
  ephemeral: true
  context: "spawned for search subtask"

5.4 Requirements

• Ephemeral grants MUST delegate to an aip:key: identifier.
• Ephemeral grants SHOULD have short TTLs (5 minutes or less is RECOMMENDED).
• The ephemeral field MUST be set to true for ephemeral grants.
• All scope attenuation rules (Section 2) apply equally to ephemeral grants.
• The context field MUST be non-empty (Section 4).
• The parent agent's identity document delegation.allow_ephemeral_grants field, if set to false, MUST prevent ephemeral grants from being issued.

6. Key Rotation

6.1 DNS-Based Identities (aip:web:)

DNS-based identity documents support zero-downtime key rotation through multiple keys with validity windows.

Rotation procedure:

• Publish a new key in the identity document with a valid_from timestamp set to the desired activation time.
• Wait for propagation (identity document caches to expire).
• Both old and new keys are valid during the overlap window.
• After the old key's valid_until passes, it is no longer accepted for new token verification.
• Retire the old key by removing it from the identity document.

Requirements:

• Identity documents MAY list multiple keys with overlapping or adjacent validity windows.
• Tokens signed with any currently-valid key (where valid_from <= now <= valid_until) MUST be accepted.
• The recommended rotation period is 90 days.
• Implementations SHOULD cache identity documents with a maximum TTL of 5 minutes to ensure timely key rotation propagation.

6.2 Self-Certifying Identities (aip:key:)

For self-certifying identities, the key IS the identity. Rotation produces a new identity.

Requirements:

• Key rotation for aip:key: identifiers MUST be treated as identity replacement, not key update.
• This is acceptable because aip:key: identifiers are intended for ephemeral agents.
• Existing tokens signed by the old key remain valid until their expiration.

7. Revocation

7.1 General Stance

AIP prefers short-lived tokens over revocation infrastructure. This reduces operational complexity and avoids the latency and availability problems inherent in revocation checking.

7.2 Compact Mode

Compact mode tokens SHOULD have a lifetime of less than 1 hour. With short-lived tokens, revocation is generally unnecessary: the token will expire before revocation infrastructure could propagate the revocation.

7.3 Chained Mode

Chained mode supports two revocation mechanisms:

Key revocation:

• Remove the key from the identity document.
• All tokens signed by that key become unverifiable on next identity document fetch.
• Verifiers SHOULD cache identity documents with a maximum TTL of 5 minutes.

Token-specific revocation (optional):

• The identity document MAY include a revocation object with an HTTPS endpoint and method.
• The only supported method in v1 is "crl" (Certificate Revocation List).
• The CRL format is deferred to v2. Implementations SHOULD NOT depend on CRL availability in v1.

7.4 Requirements

• Compact mode tokens SHOULD have lifetimes of less than 1 hour.
• Verifiers SHOULD cache identity documents with a maximum TTL of 5 minutes to enable timely key revocation.
• Token-specific revocation via CRL is OPTIONAL in v1.
• The CRL format definition is deferred to v2. The revocation field in identity documents is reserved for forward compatibility.

AIP Provenance Bridge and Audit

Version: 0.1.0-draft

Status: Draft

Date: 2026-03-22

1. Introduction

This document defines AIP completion blocks, the trust model for completion data, integration with the Layered Disclosure Protocol (LDP), governance framework mapping, and the audit token concept.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. Completion Blocks

2.1 Overview

When work finishes, the executing agent appends a completion block to the token chain. Completion blocks bind the outcome of work back to the authorization chain that permitted it.

2.2 Completion Block Structure

A completion block contains 7 fields:

Block N (Completion) -- signed by executing agent
  status: "completed" | "failed" | "partial"
  result_hash: "sha256:e3b0c44298fc..."
  verification_status: "tool_verified"
  tokens_used: 1200
  cost_usd: 0.03
  duration_ms: 4500
  ldp_provenance_id: "ldp:provenance:uuid"  (optional)

2.3 Field Definitions

2.4 When Completion Blocks Are Required

Completion blocks are OPTIONAL by default. They are REQUIRED only when:

• The delegation policy includes require_provenance: true.
• The token will be used as audit evidence.
• LDP provenance bridging is active (see Section 4).

2.5 Requirements

• Completion blocks MUST be signed by the executing agent (the agent that performed the work).
• The status field MUST be one of the three defined values: "completed", "failed", or "partial".
• The result_hash MUST use SHA-256 and the format "sha256:<hex-digest>".
• The completion block MUST be appended as the final block in the token chain.
• Only one completion block is permitted per token chain (excluding verification and attestation blocks defined in Section 3).

3. Trust Model

3.1 Overview

Completion blocks are signed by the executing agent -- the party whose work is being reported. This means completion blocks are self-reported claims, not independently verified proofs. Their trust properties:

• Tamper-evident: The block is cryptographically signed. It cannot be modified after creation without detection.
• Attribution-bound: The signature proves which agent made the claim. A fraudulent claim is attributable.
• Not independently verified (by default): The executing agent could misrepresent result_hash or cost_usd.

3.2 Trust Levels

AIP defines three trust escalation levels for completion blocks:

Level 1: Self-Reported (Default)

The agent reports its own results. No independent verification.

• verification_status: implementation-defined (e.g., "self_reported" or "unverified")
• Sufficient for internal, trusted environments.
• No additional blocks required.

Level 2: Counter-Signed

The delegator (parent agent) independently verifies the result and appends a counter-signature block.

The counter-signature adds one block after the completion block:

Block N+1 (Verification) -- signed by delegator
  verified: true
  verifier: <delegator_aip_id>

• verification_status in the completion block: "tool_verified" or equivalent.
• The delegator has independently checked the result.

Level 3: Third-Party Attested

An external verifier (LDP peer verification, human reviewer, or audit service) signs an attestation block.

• The verification_status field maps to LDP's verification enum when LDP integration is active.
• "peer_verified": verified by an LDP peer.
• "human_verified": verified by a human reviewer.

3.3 Requirements

• Consumers of completion blocks SHOULD check the verification_status field and weight their trust accordingly.
• "tool_verified" or "peer_verified" completion blocks carry more weight than unverified self-reports.
• Counter-signature blocks (Level 2) MUST be signed by the delegator identified in the preceding delegation block.
• Third-party attestation blocks (Level 3) MUST include the attester's AIP identifier.

4. LDP Integration

4.1 Overview

When both AIP and the Layered Disclosure Protocol (LDP) are in use, they provide complementary guarantees:

• AIP: Authorization chain -- who was authorized, through which agents, with what scope.
• LDP: Provenance and quality evidence -- what was produced, how it was verified, what metadata accompanies it.

Neither protocol depends on the other. They are linked when both are present.

4.2 Bidirectional Linking

AIP to LDP (forward link):

The LDP provenance record includes an aip_token_hash field, binding "what was produced" to "who was authorized to produce it."

LDP to AIP (back-link):

The AIP completion block includes an ldp_provenance_id field, linking the authorization chain back to the full provenance record.

Together, the forward and back links create a bidirectional binding between authorization (AIP) and provenance (LDP).

4.3 Requirements

• When LDP integration is active, the AIP completion block SHOULD include the ldp_provenance_id field.
• When LDP integration is active, the LDP provenance record SHOULD include the aip_token_hash field.
• The aip_token_hash in LDP records MUST be the SHA-256 hash of the serialized AIP token (before the completion block is appended).
• The ldp_provenance_id MUST be a valid LDP provenance record identifier.
• Implementations MUST NOT require LDP to be present for AIP to function. LDP integration is OPTIONAL.

5. Governance Framework Mapping

AIP directly addresses common governance requirements for AI agent systems:

6. Audit Token

6.1 Concept

A completed chained token (with a completion block appended) is a self-contained audit artifact. It answers five key questions without requiring any external database:

Who authorized?     -> Block 0 (root identity + initial scope)
Through whom?       -> Blocks 1..N-1 (delegation chain with context)
What constraints?   -> Datalog policies in each block
What happened?      -> Completion block (result hash, cost, duration)
Was it verified?    -> verification_status + ldp_provenance_id link

6.2 Properties

• Self-contained: No central audit database is needed. The token itself is the evidence.
• Tamper-evident: Every block is cryptographically signed. Modification of any block invalidates the chain.
• Non-repudiable: Each signer's identity is bound to their block. Signers cannot deny their participation.
• Verifiable offline: Given the public keys (from identity documents), the entire chain can be verified without network access to any central authority.

6.3 Requirements

• Audit tokens MUST be complete chained mode tokens with at least Block 0 (authority) and one completion block.
• All blocks in an audit token MUST pass signature verification.
• All delegation blocks MUST have non-empty context fields.
• Implementations SHOULD provide tooling to render audit tokens in a human-readable format for forensic review.
• Audit tokens SHOULD be retained according to the organization's data retention policies.

AIP Binding: Model Context Protocol (MCP)

Version: 0.1.0-draft

Status: Draft

Date: 2026-03-22

1. Introduction

This document defines how AIP tokens are transported, verified, and enforced within the Model Context Protocol (MCP). It covers the token header, server-side verification steps, error response format, error codes, and the require_aip server capability.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. Token Transport

2.1 X-AIP-Token Header

AIP tokens MUST be transmitted in the X-AIP-Token HTTP header on MCP tool call requests.

POST /mcp/v1/tools/search
X-AIP-Token: <compact or chained token>
Content-Type: application/json

{"query": "latest research on agent identity"}

2.2 Token-by-Reference

For large tokens (exceeding 4KB), the client MAY use the X-AIP-Token-Ref header instead:

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

Requirements:

• Clients MUST send the AIP token in the X-AIP-Token header, or a reference URL in the X-AIP-Token-Ref header.
• If both X-AIP-Token and X-AIP-Token-Ref are present, the server MUST use X-AIP-Token and ignore X-AIP-Token-Ref.
• The X-AIP-Token-Ref URL MUST use HTTPS.
• Servers MUST fetch and fully verify the token from the reference URL before processing the request.

3. Server-Side Verification

When an MCP server receives a request with an AIP token, it MUST perform the following 5-step verification:

Step 1: Extract Token

Extract the token from the X-AIP-Token header. If the header is absent, check for X-AIP-Token-Ref and fetch the full token from the referenced URL.

If neither header is present and the server has require_aip: true, return error aip_token_missing.

Step 2: Verify Signatures

Verify the token's cryptographic signature(s) against the identity document resolved from the issuer identity (iss claim in compact mode, Block 0 identity fact in chained mode).

• For compact mode: verify the single JWT signature against the issuer's public key.
• For chained mode: verify the signature on every block against the respective signer's public key.

If signature verification fails, return error aip_signature_invalid.

If the issuer's identity document cannot be resolved, return error aip_identity_unresolvable.

Step 3: Check Policy

Determine whether the token authorizes the requested tool call:

• Check that the requested tool is included in the token's scope (compact) or right facts (chained).
• If the token does not authorize the operation, return error aip_scope_insufficient.

Step 4: Check Chain Constraints (Chained Mode)

For chained mode tokens, perform additional checks at each block in the chain:

• Delegation depth: Verify the chain does not exceed max_depth. If exceeded, return error aip_depth_exceeded.
• Budget ceiling: Verify the declared budget is non-negative. If the budget is insufficient for the declared operation cost, return error aip_budget_exceeded.
• Expiry: Verify that no block in the chain has expired. If any block has expired, return error aip_token_expired.
• Scope attenuation: Verify that each delegation block's capabilities are a subset of its parent block.
• Context: Verify that each delegation block has a non-empty context field.
• Key revocation: If the identity document includes a revocation endpoint, check whether any signing key has been revoked. If revoked, return error aip_key_revoked.

Step 5: Inject Verified Identity

Inject the verified identity information into the request context, making it available to the tool implementation. The tool implementation MAY use the identity for authorization decisions, logging, or audit.

4. Error Responses

4.1 Error Format

When AIP verification fails, MCP servers MUST return a structured error response:

{
  "error": {
    "code": "aip_<error_type>",
    "message": "Human-readable description"
  }
}

Requirements:

• The code field MUST be one of the defined AIP error codes (Section 4.2).
• The message field MUST contain a human-readable description of the error.
• The message field SHOULD provide enough detail for debugging without leaking sensitive information.

4.2 Error Codes

The following 9 error codes are defined:

4.3 HTTP Status Mapping

• HTTP 401 (Unauthorized) MUST be used for identity and authentication failures: aip_token_missing, aip_token_malformed, aip_signature_invalid, aip_identity_unresolvable, aip_token_expired, aip_key_revoked.
• HTTP 403 (Forbidden) MUST be used for authorization and scope failures: aip_scope_insufficient, aip_budget_exceeded, aip_depth_exceeded.

5. Server Capability: require_aip

5.1 Overview

MCP servers MAY declare AIP support and requirements in their identity document.

5.2 Identity Document Extension

{
  "aip": "1.0",
  "id": "aip:web:example.com/tools/search-api",
  "public_keys": [{"id": "key-1", "type": "Ed25519", "public_key_multibase": "z6Mk..."}],
  "protocols": {
    "mcp": {
      "require_aip": true,
      "minimum_policy_profile": "simple"
    }
  },
  "document_signature": "<signature>"
}

5.3 Fields

5.4 Requirements

• When require_aip is true, the server MUST return error aip_token_missing (HTTP 401) for any request that does not include a valid AIP token.
• When require_aip is false or absent, the server MAY accept anonymous requests but SHOULD still verify AIP tokens when present.
• When minimum_policy_profile is set, chained mode tokens MUST include policies at or above the specified profile level. Simple < Standard < Advanced.

AIP Binding: Agent-to-Agent Protocol (A2A)

Version: 0.1.0-draft

Status: Draft

Date: 2026-03-22

1. Introduction

This document defines how AIP tokens are transported, verified, and enforced within the Agent-to-Agent (A2A) protocol. It covers the agent card extension, token metadata field, and the 6-step verification flow.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. Agent Card Extension: aip_identity

2.1 Overview

A2A agents that support AIP MUST declare their AIP identity in their agent card using the aip_identity extension field.

2.2 Format

{
  "name": "Research Analyst",
  "skills": ["..."],
  "aip_identity": {
    "id": "aip:web:jamjet.dev/agents/research-analyst",
    "document_url": "https://jamjet.dev/.well-known/aip/agents/research-analyst.json"
  }
}

2.3 Field Definitions

2.4 Requirements

• A2A agents that support AIP MUST include the aip_identity field in their agent card.
• The aip_identity.id MUST be a valid AIP identifier.
• For aip:web: identifiers, aip_identity.document_url MUST be provided and MUST use HTTPS.
• For aip:key: identifiers, aip_identity.document_url is OPTIONAL (the public key is embedded in the identifier itself).

3. Token Transport: aip_token Metadata Field

3.1 Overview

AIP tokens are transmitted in A2A task submissions via the metadata.aip_token field.

3.2 Format

{
  "jsonrpc": "2.0",
  "method": "tasks/send",
  "params": {
    "task_id": "uuid",
    "message": {
      "role": "user",
      "parts": [{"text": "Research X"}]
    },
    "metadata": {
      "aip_token": "<chained token with delegation block appended>"
    }
  }
}

3.3 Requirements

• The AIP token MUST be placed in the metadata.aip_token field of the A2A task submission.
• The token SHOULD be a chained mode token with a delegation block appended for the receiving agent.
• Compact mode tokens MAY be used for single-hop A2A interactions.
• The metadata object MUST be preserved across A2A task forwarding.

4. Verification Flow

When an A2A agent receives a task with an AIP token, it MUST perform the following 6-step verification flow:

Step 1: Discover Agent Card

Agent A discovers Agent B's agent card, which includes the aip_identity extension.

If the agent card does not include aip_identity and the receiving agent requires AIP, the task MUST be rejected.

Step 2: Resolve Identity Document

Agent A resolves Agent B's AIP identity document using the document_url from the agent card (for aip:web: identifiers) or constructs it from the key (for aip:key: identifiers).

Agent A MUST verify the identity document's document_signature and confirm the document has not expired.

Step 3: Append Delegation Block

Agent A appends a delegation block to its token, attenuating scope for Agent B's task:

• The delegation block MUST contain a delegate fact with Agent B's AIP identifier.
• The delegation block MUST attenuate capabilities to only those needed for the delegated task.
• The delegation block MUST include a non-empty context field.
• The delegation block MUST be signed by Agent A's private key.

Step 4: Send Task with Token

Agent A sends the task to Agent B with the token (including the new delegation block) in the metadata.aip_token field.

Step 5: Verify Full Chain

Agent B verifies the full token chain:

• Root authority: Verify Block 0 signature and resolve the root identity.
• Delegation chain: For each delegation block (Block 1..N), verify:
• The block's signature against the delegator's public key.
• Scope attenuation (capabilities are a subset of the parent block).
• The context field is non-empty.
• The delegation depth does not exceed max_depth.
• Final delegation: Verify the last delegation block delegates to Agent B's own AIP identifier.
• Expiry: Verify no block in the chain has expired.
• Budget: Verify the declared budget is non-negative.

If any verification step fails, the task MUST be rejected with an appropriate error.

Step 6: Further Delegation (Optional)

Agent B MAY further delegate by appending another delegation block if max_depth allows. All scope attenuation rules apply. If the current chain depth equals max_depth, further delegation MUST NOT be permitted.

5. Error Handling

A2A agents SHOULD use the same error codes defined in the AIP MCP Binding specification (Section 4.2 of aip-bindings-mcp.md). Errors SHOULD be returned as A2A task error responses with the AIP error code included in the error metadata.

6. Mutual Authentication

A2A interactions support optional mutual authentication:

• Caller proves identity: Agent A includes an AIP token in the task submission.
• Receiver proves identity: Agent A resolves Agent B's identity document before sending and verifies TLS certificate matches the domain in Agent B's aip:web: identifier.

Mutual authentication for self-certifying identities (aip:key:) is deferred to v2 (requires a challenge-response sub-protocol).

Requirements:

• Caller-only authentication is the default.
• Mutual authentication is OPTIONAL and opt-in for high-security scenarios.
• When mutual authentication is used with aip:web: identifiers, the caller MUST verify the TLS certificate matches the domain before sending the task.

AIP Binding: HTTP / Mutual Authentication

Version: 0.1.0-draft

Status: Draft

Date: 2026-03-22

1. Introduction

This document defines the generic HTTP binding for AIP tokens, including the Authorization: AIP header, mutual authentication, and token-by-reference via the X-AIP-Token-Ref header. This binding applies to any HTTP-based API that is not covered by the MCP or A2A bindings.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

2. Authorization Header

2.1 Format

AIP tokens MUST be transmitted using the standard HTTP Authorization header with the AIP scheme:

GET /api/data
Authorization: AIP <token>

The <token> value is the base64url-encoded compact (JWT) or chained (Biscuit) token.

2.2 Scheme Registration

The AIP authorization scheme is used to identify AIP tokens in the Authorization header.

2.3 Compatibility

APIs that do not understand the AIP scheme will ignore the Authorization header or return a standard HTTP 401 response. APIs that support AIP can verify caller identity and scope from the token.

2.4 Requirements

• Clients MUST use the Authorization: AIP <token> format for generic HTTP API calls.
• The <token> MUST be a valid AIP token (compact or chained mode).
• Servers that support AIP MUST recognize the AIP scheme in the Authorization header.
• Servers that do not support AIP SHOULD ignore the AIP scheme gracefully (standard HTTP behavior).
• The Authorization: AIP header and the X-AIP-Token header (from the MCP binding) carry the same token format. The choice of header depends on the protocol context.

3. Token-by-Reference

3.1 X-AIP-Token-Ref Header

For tokens that exceed practical inline size limits (4KB recommended threshold), clients MAY use the X-AIP-Token-Ref header to provide a URL from which the server can fetch the full token:

GET /api/data
Authorization: AIP <token-reference-indicator>
X-AIP-Token-Ref: https://issuer.example/.well-known/aip/tokens/<token-id>

3.2 Requirements

• The X-AIP-Token-Ref URL MUST use HTTPS.
• The response at the reference URL MUST include the full, self-authenticating token (with its complete signature chain).
• No additional trust beyond the token's own cryptographic signatures is required to verify a token fetched by reference.
• If both Authorization: AIP <token> (with an inline token) and X-AIP-Token-Ref are present, the server MUST use the inline token and ignore the reference.
• Servers MUST fetch and fully verify the referenced token before processing the request.
• Servers SHOULD enforce a timeout on reference URL fetches (RECOMMENDED: 5 seconds).
• Servers SHOULD reject reference URLs that do not match expected domain patterns to prevent SSRF attacks.

4. Mutual Authentication

4.1 Overview

All AIP HTTP bindings support optional mutual authentication, where both the caller and receiver prove their identity.

4.2 Caller Authentication (Default)

The caller proves identity by including an AIP token in the request. This is the default mode for all AIP-enabled HTTP interactions.

4.3 Receiver Authentication

The caller verifies the receiver's identity before sending the request.

v1: DNS-based TLS only.

For receivers with aip:web: identifiers:

• The caller resolves the receiver's AIP identity document.
• The caller verifies the TLS certificate of the receiver's domain matches the domain in the receiver's AIP identifier.
• Standard HTTPS certificate validation provides receiver authentication.

This leverages existing PKI infrastructure. No additional challenge-response protocol is needed for DNS-based identities.

v2 (deferred): Self-certifying mutual authentication.

Mutual authentication for self-certifying identities (aip:key:) requires a challenge-response sub-protocol that is out of scope for v1. This will be defined in a future version of this specification.

4.4 Requirements

• Caller-only authentication (sending an AIP token) is the default. No additional configuration is required.
• Mutual authentication is OPTIONAL and opt-in for high-security scenarios.
• In v1, receiver authentication MUST use DNS-based TLS verification only.
• Implementations MUST NOT attempt mutual authentication with aip:key: identifiers in v1.
• When mutual authentication is active, the caller MUST resolve the receiver's identity document and verify the TLS certificate matches the domain BEFORE sending the request.

5. Verification

HTTP servers that support AIP SHOULD follow the same 5-step verification process defined in the AIP MCP Binding specification (Section 3 of aip-bindings-mcp.md):

• Extract token from Authorization: AIP header (or X-AIP-Token-Ref).
• Verify signature(s) against the resolved identity document.
• Check policy: does the token authorize this operation?
• If chained mode: check delegation depth, budget ceiling, expiry at each block.
• Inject verified identity into request context.

The same error codes and HTTP status mappings defined in the MCP binding (Section 4 of aip-bindings-mcp.md) apply to the generic HTTP binding.