Backend-owned
Issuance is controlled through backend authority pathways. Websites, public copy, badges, and directory listings do not create authoritative state.
Issuance Policy
ECZ-ID issuance defines how a stable identifier or scoped passport state becomes available for public reference. Issuance is not a website claim, badge graphic, directory listing, marketplace entry, or marketing statement. It is a backend-owned authority event that Resolver can project as current public proof.
Policy purpose
ECZ-ID is designed so relying parties, platforms, auditors, insurers, agents, and automated systems do not need to infer identity or authority from copied text, outdated pages, private messages, screenshots, marketplace listings, directories, or non-authoritative badges. Issuance creates a canonical reference point that can be resolved and re-checked.
Issuance is controlled through backend authority pathways. Websites, public copy, badges, and directory listings do not create authoritative state.
Resolver is the public read-only surface for checking current authoritative public state before reliance.
Passports and scoped proof surfaces remain attached to the parent ECZ-ID identity spine. They do not create competing identity roots.
Issuance state should be legible to humans, agents, platforms, and automated systems so checks can be repeated without narrative interpretation.
What issuance creates
What issuance does not create
Authority sequence
Issuance requires the system to know what is being issued, who or what it is attached to, what authority pathway applies, and what current public state should be shown. This keeps ECZ-ID suitable for businesses, agents, APIs, platforms, products, machines, supply chains, and operating surfaces.
The subject must be distinguishable enough for a stable ECZ-ID or scoped passport state to be attached without relying on public marketing copy.
Authority must be scoped, attributable, and controlled through backend pathways before public state is projected.
Issuance creates a canonical reference point and lifecycle position that can later be inspected, changed, suspended, downgraded, expired, or revoked.
Resolver presents the current public answer. Relying parties should check Resolver rather than infer state from websites or copied material.
Machines, agents, platforms, and reviewers
Agents, MCP servers, platforms, procurement tools, insurers, auditors, reviewers, and integration systems should treat Resolver as the public proof surface. Developer Gateway can support schemas, route indexes, manifests, and implementation guidance, but it is not itself public proof.
Re-check Resolver before relying on an ECZ-ID, passport, tool, provider, API, credential, or proof surface.
Use current Resolver state as an input to your own review, routing, gating, hold, or fail-closed policy.
Use Developer Gateway for schemas, route indexes, manifest guidance, and safe integration patterns.
Public reference path
Use this page to understand issuance posture. Use Resolver to inspect current public proof. Use TrustOps for acquisition, activation, lifecycle control, and operational action. Use Developer Gateway for schemas, docs, manifests, route indexes, and implementation guidance.