Design Goals

1. Portability: One identity credential valid across all supported protocols.
2. Verifiability: Every action produces a cryptographically signed receipt.
3. Policy enforcement: Declarative rules evaluated before every action.
4. Federation: External identity providers (OIDC) accepted natively.
5. Minimal footprint: Zero external dependencies in the SDK.

Terminology

Agent Passport

A structured credential identifying an AI agent across protocols.

Receipt

A signed record of an action (create, revoke, translate, etc.).

Binding

Protocol-specific authentication configuration within a passport.

Capability

A declared ability of an agent (e.g., booking, support).

Policy Rule

A declarative constraint evaluated before an action is permitted.

Tier

The lifetime class of a passport: permanent, session, or ephemeral.

URN Scheme

Agent passports MUST use the following hierarchical URN scheme:

urn:aib:agent:{org_slug}:{agent_slug}

Where:

• org_slug: Lowercase alphanumeric organization identifier (2-64 characters, hyphens allowed).
• agent_slug: Lowercase alphanumeric agent identifier (1-64 characters, hyphens and underscores allowed). MUST match the pattern ^[a-z0-9][a-z0-9-_]{0,62}[a-z0-9]$.

Organization issuers MUST follow:

urn:aib:org:{org_slug}

Passport Object

A conforming Agent Passport is a JSON object with the following structure:

{
  "passport_id": "urn:aib:agent:myorg:booking-bot",
  "display_name": "myorg/booking-bot",
  "issuer": "urn:aib:org:myorg",
  "capabilities": ["booking", "scheduling"],
  "protocols": ["mcp", "a2a"],
  "protocol_bindings": {
    "mcp": { "auth_method": "oauth2" },
    "a2a": { "auth_method": "bearer" }
  },
  "tier": "permanent",
  "status": "active",
  "version": 1,
  "issued_at": "2026-03-28T10:00:00Z",
  "expires_at": "2027-03-28T10:00:00Z",
  "metadata": {}
}
      

Required Fields

Protocol Bindings

Each entry in protocol_bindings maps a protocol to its auth configuration:

Tiers

Supported Translation Paths

Translation Semantics

• skills (A2A) → tools (MCP): Each skill becomes a tool with an auto-generated inputSchema.
• tools (MCP) → skills (A2A): Each tool becomes a skill with id = tool name.
• capabilities (AG-UI) → skills/tools: Each capability string becomes a skill or tool.

Translated credentials MUST include the following metadata fields:

• _aib_source: The original format identifier.
• _aib_translated_at: ISO 8601 timestamp of translation.

Receipt Format

Every action MUST produce a Receipt:

{
  "passport_id": "urn:aib:agent:myorg:bot",
  "action": "create",
  "status": "success",
  "receipt_hash": "a1b2c3d4e5f6...",
  "signature": "ed25519hex...",
  "signed_by": "publickeyhex...",
  "created_at": "2026-03-28T10:00:00Z"
}
      

Hash Chain

Each receipt's receipt_hash MUST be computed as:

SHA-256("{action}|{passport_id}|{timestamp}")

This creates a tamper-evident chain — modifying any receipt invalidates subsequent hashes.

Ed25519 Signatures

Receipts MUST be signed using Ed25519 ([[RFC8032]]). The signing key SHOULD be persistent across server restarts. The public key MUST be stored in the signed_by field of each receipt for independent verification.

Denied Actions

Policy violations MUST also generate signed receipts with status: "denied", the error code in error_code, and violation details in metadata.violations.

Rule Types

Conforming implementations MUST support the following 12 policy rule types:

Severity Levels

Each policy rule MUST have a severity level:

block

Action is denied. A signed denial receipt is emitted.

warn

Action proceeds. Violation is recorded in receipt metadata.

log

Action proceeds. Violation is counted in rule hit statistics.

Evaluation Order

All active rules MUST be evaluated for every action. If any rule with block severity produces a violation, the action MUST be denied. Violations from warn and log rules SHOULD be included in the response metadata.

Verification Flow

Conforming implementations MUST perform the following steps when processing an OIDC token:

1. Extract the JWT payload from the Bearer token.
2. Look up the iss (issuer) claim in the federation trust registry.
3. Verify exp (expiration) is in the future.
4. If an expected audience is configured, verify the aud claim matches.
5. Fetch the JWKS from the issuer's jwks_uri.
6. Verify the JWT signature using the appropriate algorithm (RS256, RS384, or RS512).
7. If valid, create or authenticate the identity linked to the OIDC subject.

Supported Algorithms

Conforming implementations MUST support RS256 and SHOULD support RS384 and RS512 (RSASSA-PKCS1-v1_5).

JWKS Caching

JWKS responses SHOULD be cached for at least 1 hour per issuer URI to minimize network overhead.

Event Types

Conforming implementations SHOULD support the following webhook events:

Payload Format

{
  "event": "passport.created",
  "timestamp": "2026-03-28T10:00:00Z",
  "data": {
    "passport_id": "urn:aib:agent:myorg:bot",
    "protocols": ["mcp", "a2a"],
    "capabilities": ["booking"]
  }
}
      

Signature

When a webhook has a secret configured, the payload body MUST be signed with HMAC-SHA256. The hex-encoded signature MUST be sent in the X-AIB-Signature HTTP header.