01
Backend-owned
Revocation is controlled through backend authority pathways, not website text, badges, directories, or public presentation layers.
Revocation Policy
Revocation keeps public proof aligned with backend truth.
Resolver output must reflect current backend truth. A revoked, suspended, degraded, expired, mismatched, or unresolved state must not continue to look operational.
Policy purpose
Revocation prevents stale proof from being mistaken for current authority.
ECZ-ID is designed so identity and passport state can change without losing historical meaning. Revocation, suspension, expiry, downgrade, mismatch, and unresolved-state handling ensure public proof does not continue to imply reliance when backend state has changed.
02
Resolver-projected
Resolver must display current public state so relying parties can check before acting, integrating, paying, approving, or routing.
03
Time-bound
Historical state remains reconstructable while current reliance posture changes deterministically.
04
Machine-readable
Public state should be legible to humans, agents, platforms, and automated systems so checks can fail closed when required.
State outcomes
Public proof must distinguish current state from past evidence.
Revoked
The credential, passport, binding, or proof surface should no longer be treated as operational. Resolver must not present it as currently valid.
Suspended
Current reliance is paused. Suspension may preserve history while preventing present-tense operational reliance.
Degraded
The state remains visible, but current operational posture is reduced because a required condition is no longer fully met.
Expired
The relevant time window has passed. Resolver should make expiry clear rather than allowing stale reliance.
Mismatch
A binding, identifier, manifest, or referenced state no longer matches the expected canonical record.
Unresolved
The system cannot currently confirm the required public state. Relying parties should not treat unresolved as approved, active, verified, or safe to rely on.
What revocation preserves
History remains reconstructable.
Revocation does not erase the historical record. It changes present-tense public reliance posture while allowing prior authority and state to remain reconstructable where the underlying ledger and canonical records support that reconstruction.
What revocation prevents
Stale public proof must not keep operating.
A relying party should not have to infer revocation from missing pages, stale documents, private emails, or manual explanation. Resolver should expose the current public answer.
Machines, agents, platforms, and reviewers
Automated systems need revocation to be explicit, current, and easy to re-check.
Agents, MCP servers, platforms, procurement tools, insurers, auditors, and integration systems should not rely on stale website copy or copied badges. They should re-check current public state in Resolver and apply their own local policy.
For agents
Re-check Resolver before relying on a target, tool, provider, API, credential, or public proof surface.
For platforms
Treat revoked, expired, mismatched, degraded, or unresolved states as signals for review, routing, hold, or fail-closed handling under your own policy.
For developers
Use Developer Gateway for schemas, route indexes, manifest guidance, and safe integration patterns. Do not treat Developer Gateway as public proof.
Public reference path
Read policy here. Check current public state in Resolver.
Use this page to understand revocation 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, and implementation guidance.