Passport

What This Is

A working spec for the agent Passport layer. This builds directly on Phase 1 (Identity Layer) — read that spec first.

The Passport answers a different question than identity. Identity says who an agent is. Passport says what an agent can do — and critically, who vouches for it.

The Core Problem

An agent with a verified identity (AgentID) can prove it's itself. That's Phase 1. But in a multi-agent system, "who are you?" is only the first question. The second question — asked by every agent deciding whether to delegate work — is:

What can you actually do, and should I trust those claims?

Right now there's no standard way to answer that. Agents make informal capability claims in their system prompts, or through out-of-band documentation, or not at all. There's no machine-readable format, no attestation mechanism, and no way to verify claims against a trusted source.

This creates problems:

• No capability discovery — Agent B can't find Agent A based on what A can do
• No attestation — A's claim to handle HIPAA data is unverifiable
• No trust graduation — all agents are equally trusted (or untrusted); there's no gradation
• No expiry — a capability granted once is presumed forever
• No revocation — a compromised agent keeps its claimed capabilities

The Passport layer fixes this. It's the credential layer of the A2A infrastructure stack.

What Is an Agent Passport?

An Agent Passport is a signed, time-bounded document that attests: this identity has these capabilities, as verified by this issuer.

Key properties:

• Identity-anchored: always references a specific AgentID
• Attested: signed by a named issuer (operator, auditor, or self)
• Capability-scoped: explicit list of what the agent can do
• Time-bounded: expires_at timestamp; stale Passports are invalid
• Revocable: issuers can publish revocation records
• Composable: an agent may hold multiple Passports from different issuers

Passport Record Structure

{
  "id": "pass_01HZ...",
  "version": 1,
  "created_at": "2026-04-01T06:00:00Z",
  "expires_at": "2026-07-01T00:00:00Z",

  "subject": {
    "agent_id": "agnt_01HZ...",
    "fingerprint": "sha256:<hex>"
  },

  "issuer": {
    "type": "self | operator | third_party",
    "id": "string — issuer identifier",
    "name": "string — human-readable name",
    "public_key": "base64 Ed25519 public key",
    "fingerprint": "sha256:<hex>"
  },

  "capabilities": [
    {
      "token": "email:send",
      "label": "Send Email",
      "scope": "transactional_only",
      "constraints": {},
      "attested_at": "2026-04-01T06:00:00Z"
    }
  ],

  "attestation_context": {
    "method": "operator_assertion | automated_test | third_party_audit",
    "evidence_url": "optional link to evidence",
    "notes": "optional freeform"
  },

  "signature": "base64 — issuer signature over canonical JSON"
}

Capability Token Format

Capability tokens are structured strings:

<domain>:<action>[:<qualifier>]

Examples:

calendar:read
calendar:write
email:send
email:send:transactional_only
data:phi:access
data:phi:access:read_only
payment:process
agent:delegate
agent:spawn
tool:web_search
tool:code_execution
tool:file_read
tool:file_write

# Operator-namespaced custom tokens:
custom:acme_corp:crm_write

Token namespaces: calendar:, email:, data:, payment:, agent:, tool:, domain:, custom:<operator_id>:

Unknown tokens are treated as "not attested" — not errors. The canonical token list grows via RFC process.

Issuer Types and Trust

Issuer Type	Who Signs	Trust Level	Use Case
self	The agent itself	Low	Development, initial deployment
operator	The deploying operator	Medium	Production deployments, internal agent networks
third_party	Independent auditor or certification body	High	Regulated industries, public-facing networks

Trust policy is the peer's responsibility. The Passport layer provides the primitives; it doesn't make trust decisions for you.

Passport Operations

// Issue a Passport
issue_passport(
  subject_agent_id: AgentID,
  capabilities: CapabilityToken[],
  issuer_private_key: bytes,
  issuer_info: IssuerInfo,
  ttl_days: number
) → Passport

// Verify a Passport
verify_passport(passport: Passport) → {
  valid: boolean,
  expired: boolean,
  revoked: boolean,
  errors: string[]
}

// Check a specific capability
has_capability(
  passport: Passport,
  token: CapabilityToken,
  scope?: string
) → boolean

// Revoke a Passport (issuer only)
revoke_passport(
  passport_id: string,
  issuer_private_key: bytes,
  reason: string
) → RevocationRecord

// Export / Import
export_passport(passport: Passport) → string
import_passport(string) → Passport

Passport Lifecycle

[Issue] → [Active] → [Expired]
             ↓
         [Revoked]

Recommended TTLs: self-issued 30 days · operator 90 days · third-party 1 year.

Renewal creates a new Passport with a new ID. The old Passport remains valid until its own expiry.

Multiple Passports (Passport Bundle)

An agent may hold multiple Passports simultaneously — expected and by design. Peers receive a Passport bundle:

{
  "agent_id": "agnt_01HZ...",
  "passports": [ ...Passport[] ]
}

Helper: best_passport_for(capability, min_issuer_type) — returns the highest-trust Passport that attests the requested capability.

Connection to Phase 1 (Identity)

The Passport is built on the identity layer:

• The stable AgentID is the Passport's subject anchor
• The subject fingerprint binds the Passport to a specific public key
• verify_claim() from Phase 1 is used internally to check the issuer signature
• Canonical JSON format and pass_ ID prefix follow the same pattern as Phase 1

A Passport without an underlying AgentID is invalid. Without identity, there's nothing to attach a Passport to.

Connection to Phase 3 (Registry)

Phase 3 Registry adds discovery, publication, and distributed revocation. Phase 2 Passport format is designed to be Registry-compatible — in Phase 2, Passport exchange is out-of-band (file share, A2A, etc.). Phase 3 makes this automatic.

Open Questions