Skip to content
Ratify Protocol

Glossary

A precise vocabulary matters for a protocol. This glossary defines every term used in the spec and SDKs.

A

Section titled “A”

A2A (agent-to-agent) — A pattern where one agent transacts with, hires, or sub-delegates to another agent without a human in the loop at the moment of the transaction.

Agent — An autonomous software entity acting on a principal’s behalf. Carries a hybrid keypair and a delegation chain.

AgentIdentity — A named agent: agent ID, public key, agent type. Distinct from the keypair itself.

Anchor — An out-of-protocol identity claim that a HumanRoot is tied to. Examples: an SSO identity, a domain-verified email, a government ID. Not normative; usable by upper layers.

B

Section titled “B”

Bundle — Short for ProofBundle. The signed object an agent presents to a verifier.

C

Section titled “C”

Canonical JSON — Ratify’s deterministic JSON serialization: sorted keys, no insignificant whitespace, fixed number formatting. Specified in SPEC.md §6.

Cert — Short for DelegationCert.

Challenge — 32 random bytes generated by a verifier and signed (with a timestamp) by the presenting agent. Defeats replay.

Chain — The ordered list of delegation certs in a ProofBundle. Chain depth 1 means one direct delegation (Alice → Agent-A); chain depth N means N sub-delegations.

Conformance suite — The 59 canonical fixtures in testvectors/v1/ that every SDK must pass byte-identically.

Constraint — A condition that must be satisfied at verify time on top of scope. Three families in v1: geo, temporal, version.

Custom scope — An application-specific scope outside the canonical 52. Prefix: custom:. Treated as opaque string by the verifier.

D

Section titled “D”

DEK (data encryption key) — In Verify’s custodial mode, the AES-256-GCM key that encrypts the principal’s private key at rest. The DEK itself is encrypted by a KEK in Cloud KMS.

Delegate — The verb: a principal signs a DelegationCert for a subject.

DelegationCert — The signed object binding issuer → subject with scope, constraints, expiry, and a hybrid signature.

DCO (Developer Certificate of Origin) — The lightweight contributor agreement Ratify uses instead of a CLA. Commits are signed off with git commit -s.

E

Section titled “E”

Ed25519 — The classical elliptic-curve signature scheme. RFC 8032. One half of every hybrid Ratify signature.

Effective scope — The intersection of every cert’s scope in a delegation chain. The presenter can only do what every link in the chain authorized.

F

Section titled “F”

FIPS 204 — NIST’s standardization of the Dilithium post-quantum signature algorithm, finalized August 2024. The published name is ML-DSA. Ratify uses ML-DSA-65.

Freshness — The challenge timestamp must be within a recent window (default 300 seconds) or the verifier rejects with identity_status: replay.

H

Section titled “H”

HumanRoot — A principal that is a human, identified by a hybrid keypair plus an Anchor.

Hybrid signature — A pair of signatures (Ed25519 + ML-DSA-65) over the same canonical bytes. Both must verify. This is Ratify’s quantum-safe defense.

I

Section titled “I”

IdentityStatus — The verifier’s verdict on a bundle. One of: valid, bad_signature, expired, scope_denied, revoked, replay, constraint_violation, malformed, revocation_unavailable.

Issuer — The party that signed a DelegationCert. For the first link in a chain, this is a HumanRoot (or another agent for full A2A chains).

K

Section titled “K”

KEK (key encryption key) — In Verify’s custodial mode, the Cloud KMS key that encrypts DEKs.

KeyRotationStatement — A signed object proving identity continuity from an old keypair to a new one. Both old and new keys sign. Used for self-custody upgrades and routine rotation.

M

Section titled “M”

ML-DSA-65 — Module-Lattice Digital Signature Algorithm, parameter set 65. The NIST-standardized form of CRYSTALS-Dilithium. FIPS 204. The other half of every hybrid Ratify signature.

P

Section titled “P”

Present — The verb: an agent assembles a ProofBundle and sends it to a verifier.

Principal — The party at the root of a delegation chain. Usually a HumanRoot; can also be an AgentIdentity for fully autonomous chains.

ProofBundle — What an agent presents. Contains the delegation chain plus a fresh challenge signature.

R

Section titled “R”

Ratify Protocol™ — The open cryptographic trust protocol. Spec under CC-BY-4.0, SDKs under Apache-2.0. Trademark of Identities AI, Inc.

Ratify Verify — Identities AI’s commercial managed-control-plane product on top of the open protocol. Closed-source.

RevocationList — A signed list of cert IDs the issuer has revoked. Verifier-cached with a short TTL.

S

Section titled “S”

Scope — A string naming an allowed action. Canonical vocabulary has 52 scopes + 14 wildcards + the custom: extension pattern.

Sensitive scope — A scope flagged as not eligible for wildcard expansion. Must be enumerated explicitly in a DelegationCert.scope.

Self-custody — Key custody mode where the principal holds their own private key. No third party can sign on their behalf.

Subject — The party named as the recipient in a DelegationCert. For sub-delegation, the subject of one cert is the issuer of the next cert in the chain.

T

Section titled “T”

Trust root — The first issuer in a delegation chain. A verifier must have the trust root’s public key available (or look it up via the embedded issuer_id).

V

Section titled “V”

Verify — The verb: a third party runs the verifier algorithm on a ProofBundle and gets a yes/no answer.

Verifier — The party running the verify algorithm. Examples: a Zoom meeting verifier (checking participants), an API gateway (checking incoming requests), a drone autopilot (checking commands).