Issuance Policy

Issuance is resolver-first. Authority must exist before public state is shown.

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

Issuance prevents identity from being inferred from presentation.

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.

01

Backend-owned

Issuance is controlled through backend authority pathways. Websites, public copy, badges, and directory listings do not create authoritative state.

02

Resolver-projected

Resolver is the public read-only surface for checking current authoritative public state before reliance.

03

Parent-bound

Passports and scoped proof surfaces remain attached to the parent ECZ-ID identity spine. They do not create competing identity roots.

04

Machine-readable

Issuance state should be legible to humans, agents, platforms, and automated systems so checks can be repeated without narrative interpretation.

What issuance creates

A stable public reference point.

  • A canonical ECZ-ID or scoped passport state that can be resolved.
  • A public proof surface that can be checked by humans and systems.
  • A time-bound reference point for authority, state, and lifecycle history.
  • A machine-readable path for integration, audit, procurement, and review.

What issuance does not create

  • It does not certify business quality.
  • It does not guarantee compliance, safety, performance, or outcomes.
  • It does not replace regulators, auditors, insurers, courts, or institutional decision-makers.
  • It does not make a website, badge, marketplace listing, or directory entry authoritative.

Authority sequence

Authority first. Issuance second. Resolver projection third.

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.

01

Identify the subject

The subject must be distinguishable enough for a stable ECZ-ID or scoped passport state to be attached without relying on public marketing copy.

02

Check authority

Authority must be scoped, attributable, and controlled through backend pathways before public state is projected.

03

Record issuance

Issuance creates a canonical reference point and lifecycle position that can later be inspected, changed, suspended, downgraded, expired, or revoked.

04

Project public proof

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

Automated systems should re-check issuance state, not trust stale presentation.

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.

For agents

Re-check Resolver before relying on an ECZ-ID, passport, tool, provider, API, credential, or proof surface.

For platforms

Use current Resolver state as an input to your own review, routing, gating, hold, or fail-closed policy.

For developers

Use Developer Gateway for schemas, route indexes, manifest guidance, and safe integration patterns.

Public reference path

Read policy here. Check current public state in Resolver.

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.