Trust Center
Everything on this page is either a fact about the shipped protocol, a fact about what is not yet complete, or a link to the primary source. Nothing here is marketing language standing in for a technical claim.
Protocol
AgenID v1.1.1 is the current locked specification, published and MIT-licensed at AgenID-protocol/spec. Two errata are on record — a key-identifier URI fix and a number-domain canonicalization rule (E1), and the namespace unification onto a single agenid.com domain (E2). Any future change to identity, cryptography, serialization, or verification semantics requires a published erratum before any implementation follows it; the spec is the source of truth, not the code.
Cryptography
Manifests and assertions are canonicalized with RFC 8785 JSON Canonicalization Scheme (JCS) before signing — the signing input is the JCS bytes of the signed object minus its signature field, and the $schema field is part of what’s signed.
Signatures are pure Ed25519 (RFC 8032) over those canonical bytes directly — no Ed25519ph, no external pre-hash step. The only SHA-256 in the protocol produces the manifest_digest data value, which the signature binds; SHA-256 is never itself the signed input.
The §8.7 number-domain rule rejects non-finite values and rejects integer-literal canonical tokens with magnitude greater than 2⁵³−1 — documented as a rejection case, never as a silently-accepted edge case.
Key Management
Every key has its own ULID. A key’s role is exactly operator or authority — an operator key can never produce a valid VerificationAssertion, and an authority key can never produce a valid ManifestProof. That separation is enforced at verification time, not by convention.
Retired or revoked keys stay resolvable forever — a revoked key’s history is never deleted.
Verification Methodology
Verification is a distinct, signed act — a VerificationAssertion, made by an authority key, bound to one specific manifest digest and evidence type. It is never inferred from an operator’s own declaration.
- L1_REGISTERED — schema_validation. Issuable.
- L2_DOMAIN_VERIFIED — dns_txt_challenge / http_wellknown_challenge. Issuable.
- L3_ORGANIZATION_VERIFIED — business_registry_match / document_review. Issuable.
- L4_DEPLOYMENT_VERIFIED — deployment_conformance via deployment_sample_review. Issuable, but the sampling methodology itself is still being finalized — see below.
- L5_CONTINUOUSLY_MONITORED — a reserved name only. No continuous-integrity claim exists in v1.1.1; it cannot be issued.
A VERIFIED claim is scoped to exactly what its evidence type checked. It is never a general safety, behavioral, or legal guarantee — verification is not compliance.
Root Authority Key — Current Status
Not yet complete. The production root authority key has not completed its HSM ceremony. The verification mechanism for trust anchors — two-path key discovery, key roles, revocation — is fully specified and testable today (spec §9.5). What has not happened yet is the operational step of generating and ceremonially sealing the actual production root key. This is disclosed here rather than implied to be finished, and this page will be updated the day it is.
The L4 deployment_sample_review methodology and the CI sync step between the spec repository and this site’s mirrored schemas/docs are also open items, tracked internally and not yet resolved.
Open Source & Conformance
The protocol specification is public and MIT-licensed: AgenID-protocol/spec. The independent conformance suite is also public and MIT-licensed: AgenID-protocol/conformance — it never imports @agenid/core or calls AgenID’s own registry, and currently passes 34 of 34 checks in CI on every push.
Privacy
A registered manifest’s declared fields (identity, operator, purpose, disclosure) are public by design — that is what makes independent verification possible. AgenID does not publish a directory of registered agents for open discovery yet; resolution is by identifier, not by browsing.