ECZ-ID Binding Registry™
Bind ECZ-ID passports and packages to real domains, agents, APIs, assets, documents, accounts, and counterparties — then prove only what Backend/Core has actually observed and Resolver can safely project.
What a binding is
A binding is a backend-controlled proof relationship between an ECZ-ID capability and a real-world or system target. Customer-provided records, manifests, API specs, or documents are setup artifacts. They are not proof until Backend/Core observes them, validates them, and Resolver projects the BOUND state.
Why bindings matter
- They turn an ECZ-ID from a string into machine-checkable proof tied to a specific real-world target.
- They give counterparties, agents, and platforms a single posture to verify before action.
- They make tamper-evident hashing and exact-ID Resolver checks possible at runtime.
- They let the relying party fail closed when state is unsafe, instead of guessing from screenshots.
Fast path
- Choose the binding type that matches the target (domain, agent, API, MCP, SBOM).
- Open TrustOps and start the setup pack for that binding.
- Publish the required setup artifact (DNS record, manifest, OpenAPI extension, SBOM reference).
- Backend/Core observes the evidence from its own infrastructure.
- Resolver projects BOUND once verification completes.
- Share the Resolver URL — never a screenshot — with the relying party.
Which binding do I need?
| Use case | Binding type |
|---|---|
| Prove control of a domain | Domain binding |
| Verify a logical agent before it acts | Agent binding |
| Verify an authorised API surface and spec hash | API binding |
| Gate high-risk MCP tool calls | MCP binding |
| Tie an SBOM to a release for procurement / DORA | SBOM binding |
| Ask a counterparty to obtain or prove a binding | Request-to-Resolve |
How the model works
Resolver is the public proof surface
No customer-supplied document, manifest, or upload becomes proof on Developer Gateway. Current state is confirmed in Resolver.
TrustOps owns acquisition and lifecycle
Acquisition, payment, setup packs, suspension, and lifecycle live in TrustOps. Developer Gateway routes there.
Resolver is public read-only proof
Current state for an exact ECZ-ID is checked in Resolver. There is no search, no directory, no setup, no checkout in Resolver.
Developer Gateway documents and routes
No checkout. No setup form that mutates verification state. No Resolver clone. No directory of ECZ-IDs.
Binding Registry documentation
Public reference for each binding type, the Request-to-Resolve workflow, the Resolver projection model, and the forbidden-claims governance.
What ECZ-ID does not claim
ECZ-ID is identity, authority, custody, and evidence-state proof. It is not the following terms, and Developer Gateway must not describe it that way:
Formal governance and specifications for issuance, revocation, authority, and binding semantics are published at ecocitizenz.org.