aitp-rs

Rust reference implementation of the Agent Identity & Trust Protocol (AITP).

Status: v0.1.0 — Tracks AITP specification v0.1.0-rc.1. 44/44 conformance fixtures pass (37 core + 7 draft under feature flags). See docs/conformance.md for the per-fixture breakdown and CHANGELOG.md for the full history.

What is AITP?

AITP is a transport-agnostic, identity-agnostic trust protocol for agent-to-agent communication. Two agents establish bilateral trust without requiring a shared verifier, exchanging signed peer-issued Trust Context Tokens (TCTs) that name each peer as the audience and bind capabilities to the holder's key.

The protocol specification lives in the agentidentitytrustprotocol repository. This implementation tracks AITP v0.1.0.

Workspace layout

aitp-rs/
├── crates/
│   ├── aitp-core/           types, JCS, base64url, AID — pure, no I/O
│   ├── aitp-crypto/         Ed25519, JWK thumbprint, signature ops
│   ├── aitp-envelope/       envelope signing and verification — sync, no I/O
│   ├── aitp-manifest/       Manifest issuance and verification
│   ├── aitp-handshake/      Mutual handshake state machine
│   ├── aitp-tct/            TCT issuance and verification, PoP exchange
│   ├── aitp-delegation/     Single-hop delegation tokens
│   ├── aitp-session-bundle/ Session Trust Bundle (RFC-0010, opt-in draft)
│   ├── aitp-transport-http/ HTTP client/server (feature-gated, async)
│   ├── aitp/                facade re-exporting the protocol crates
│   ├── aitp-conformance/    conformance test runner with adapter trait
│   └── aitp-rs-adapter/     canonical Rust adapter for conformance testing
├── bindings/                language SDKs — excluded from the Cargo workspace
│   ├── aitp-py/             Python SDK (PyO3)
│   ├── aitp-node/           Node.js SDK (NAPI-rs)
│   └── interop/             cross-language interop tests — `make interop`
├── examples/
│   ├── two-agents/          standalone demo: two agents establishing trust
│   └── observability/       tracing / metrics integration example
├── tools/                   fixture- and example-minting binaries
├── adapters/                example conformance adapters in other languages
├── docs/                    implementation guides + design/ decision notes
└── scripts/                 build and release helpers

Status by crate

Language SDKs (bindings/)

Thin SDKs over the protocol crates: an AitpAgent plus initiator/responder session types whose methods exchange JSON strings (HTTP request/response bodies), so agent code never touches a Rust type. They are excluded from the Cargo workspace — cargo test --workspace does not build them. bindings/interop/ cross-checks the two SDKs against each other; see Cross-language interop below.

RFC compliance matrix

Known limitations (v0.1)

• Single-hop delegation only by default. Multi-hop chains (RFC-0011) are rejected unless the experimental-multihop-delegation feature is opted in. See conformance-matrix for fixture coverage.
• Session Trust Bundle is opt-in. N-party trust artifacts (RFC-0010, Draft) are gated behind the experimental-session-bundle Cargo feature on the aitp facade.
• JWKS resolution from a current-thread runtime. The synchronous JwksResolver::resolve sync→async bridge uses block_in_place, which requires a multi-thread tokio runtime; on a current-thread runtime resolve now fails closed with a descriptive error rather than panicking. Async callers should use AsyncJwksResolver::resolve_async (e.g. to pre-warm the resolver cache); pure-sync deployments rely on the pinned-issuer store.

Conformance matrix

The conformance runner reads fixture metadata (status, feature, required_for_v0_1) to decide which fixtures run in strict v0.1 vs. opt-in modes.

The 7 SKIPs in strict mode are the draft-tier fixtures (3 session bundle + 4 multi-hop delegation), all required_for_v0_1: false. The single SKIP in opt-in mode is del-004, which asserts the v0.1 strict rejection (DELEGATION_MULTIHOP_NOT_SUPPORTED) and is auto-skipped by the runner's negative-feature rule when multi-hop is opted in. See crates/aitp-conformance/src/runner/executor.rs:negated_by_feature.

The runner enforces a v0.1 conformance gate: a fixture marked required_for_v0_1 that fails — or is SKIPped because the adapter lacks the op — makes aitp-conformance run exit non-zero, so CI cannot regress required coverage to a silent SKIP. A full per-fixture breakdown is in docs/conformance.md.

Quick start

Run the two-agent demo (no external dependencies):

make demo

You should see the four-message handshake complete and an /echo capability invocation succeed. See examples/two-agents/README.md for the walkthrough.

Cross-language interop

make interop

Builds the Python and Node SDKs, then runs a real four-message AITP handshake between the two runtimes — in both directions — proving the two implementations emit wire-compatible envelopes. The Python side runs in-process under pytest; the Node side runs as a subprocess worker. See bindings/interop/README.md for the design.

Building

cargo build --workspace --all-targets --all-features
cargo test --workspace --all-features
cargo fmt --all -- --check
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo doc --workspace --no-deps --all-features

scripts/test.sh and make test both run the local CI gauntlet. CI runs the same checks plus cargo deny and cargo audit on Linux + macOS + Windows.

Documentation

docs/README.md is the index and the entry point. Highlights:

• docs/architecture.md — topology, crate map, and the workspace-split rationale
• docs/jcs.md — JSON canonicalization strategy and test vectors
• docs/conformance.md — NDJSON adapter protocol + the per-fixture matrix
• docs/handshake-transcripts.md — four-message exchange, byte by byte
• docs/session-bundle.md · docs/multihop-delegation.md · docs/tct-renewal.md — draft, opt-in extensions
• docs/sdk-python.md · docs/sdk-node.md — SDK feature guides
• docs/transport-hardening.md — HTTP-transport hardening register
• plans/defered/deferred.md — declined / out-of-scope items

The protocol itself is defined normatively by the AITP RFCs; docs here point to the relevant RFC section rather than restating it.

Roadmap

The original five-sprint bootstrap (alpha.1 through alpha.4) is complete. Subsequent hardening is summarized below; the transport-layer items are tracked in docs/transport-hardening.md:

• alpha.5 — Phases 1–9: pinned-key proof v1, identity type enforcement, PinnedKeyStore, grant policy hook, replay deny list, JwksFetcher hardening.
• beta.1 — Phases 10–16: key resolution policy, manifest cache correctness, revocation end-to-end, HTTP transport hardening, conformance fixture expansion, TCT renewal + facade.
• post-beta — RFC-0010 (Session Trust Bundle) and RFC-0011 (Multi-hop Delegation) once v0.1 soaks. Both have design prerequisites in the unified plan.

License

Dual-licensed under either of:

• Apache License, Version 2.0
• MIT License

at your option. See LICENSE-APACHE and LICENSE-MIT.