Verification Model
ECZ-ID verification is not a one-time check. It’s a continuous, evidence-backed process that ensures every entity maintains its resolver-verifiable state throughout its lifecycle.
How Verification Works
The ECZ-ID verification model has three layers: identity provisioning, current-state verification, and ongoing evidence-state updates.
Identity Provisioning
Every entity starts with identity provisioning through TrustOps. The entity receives a unique ECZ-ID, capability evidence records, operational boundaries, and initial resolver-verifiable state. This is the foundation upon which all verification builds.
Current-State Verification
Any party can check an entity's identity through Resolver. Resolver returns the identity status, active evidence records, and operational validity that are current at the time of the request. Re-check before reliance — this is the runtime trust layer.
Evidence-State Updates
Verification doesn't stop after initial provisioning. Resolver state changes when deterministic inputs change: identity state, entitlement, binding state, evidence freshness, and lifecycle events recorded by ECZ-ID core systems. Expired evidence and lifecycle changes are reflected with deterministic reason codes.
Verification Flow
A typical verification interaction between two entities.
Understanding Resolver State
Resolver state reflects dynamic, verifiable evidence about an entity. It is computed from deterministic ECZ-ID Core records — not self-declared.
Identity State
The entity's canonical identity record and tier, as controlled by ECZ-ID core systems. Rule-based, not scored.
Entitlement & Binding
Which credentials are active and what they are bound to. Binding state is decisive and deterministic.
Evidence Freshness
Are evidence records current? Expired or stale records change resolver state with deterministic reason codes.
Lifecycle State
Suspension, revocation, expiry, and renewal events recorded by ECZ-ID core systems are reflected directly in resolver state.
Verification Principles
Resolver-Verified, Not Assumed
No identity claim is accepted without Resolver checks. Every assertion is checkable through Resolver.
Continuous, Not Static
Verification is ongoing. Evidence state updates. Records refresh. Status changes when deterministic inputs change — not with subjective behaviour scores.
Transparent, Not Opaque
Verification results are structured, documented, and auditable, with deterministic reason codes. No black boxes.
Decoupled, Not Siloed
TrustOps handles setup. ECZ-ID core systems control state. Resolver projects public proof. Each surface has one job, and a relying party fails closed if Resolver is unavailable.
Standard, Not Proprietary
ECZ-ID aligns with emerging standards for machine identity, digital product passports, and trust frameworks.
Sovereign, Not Dependent
Organisations control their identity infrastructure. ECZ-ID enables sovereignty, not dependency.
Three Surfaces, Clear Responsibilities
Understanding which surface does what is essential to the ECZ-ID verification model.
🏗️ Developer Gateway (This Site)
Explains. Discovery, onboarding guidance, starter kits, build scaffolds, and documentation. This site helps you understand and start—it does not provision, price, or verify.
Role: Persuasion, education, build guidance
⚡ TrustOps
Provisions. All identity provisioning, credential management, pricing, sales, checkout, and credential lifecycle management. TrustOps is the commercial and operational control surface. Customer acquisition starts at /start.
Role: Provisioning, pricing, credentialing
🔍 Resolver
Proves. Public read-only resolver-state queries, evidence-record checks, and provenance tracing. No account required. Any party can verify any ECZ-ID independently.
Role: Verification, proof, public trust checks
Formal governance and specifications — issuance, revocation, authority, and specification material — are published at ecocitizenz.org. Governance defines the rules; this site documents how to implement against them.
The Complete ECZ-ID Identity System
How passports, packages, badges, and verification fit together.
ECZ-ID Business Passport™
Parent passport. Root credential for every organisation. All child passports and derived add-ons attach to this.
7 Families / 33 Child Passports
Organised into 7 canonical categories covering digital systems, product/risk/transfer, robotics, road mobility, drones, infrastructure, and control overlays.
33 Packages
18 core bundles (includes KYA Ready Pack™) + 8 advanced / accelerator packages (includes ECZ-ID Digital Counterparty Infrastructure Pack™) + 7 extension packages (DORA, SBOM, Trade Finance, Construction). Commercial acquisition paths for child passports.
ECZ-ID Insurability Readiness™
Derived add-on on parent passport. Auto-computed from active passport state, evidence state, and canonical ECZ-ID Core rules. Not a package. Not purchasable.
Badges & Public Proof
After verification, entities receive resolver-verifiable badges. These are public proof URLs anyone can check.
Deployment & Lifecycle
After credentialing and verification, entities deploy to production. Credentials travel with the entity. Evidence state and resolver state evolve over time.
See Verification in Action
Verify any ECZ-ID through Resolver, or provision new identities through TrustOps.