Specification

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

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.

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) and re-progress through the lifecycle; the v0.1 line completed Release Candidate at 0.1.0-rc.3.

Document versions within a protocol revision may diverge: the Version: header tracks each RFC's own editorial history, not the protocol literal, which stays aitp/0.2 for all of them, and not the minor position, which is reserved for the protocol revision itself (see VERSIONING.md). RFC-AITP-0008 is at 0.2.6-draft; RFC-AITP-0001 is at 0.2.5-draft; RFC-AITP-0003 and RFC-AITP-0010 are at 0.2.4-draft; RFC-AITP-0002 and RFC-AITP-0004 are at 0.2.3-draft; and RFC-AITP-0005 is at 0.2.1-draft, after the JCS signing-input, session-bundle placement, extensions field-table, RFC-AITP-0011 wrapper-citation, §3.1 pinned-key timestamp, UNKNOWN_FIELD, structural-rejection code, and identity-descriptor mirror corrections (see CHANGELOG.md). RFC-AITP-0006, RFC-AITP-0007, RFC-AITP-0009 and RFC-AITP-0011 remain at 0.2.0-draft (the reserved and planned placeholders keep their own suffixes). Check the header of the document you are reading rather than assuming a shared version.

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.