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; v0.1 is the first published version.

RFCTitleStatus
RFC-AITP-0001Core — envelope, signatures, replay, error codesRelease Candidate
RFC-AITP-0002Identity BindingRelease Candidate
RFC-AITP-0003Agent ManifestRelease Candidate
RFC-AITP-0004Mutual HandshakeRelease Candidate
RFC-AITP-0005Trust Context TokenRelease Candidate
RFC-AITP-0006Single-Hop DelegationRelease Candidate
RFC-AITP-0007Key ResolutionRelease Candidate
RFC-AITP-0008RevocationRelease Candidate
RFC-AITP-0009Security & Threat ModelRelease Candidate
RFC-AITP-0010Session Trust BundleDraft (post-v0.1)
RFC-AITP-0011Multi-hop DelegationDraft (post-v0.1)
RFC-AITP-0012Extensions (ZK, TEE) — reservedReserved
RFC-AITP-0013TCT Renewal ExtensionPlanned

Reading order

The numbering matches dependency order. Read top-to-bottom:

  1. RFC-AITP-0001 Core — envelope, replay protection, signatures, error codes.
  2. RFC-AITP-0002 Identity — identity binding model and trust anchors.
  3. RFC-AITP-0003 Manifest — signed agent self-description.
  4. RFC-AITP-0004 Mutual Handshake — the four-message A2A handshake.
  5. RFC-AITP-0005 TCT — the canonical peer-issued Trust Context Token.
  6. RFC-AITP-0006 Delegation — single-hop delegation between peers.
  7. RFC-AITP-0007 Key Resolution — Manifest-first peer-key resolution and identity-issuer key resolution.
  8. RFC-AITP-0008 Revocation — JTI deny lists per issuing peer, key revocation.
  9. RFC-AITP-0009 Security — threat model and required defenses.

Post-v0.1 (Draft normative text published, NOT part of v0.1 conformance):

Reserved (no normative text, numbering pinned for future work):

Planned (RFC number reserved, no document yet):

RFC lifecycle

Draft → Review → Release Candidate → Final Comment Period → Accepted (or Rejected).

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.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.