Specification
AITP RFC specifications
This directory contains the normative RFCs that define the Agent Identity & Trust Protocol (AITP). AITP is an agent-to-agent (A2A) trust protocol; the current revision is aitp/0.2 (v0.1 was the first published version — v0.2 is a breaking revision that re-serializes the portable trust artifacts as compact JWS and adds cryptographic agility; see RFC-AITP-0001 §1).
| RFC | Title | Status |
|---|---|---|
| RFC-AITP-0001 | Core — envelope, signatures, replay, error codes | v0.2 Draft |
| RFC-AITP-0002 | Identity Binding | v0.2 Draft |
| RFC-AITP-0003 | Agent Manifest | v0.2 Draft |
| RFC-AITP-0004 | Mutual Handshake | v0.2 Draft |
| RFC-AITP-0005 | Trust Context Token | v0.2 Draft |
| RFC-AITP-0006 | Single-Hop Delegation | v0.2 Draft |
| RFC-AITP-0007 | Key Resolution | v0.2 Draft |
| RFC-AITP-0008 | Revocation | v0.2 Draft |
| RFC-AITP-0009 | Security & Threat Model | v0.2 Draft |
| RFC-AITP-0010 | Session Trust Bundle | Draft (opt-in) |
| RFC-AITP-0011 | Multi-hop Delegation | Draft (opt-in) |
| RFC-AITP-0012 | Extensions (ZK, TEE) — reserved | Reserved |
| RFC-AITP-0013 | TCT Renewal Extension | Planned |
Reading order
The numbering matches dependency order. Read top-to-bottom:
- RFC-AITP-0001 Core — envelope, replay protection, signatures, error codes.
- RFC-AITP-0002 Identity — identity binding model and trust anchors.
- RFC-AITP-0003 Manifest — signed agent self-description.
- RFC-AITP-0004 Mutual Handshake — the four-message A2A handshake.
- RFC-AITP-0005 TCT — the canonical peer-issued Trust Context Token.
- RFC-AITP-0006 Delegation — single-hop delegation between peers.
- RFC-AITP-0007 Key Resolution — Manifest-first peer-key resolution and identity-issuer key resolution.
- RFC-AITP-0008 Revocation — JTI deny lists per issuing peer, key revocation.
- RFC-AITP-0009 Security — threat model and required defenses.
Opt-in (Draft normative text published, NOT part of v0.2 core conformance):
- RFC-AITP-0010 Session Trust Bundle — multi-agent session scaling.
- RFC-AITP-0011 Multi-hop Delegation — chains beyond a single hop.
Reserved (no normative text, numbering pinned for future work):
- RFC-AITP-0012 Extensions — ZK and TEE namespaces.
Planned (RFC number reserved, no document yet):
- RFC-AITP-0013 TCT Renewal Extension — standardization of the shortened renewal endpoint described non-normatively in RFC-AITP-0004 §8.1. A stub document exists; no normative text yet.
RFC lifecycle
Draft → Review → Release Candidate → Final Comment Period → Accepted (or Rejected).
The aitp/0.2 revision is a breaking change (compact-JWS trust artifacts, cryptographic agility), so RFCs 0001–0009 returned to Draft (shown as "v0.2 Draft" above, version 0.2.0-draft) and re-progress through the lifecycle; the v0.1 line completed Release Candidate at 0.1.0-rc.3.
Release Candidate is the editorial stage after Review and before FCP: the RFC text is substantively complete, the version carries an rc.N suffix (e.g. 0.2.0-rc.1; the v0.1 line reached 0.1.0-rc.3), and further changes are limited to clarifications, KAT vectors, and conformance fixtures. RC can iterate (rc.1, rc.2, …) as implementer feedback surfaces issues. Promotion to FCP requires all required KAT vectors present, the conformance fixture set complete for the RFC's normative surfaces, and at least one implementation passing the core conformance tier. See governance/RFC-PROCESS.md for the full stage definitions.