Verification

Verification Model

ECZ-ID verification is not a one-time check. It’s a continuous, attestable process that ensures every entity maintains its verified status throughout its lifecycle.

Core Model

How Verification Works

The ECZ-ID verification model has three layers: identity provisioning, real-time verification, and continuous attestation.

1

Identity Provisioning

Every entity starts with identity provisioning through TrustOps. The entity receives a unique ECZ-ID, capability attestations, operational boundaries, and initial trust score. This is the foundation upon which all verification builds.

2

Real-Time Verification

Any party can verify an entity’s identity through Resolver in real time. Verification checks the entity’s current identity status, trust score, active attestations, and operational validity. This is the runtime trust layer.

3

Continuous Attestation

Verification doesn’t stop after initial provisioning. ECZ-ID continuously updates attestations based on entity behaviour, compliance status, and external signals. Trust scores evolve. Attestations are refreshed. Anomalies trigger review.

Verification Flow

A typical verification interaction between two entities.

1
Entity A Presents Identity
Entity A includes its ECZ-ID credentials in the interaction request.
2
Entity B Queries Resolver
Entity B sends the ECZ-ID to Resolver for real-time verification.
3
Resolver Returns Attestation
Resolver returns current identity status, trust score, capabilities, and active attestations.
4
Entity B Makes Trust Decision
Based on verified attestations, Entity B decides whether to proceed with the interaction.
5
Interaction Logged
The verified interaction is logged with provenance linking both entities' identities.
Trust Score

Understanding Trust Scores

Trust scores are dynamic, verifiable measures of an entity's trustworthiness. They're computed, not self-declared.

Identity Completeness

How complete and current the entity's identity record is. More attestations, higher completeness.

Behavioural History

Track record of the entity's actions and interactions. Consistent, verified behaviour builds trust.

Attestation Currency

Are attestations current? Expired or stale attestations reduce trust scores.

Anomaly Status

Has the entity triggered any anomaly flags? Unresolved anomalies reduce trust scores.

Principles

Verification Principles

Verified, Not Assumed

No identity claim is accepted without verification. Every assertion is checkable through Resolver.

Continuous, Not Static

Verification is ongoing. Trust scores update. Attestations refresh. Status evolves with behaviour.

Transparent, Not Opaque

Verification results are structured, documented, and auditable. No black boxes.

Decoupled, Not Siloed

TrustOps provisions. Resolver verifies. They're independent. No single point of failure.

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.

Authority Separation

Three Surfaces, Clear Responsibilities

Understanding which surface does what is essential to the ECZ-ID verification model.

🏗️ GitHub 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 authority plane. Customer acquisition starts at /start.

Role: Provisioning, pricing, credentialing

🔍 Resolver

Proves. Public verification, trust score queries, attestation checks, and provenance tracing. No account required. Any party can verify any ECZ-ID independently.

Role: Verification, proof, public trust checks

System Overview

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.

25 Packages

17 core + 1 KYA Ready Pack™ + 7 advanced infrastructure services. Commercial acquisition paths for child passports.

ECZ-ID Insurability Readiness™

Derived add-on on parent passport. Auto-computed from trust posture. 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. Trust scores evolve over time.

See Verification in Action

Verify any ECZ-ID through Resolver, or provision new identities through TrustOps.