AITP Glossary
Terms used across AITP RFCs, schemas, and registries. The authoritative definitions live in the RFC sections referenced from each entry; this glossary is a non-normative quick reference.
Concept Index
A one-line "what is X / where is it defined" lookup for the core AITP concepts. For longer definitions, scroll to the alphabetical section below.
| Concept | One-line definition | Authoritative location |
|---|---|---|
| AID | Cryptographic agent identifier (aid:pubkey:<43-char base64url>). | RFC-AITP-0001 §5.3 |
| Envelope | Outer signed object every AITP message ships in. | RFC-AITP-0001 §5 |
| JCS signing input | Canonical JSON form (RFC 8785) used as the signing input. | RFC-AITP-0001 §5.4.1 |
| Replay protection | message_id deduplication + timestamp tolerance window. | RFC-AITP-0001 §5.5 |
| Identity binding | How an AID is bound to a verifiable claim from a trusted issuer. | RFC-AITP-0002 |
| OIDC identity | JWT proof with aud (verifying peer's AID) and cnf.jkt (AID key thumbprint). | RFC-AITP-0002 §2 |
| Pinned-key identity | Signature over (sender, receiver, message_id, timestamp, pop_nonce). | RFC-AITP-0002 §3.1 |
| Manifest | Signed self-description served at /.well-known/aitp-manifest. | RFC-AITP-0003 |
identity_hint | Static issuer/subject metadata in the Manifest (no JWT). | RFC-AITP-0003 §3 |
| Mutual Handshake | Four-message peer authentication producing two TCTs. | RFC-AITP-0004 |
| Grant intersection | TCT grants are requested_grants ∩ identity_policy ∩ offered_capabilities. | RFC-AITP-0004 §4.1 |
| TCT | Signed, audience-bound, capability-scoped peer-issued grant. | RFC-AITP-0005 |
binding.cnf | Subject's public key embedded in the TCT for downstream PoP. | RFC-AITP-0005 §6 |
| JTI | UUID v4 token ID on a TCT; key for revocation lookups. | RFC-AITP-0005 §2 |
| Delegation | Single-hop subset grant (A → B → C) with embedded grant_proof. | RFC-AITP-0006 |
| Key resolution | Manifest-first for peers; cache → pinned → well-known for issuers. | RFC-AITP-0007 |
| Revocation | Per-issuing-peer JTI deny lists, pull-based. | RFC-AITP-0008 |
extensions | Reserved field for future extension namespaces (zk, tee). | RFC-AITP-0012 |
| PoP | Proof-of-Possession: signature over a fresh nonce by the holder's private key. | RFC-AITP-0003 §6, RFC-AITP-0005 §6 |
| Trust anchor | Locally configured trusted issuer (or pinned key) used to verify peers. | RFC-AITP-0002 §4 |
A
A2A (Agent-to-Agent). The trust model AITP defines: two autonomous agents establish bilateral trust without a central verifier. There is no service-consumer profile in v0.1. See RFC-AITP-0001 §1.
AID (Agent Identifier). The canonical, public identifier of an agent. v0.1 form: aid:pubkey:<43-char base64url>, where the trailing 43 characters are the unpadded base64url encoding of a 32-byte raw Ed25519 public key. SPKI DER and PEM are not permitted in v0.1. See RFC-AITP-0001 §5.3.
Audience. The peer a TCT is bound to. The audience peer is the only one who can present the TCT for the capabilities it carries. See RFC-AITP-0005 §3.
B
Binding. The binding object on a TCT (and on the inline TCT carried in MUTUAL_COMMIT). Holds the confirmation key (cnf) used for proof-of-possession when a downstream consumer verifies the holder. REQUIRED on every v0.1 peer-issued TCT.
C
Capability. An opaque string identifying an action a peer is willing to grant or accept. AITP does not define what a capability means — that is owned by the namespace prefix (e.g. macp.*, aitp.handshake.v1). See RFC-AITP-0005 §4.2.1.
cnf (Confirmation Key). A peer's public key embedded in binding.cnf so a downstream verifier can challenge the TCT holder. v0.1 form is the same 43-char base64url encoding used by AIDs. See RFC-AITP-0002 §2.2.1.
Conformance fixture. A JSON file under schemas/conformance/ describing a scenario, its input, and the expected outcome. Implementations MUST produce the specified outcome for each fixture they support.
Core Team. The body responsible for shepherding RFCs and cutting releases. See governance/CHARTER.md.
D
Delegation. v0.1 single-hop: a peer that holds a TCT can issue a delegation token granting a strict subset of its capabilities to a third peer. The grant is verified against a grant_proof minimized projection of the source TCT. Multi-hop chains are specified in RFC-AITP-0011 (Draft, post-v0.1) and are not part of v0.1 conformance.
E
Envelope. The outer signed object every AITP message ships in. Carries version, message_type, message_id, timestamp, sender, payload, and signature. See RFC-AITP-0001 §5.
Extensions. The optional extensions namespace on protocol payloads. v0.1 reserves extensions.zk and extensions.tee for future normative use. See RFC-AITP-0012.
G
Grant. One of the strings in a TCT's grants array. See Capability.
grant_proof. A minimized projection of the source TCT carried inside a delegation token. Lets a verifier check that the delegator's claimed authority comes from a real, signed TCT without redistributing the full TCT. See RFC-AITP-0006 §3.1.
I
Identity binding. The mechanism by which an AID is associated with an external identity claim (OIDC token, pinned key, …). Pluggable. See RFC-AITP-0002.
identity_hint. Static identity metadata in the Manifest (type, subject, issuer). Not a verifiable proof — the verifiable identity proof is exchanged inline in the Mutual Handshake.
Issuer. For a TCT: the peer that signed it. For an OIDC identity: the OpenID Provider that minted the JWT.
J
JCS (RFC 8785, JSON Canonicalization Scheme). The canonical JSON form used as the signing input across all v0.1 signed objects (envelope, Manifest, TCT, delegation token, revocation snapshot). See RFC-AITP-0001 §5.4.1.
jkt (JWK SHA-256 thumbprint). RFC 7638 thumbprint of the agent's confirmation key, computed over the exact JWK form {"crv":"Ed25519","kty":"OKP","x":"<aid-id>"}.
jti (JWT ID). The unique identifier of a TCT. Used as the key for revocation lookups in the issuing peer's deny list.
K
Key resolution. How a peer obtains another peer's signing key. Manifest-first for peer keys; cache → pinned → well-known for identity-issuer keys. See RFC-AITP-0007.
M
Manifest. The signed self-description an agent publishes at /.well-known/aitp-manifest. The discovery layer of AITP. See RFC-AITP-0003.
message_id. The per-message UUID used for replay deduplication on the receiving peer. See RFC-AITP-0001 §5.5.
Mutual Handshake. The four-message peer authentication that produces two TCTs (one in each direction). See RFC-AITP-0004.
P
Peer. Either party in an A2A interaction. AITP has no asymmetric roles — every peer is both an issuer and an audience.
PoP (Proof-of-Possession). A signature over a fresh, server-supplied or handshake-bound nonce that proves the presenter holds the private key matching a public key (e.g. the Manifest's AID, or a TCT's cnf). See RFC-AITP-0003 §6, RFC-AITP-0005 §6.
#pop_required. The RECOMMENDED v0.1 convention for marking a TCT grant that requires downstream PoP: a grant string of the form <capability>#pop_required signals that a consumer MUST run the pop_challenge / pop_response exchange before authorizing the grant. Deployments MAY use a different marking scheme if both peers agree out-of-band. See RFC-AITP-0005 §6.
pop_nonce. The per-handshake challenge used to bind PoP signatures to a specific exchange. Echoed back in pop_nonce_echo to prevent cross-handshake replay.
R
Revocation. Per-issuing-peer JTI deny lists. Each agent maintains the deny list for the TCTs it issued; verifiers consult the list belonging to the TCT's issuer. See RFC-AITP-0008.
RFC. A normative document under rfcs/. AITP RFCs are numbered RFC-AITP-NNNN. See governance/RFC-PROCESS.md for the lifecycle.
S
Scope. A delegation token's scope array — the strict subset of the source TCT's capabilities the delegator is conveying.
Subject. For a TCT: the peer the grant is about. In v0.1 the subject equals the audience (the holder is the subject of the receipt).
T
TCT (Trust Context Token). The canonical AITP artifact: a signed, audience-bound, capability-scoped grant produced by a peer. Verified locally — no third-party lookup. See RFC-AITP-0005.
Trust anchor. An identity-issuer URL (or pinned key reference) a peer is willing to accept. Listed in a Manifest's accepted_trust_anchors. The intersection across two Manifests determines whether a handshake is even worth attempting.
V
Verifier. AITP has no dedicated verifier role. Every peer is its own verifier for the peer it is authenticating. Avoid the term in normative text; use receiver or peer instead.