> For the complete documentation index, see [llms.txt](https://docs.therisk.global/organization/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.therisk.global/organization/standardization/nexus-sovereignty/v.-verifiable-credentials/revocation-infrastructure.md).

# Revocation Infrastructure

## Revocation Infrastructure in the Nexus Sovereignty Framework: Credential Status Control, Sparse Merkle Revocation, Signed Revocation Lists, Revocation Credentials, ZK Status Proofs, and Audit-Bound Trust Correction

### Why Revocation Is Essential in a Zero-Trust Credential System

Revocation is essential because no credential should be trusted forever. In the Nexus Sovereignty Framework, Verifiable Credentials may authorize humans, institutions, machines, AI agents, TEE nodes, simulation models, credential issuers, public-safe reviewers, Project SPV evidence rooms, community stewards, data providers, and governance actors to perform actions inside a zero-trust execution environment. A credential may allow a person to submit disaster evidence, a node to sign CACs, a model to support embedded simulation, an issuer to create credentials, an AI agent to use tools, a public-safe reviewer to approve publication, or an enterprise evidence room to handle controlled Project SPV records. If that credential becomes false, stale, misused, compromised, exceeded, superseded, disputed, or legally overridden, the system must be able to invalidate it in a way that is machine-readable, cryptographically verifiable, jurisdictionally scoped, and audit-preserving.

A credential that cannot be revoked is not a trust instrument. It is a permanent risk. It can continue granting access after authority ends. It can allow compromised keys to sign actions. It can permit revoked nodes to generate CACs. It can allow outdated simulation models to keep influencing clauses. It can allow AI agents to retain tool permissions after a safety incident. It can allow credentials issued under false data to remain in circulation. It can allow cross-jurisdictional recognition after local conditions change. It can allow Project SPV evidence roles to persist after contract termination. It can allow finance-readiness or insurance-readiness evidence credentials to remain active after the underlying evidence is corrected.

Revocation is therefore not an administrative afterthought. It is the correction mechanism of the Credential Layer. It is how NSF preserves zero-trust integrity over time. Credentials can be issued, but issuance is only safe if status can change. Trust must be continuously verifiable, not assumed from a past signature.

At the same time, revocation must be boundary-safe and procedurally disciplined. Revocation is not destruction of history. It is not always punishment. It is not always proof of wrongdoing. It may reflect expiry, supersession, key rotation, changed eligibility, jurisdictional override, model deprecation, safety restriction, dispute status, or correction. Some credentials should be revoked immediately, such as compromised machine keys. Some should be suspended pending review, such as disputed human operational credentials. Some should expire naturally. Some should be restricted rather than revoked. Some should be superseded by a newer credential. Some may require issuer due process or competent authority.

The core doctrine is:

**Every NSF credential that can authorize material action must have a verifiable status mechanism, a defined revocation authority, a correction path, and an audit trail. A credential that cannot be checked, suspended, expired, superseded, or revoked within its scope should not be used for high-consequence execution.**

### Revocation Is Governance Correction, Not Erasure

Revocation should not be understood as deleting a credential from history. NSF is built on validity-by-record and correctionability. A revoked credential remains historically meaningful. It may have been valid at the time it was used. Its prior signatures may still be inspectable. Its lifecycle remains part of the audit trail. Revocation changes current and future reliance. It does not erase past events.

This distinction matters for disputes and audit. If a DisasterReliefOperatorVC was active on January 5 and revoked on February 1, a CAC signed on January 20 may remain valid for historical review, while future actions after February 1 fail. If the credential was revoked because the original issuance was fraudulent, historical reliance may require correction. If a TEEExecutorVC was suspended because of a vulnerability discovered later, CACs produced during the affected vulnerability window may be flagged under review. If a SimulationModelVC is deprecated, past simulation runs may remain historical evidence while new executions are blocked.

Revocation is therefore a status transition, not a memory deletion. The system must preserve the credential record, revocation reason, revoker authority, effective time, affected scope, dispute path, and downstream impacts.

### Revocation Models in NSF

NSF supports multiple revocation models because different credential types require different latency, privacy, scalability, and governance properties.

A **status-list model** uses a registry or status list to indicate whether a credential is active, suspended, revoked, expired, or otherwise restricted. This is useful for general-purpose verification and wallet interoperability.

A **Sparse Merkle Tree model** supports scalable cryptographic status proofs. It allows verifiers to check credential status through inclusion or non-inclusion proofs against a signed root. It is efficient for high-volume systems and ZK circuits.

A **Credential Revocation List model** publishes signed lists of revoked credentials. It is useful for human-readable audit, legacy systems, local trust infrastructures, and simple deployments.

A **Revocation Credential model** issues a signed credential-like object that records revocation, suspension, restriction, or supersession of another credential. It is useful when revocation itself requires governance evidence, chain-of-command tracing, or dispute review.

A **ZK revocation model** allows a holder or verifier to prove that a credential is not revoked without revealing full identity or credential details. This is important for privacy-preserving credentials.

A **event-driven revocation model** links revocation to CACs, safe-mode events, simulation status changes, node compromise events, public-safe violations, or governance decisions.

A **time-based expiry model** uses expiration dates, renewal intervals, inactivity limits, or model supersession to invalidate credentials automatically.

A **jurisdictional revocation model** restricts credential validity in one jurisdiction without invalidating it globally. This is critical for cross-border recognition.

A **cascade revocation model** invalidates dependent credentials if an issuer, schema, model, node, key, or root credential is revoked.

These methods can be combined. A machine credential may use SMT status for fast checks, CRLs for human-readable audit, and Revocation Credentials for governance events. A privacy-preserving human credential may use ZK non-revocation proofs. A Project SPV evidence credential may use controlled registry status and CAC-linked revocation events. A public-safe reviewer credential may use short expiry plus status registry.

Revocation is not one mechanism. It is a layered status architecture.

### Sparse Merkle Tree Revocation Infrastructure

Sparse Merkle Trees, or SMTs, provide a scalable way to represent credential status. In a typical model, each credential ID, credential hash, subject commitment, or status key maps to a leaf. The leaf records status, such as active, revoked, suspended, expired, restricted, or superseded. The SMT root commits to the status of the entire credential universe for a registry epoch.

A simplified mapping may be:

```
leaf_key = H(credential_id)
leaf_value = H(status || effective_time || reason_code || status_epoch)
root = SMT(leaf_key -> leaf_value)
```

A verifier can check credential status by verifying a Merkle inclusion proof or non-revocation proof against the signed root. The root is signed by the status authority, issuer, registry, governance body, or validator set. The root is then anchored in the Audit Layer, national registry, credential registry, rollup, or optional public commitment.

SMT revocation supports stateless checks. A verifier does not need to download an entire revocation list. It can verify a branch proof. This is useful for high-throughput clause execution, edge verification, AI agent runtime checks, TEE environments, CAC generation, and credential presentation.

SMTs are also ZK-friendly. A ZK circuit can verify that a credential leaf has active status under a known root without revealing credential ID. This supports privacy-preserving credential use.

An SMT root should include an epoch or validity window. A verifier must know whether the root is fresh enough for the action. A high-risk credential may require a recent root. A low-risk credential may allow cached roots. Offline execution may allow cached roots under degraded-mode rules.

The SMT model is powerful because it makes revocation scalable without making every credential public.

### Credential Revocation Lists

Credential Revocation Lists, or CRLs, are signed lists of revoked credential identifiers. They are simpler than SMTs and useful where human readability, compatibility, or local infrastructure matters.

A CRL may include credential ID, credential hash, revocation time, revoker DID, reason code, jurisdiction, scope, effective period, dispute status, and issuer signature. It may also include a Merkle root for compact verification.

A mature CRL entry may look like:

```json
{
  "revoked_credentials": [
    {
      "vc_id": "DisasterReliefOperatorVC#0x9823",
      "vc_hash": "0x...",
      "status": "SUSPENDED",
      "effective_at": "2025-04-30T19:15:00Z",
      "revoked_by": "did:nsf:org:RegionalHumanitarianCredentialIssuer",
      "reason_code": "jurisdictional-authority-misuse-allegation",
      "scope": "affected-jurisdiction-only",
      "review_required": true,
      "audit_record": "audit-0x..."
    }
  ],
  "issuer_signature": "0xDEADBEEF",
  "merkle_root": "0xabc123"
}
```

The seed uses `UNDRR-GovDAO`. Unless there is an authorized UNDRR governance process, examples should use generic or Nexus-governed issuer names. CRLs must avoid implying official revocation by treaty or UN bodies unless such authority exists.

CRLs serve human-readable audit logs, lightweight local trust systems, pre-ZK infrastructures, offline verification, and transitional interoperability. They may be published to DID Document service endpoints, credential status endpoints, national registries, enterprise evidence rooms, or audit archives.

CRLs are less privacy-preserving than ZK or accumulator-based methods if credential IDs are public. They should be used carefully for sensitive credentials.

### Revocation Credentials and Cascading Trust Events

Revocation can itself be represented as a credential-like artifact. A Revocation Credential or Revocation Record states that a specific credential, credential class, issuer, key, node, model, schema, or registry status has changed. It identifies the target, reason, authority, effective time, binding clause, evidence, and dispute route.

A Revocation Credential may look like:

```json
{
  "type": ["VerifiableCredential", "RevocationRecord"],
  "target_vc": "CredentialIssuerVC#0x8881",
  "target_hash": "0x...",
  "revoked_by": "did:nsf:org:CredentialGovernanceRegistry",
  "reason_code": "simulation-audit-policy-noncompliance",
  "binding_clause": "NSFRef::CredentialGovernance::RevocationReviewClause@2.0",
  "supporting_cac": "cac-0x...",
  "status": "SUSPENDED_PENDING_REVIEW",
  "effective_at": "2025-04-30T19:20:00Z",
  "revocation_signature": "0xABCDEF"
}
```

This allows revocation to be governed, not arbitrary. The Revocation Credential can show which clause or governance process supported the status change. It can link to CAC evidence. It can define whether the action is revocation, suspension, restriction, supersession, or dispute. It can specify appeal or restoration paths.

Revocation Credentials are especially useful for cascading trust events. If a CredentialIssuerVC is revoked, all credentials issued by that issuer may need review. If a SimulationValidatorVC is suspended, model credentials it approved may be flagged. If a TEEExecutorVC is revoked, CACs signed after revocation must be rejected and prior CACs in the compromise window may be reviewed. If a root key is rotated, dependent signatures must be checked. If a schema is deprecated, credentials under old schemas may become historical-only.

Cascade rules must be explicit. Not every issuer suspension invalidates all historical credentials. The status may be active, under review, historical-valid, future-blocked, or revoked depending on evidence.

Revocation Credentials make trust chain changes auditable.

### Revocation Registries and Governance Control

Each credential ecosystem needs a status authority. In NSF, this may be a credential issuer, national registry, regional registry, community steward body, enterprise evidence room, public-safe governance body, simulation registry, node registry, or credential governance registry. DAO tooling may support governance, but the authority should be described as a credentialed governance or registry function rather than assumed DAO control.

A revocation registry may operate SMT roots, status lists, CRLs, accumulator states, or ZK-compatible status roots. It should publish status roots on a defined cadence, such as real-time, hourly, daily, weekly, or monthly depending on risk. High-risk machine credentials may require near-real-time status. Low-risk standing records may update less frequently.

Roots may be anchored to the Audit Layer, national archive, sovereign registry, enterprise evidence room, community registry, or public chain commitment. Public anchoring should not reveal sensitive credential IDs.

Revocation authority may be delegated. An issuer may delegate emergency suspension to a security function. A community steward body may delegate public-safe suspension to a local review panel. A node registry may automate revocation after failed attestation. A Project SPV evidence room may suspend access credentials after contract termination. Delegation must be credentialed, scoped, time-bound, and audit-linked.

Reinstatement should also be governed. A reinstatement board, issuer review, credential governance body, or dispute process may restore status after correction. The seed says “rollback powers,” but NSF should avoid implying erasure. The safer term is **restoration**, **status correction**, **supersession**, or **reinstatement**, with history preserved.

Revocation registries make status a live governance function.

### Credential Expiry and Dynamic Invalidation

Not every credential needs active revocation. Many should expire automatically. Expiry reduces risk by limiting how long a credential can authorize action without renewal.

Credentials should include `valid_from` and `expires`. They may also include renewal conditions, inactivity limits, event-based invalidation, model-dependency invalidation, attestation-dependency invalidation, jurisdictional review requirements, or training requirements.

A credential may require renewal every 90 days. A TEEExecutorVC may require re-attestation every 24 hours or after runtime update. A SimulationModelVC may expire at the next model review cycle. A PublicSafeReviewerVC may expire after training validity ends. An AI-AgentToolUseVC may expire when model version changes. A ProjectSPVEvidenceRoomVC may expire when contract or access window ends. A credential may self-invalidate if not used within a period, if its issuer credential expires, if its bound clause is superseded, or if its linked simulation model is replaced.

Execution environments must automatically reject expired credentials. They must also check whether a credential is invalid due to supersession. A credential can be within date range but invalid because its schema was revoked, issuer suspended, clause binding superseded, model quarantined, or jurisdictional recognition withdrawn.

Dynamic invalidation is essential for living policy systems.

### Proof-of-Revocation and ZK Compatibility

NSF revocation proofs should be ZK-compatible. In privacy-preserving systems, a credential holder should be able to prove that their credential is not revoked without revealing the credential ID, subject identity, or full credential history.

An SMT branch can be embedded in a SNARK or STARK circuit. The circuit can prove that the credential status leaf under a signed root is active. It may also prove that the credential is within validity period, issuer is recognized, and jurisdictional scope matches. Selective disclosure can reveal only required fields.

A ZK non-revocation proof may include root hash, nullifier, status proof, credential type, jurisdiction commitment, and proof timestamp. The verifier checks proof against a known revocation root. The subject remains private where appropriate.

ZK revocation prevents reuse of revoked credentials in private workflows. It prevents double-spending of credential rights when credentials authorize one-time actions. It prevents bypassing jurisdictional constraints when the circuit includes scope. It allows AI agents, TEEs, and cross-border verifiers to validate status without overexposure.

But ZK proof scope must remain clear. A non-revocation proof proves that the credential was not revoked under a root and circuit. It does not prove that the credential holder is morally trustworthy, legally compliant, or authorized beyond the credential’s scope.

### Revocation Audit Trails

Every material revocation action must trigger an Audit Layer event. The audit event should include credential ID or commitment, credential hash, credential type, subject DID or protected commitment, issuer DID, revoker DID, revocation authority credential, status transition, reason code, effective time, jurisdiction, binding clause if clause-triggered, supporting CAC, proof of revocation, status root, dispute policy, public-safe disclosure class, and downstream impact.

A revocation event should be queryable by authorized actors. Example queries include:

`Find all revoked SimulationModelVCs in jurisdiction = KEN between 2024-12-01 and 2025-03-01.`

`Verify credential status: ReliefCredential#0x9319f1.`

`List all credentials suspended due to node did:nsf:tee-node:27 after attestation failure.`

`Find all ProjectSPVEvidenceRoomVCs expired in Q2-2025.`

`List all AI-AgentToolUseVCs revoked after model quarantine.`

`Find all credentials issued by CredentialIssuerVC#0x8881 after issuer suspension.`

Audit queries must respect privacy. Public users may see aggregate status. Issuers may see details. National nodes may see domestic credentials. Community stewards may control community credential records. Enterprise evidence rooms may restrict Project SPV records. ZK proofs may support verification without disclosure.

Revocation audit trails make trust changes inspectable.

### Revocation and CAC Linkage

Revocation should be linked to CACs wherever a Smart Clause or execution event supports the status change. A revoked credential should reference the CAC that triggered revocation, suspension, restriction, or review. A CAC should record which credential status it affected. The Credential Registry should index both directions.

For example, if an AI agent violates tool policy, a ToolUseViolationClause may generate a CAC. That CAC supports suspension of AI-AgentToolUseVC. The credential status record references the CAC. The CAC output references the credential. The Audit Layer links both.

If a simulation model fails drift checks, a ModelDriftReviewClause generates a CAC. That CAC supports restriction of ForecastModelVC. Dependent clauses and credentials are flagged.

If a Project SPV evidence room detects invalid asset telemetry, an evidence clause generates a CAC. That CAC supports marking ProjectReadinessEvidenceVC under review, not finance rejection.

CAC-linked revocation ensures that status changes are evidence-bound rather than arbitrary.

### Revocation and Public-Safe Claims

Revocation status must be communicated carefully. A public revocation notice can be misunderstood as legal wrongdoing, regulatory violation, public authority sanction, fraud finding, safety certification failure, finance denial, insurance denial, or official disciplinary action. NSF should distinguish status states and reason codes.

Public-safe status labels may include expired, suspended, under review, restricted, superseded, revoked, not recognized, or inactive. The public meaning should be explained. For example, “suspended pending review” is not the same as “revoked for misuse.” “Historical-only” is not the same as “invalid.” “Not recognized in this jurisdiction” is not the same as “false credential.”

Credential wallets and verifier tools should display boundaries. A revoked NSF operational credential may not mean professional license revocation. A suspended model credential may not mean model fraud. A restricted Project SPV evidence credential may not mean finance denial. An insurance-readiness credential under review may not mean claim denial or coverage withdrawal.

Revocation must be transparent without becoming defamatory or misleading.

### Revocation for AI Agents and Machines

Machine and AI credentials require fast revocation. A compromised node, unsafe model, revoked tool permission, leaked key, or malicious agent can act quickly and repeatedly. Revocation systems must support low-latency status checks for machine credentials.

A TEEExecutorVC may be revoked after invalid attestation, runtime compromise, node misuse, key leak, or jurisdiction violation. A SensorProviderVC may be suspended after data anomalies. A SimulationRunnerVC may be restricted after model mismatch. An AI-AgentToolUseVC may be revoked after policy violation or model quarantine. A RollupCoordinatorVC may be suspended after duplicate CAC inclusion.

Machine revocation should integrate with orchestration. Schedulers should stop dispatching to revoked nodes. Agents should lose tool access. Rollup builders should reject invalid signers. CAC verifiers should flag outputs after revocation time. Credential issuers should review credentials based on compromised machine CACs.

Machine revocation is the immune system of automated governance.

### Revocation for Project SPVs, Finance-Readiness, and Insurance-Readiness

Project SPV and capital-relevant credentials must support revocation, suspension, restriction, and expiry because underlying evidence changes. Asset telemetry may become stale. Maintenance records may be disputed. Climate simulations may be superseded. Safeguard evidence may be challenged. Data provider authority may expire. Controlled evidence room access may terminate. A finance-readiness evidence profile may become historical-only. An insurance-readiness monitoring credential may be suspended after sensor failure.

Revocation in these contexts must preserve boundaries. A revoked finance-readiness evidence credential is not finance rejection. A suspended insurance-readiness evidence credential is not underwriting denial. A Project SPV evidence credential under review is not legal wrongdoing. It means the evidence credential is no longer active for its declared use without review.

This allows capital-relevant evidence to remain current without crossing into regulated determinations.

### Cross-Jurisdictional Revocation and Recognition Withdrawal

A credential may be revoked globally, suspended locally, or no longer recognized in one jurisdiction. NSF must distinguish these.

Global revocation means the issuing authority invalidates the credential entirely.

Jurisdictional suspension means a jurisdiction or registry does not accept the credential for its scope.

Recognition withdrawal means a credential remains valid where issued but is no longer recognized by another jurisdiction or governance body.

Scope restriction means the credential remains active but with reduced permissions.

Emergency suspension means temporary restriction under emergency rules.

A credential verifier should check both issuer status and local recognition status. A credential active in Kenya may not authorize action in Tanzania without recognition. A model active for one basin may be invalid for another. A node credential active globally may be prohibited from a national SDZ.

Cross-jurisdictional revocation must be audit-linked and public-safe. It should not imply that the issuing jurisdiction was wrong unless that is the outcome of a proper review.

### Revocation Boundary Statement

Revocation infrastructure supports credential expiry, suspension, revocation, restriction, supersession, recognition withdrawal, status proofs, sparse Merkle roots, CRLs, Revocation Credentials, ZK non-revocation proofs, audit trails, AI agent safety, machine credential control, Project SPV evidence status, finance-readiness evidence, insurance-readiness evidence, and cross-jurisdictional trust correction.

It does not by itself create legal liability, regulatory enforcement, public authority action, certification, procurement approval, finance denial or approval, investment advice, insurance underwriting, claims determination, official public warning status, treaty enforcement, professional discipline, or proof of misconduct. Revocation changes credential status under a defined issuer, schema, jurisdiction, and governance scope. The legal effect of that status depends on applicable law, competent authority, contracts, institutional adoption, credential schema, and due process.

A revoked credential is not automatically a legal violation.

A suspended credential is not automatically misconduct.

A status root is not public authority.

A Revocation Credential is not a court order unless issued under competent authority.

A finance-readiness revocation is not finance denial.

An insurance-readiness revocation is not underwriting decision.

A model credential revocation is not proof that every past output was false.

This boundary must appear in revocation schemas, credential registries, wallets, verifier tools, audit dashboards, public-safe notices, and agent policies.

### Revocation as the Final Layer of Institutional Trust

In NSF, credentials are living trust objects. They are issued, used, checked, renewed, restricted, suspended, revoked, restored, superseded, and disputed. Their value depends not only on issuance, but on the ability to update trust when conditions change.

Revocation is how NSF responds to misuse.

It is how it handles compromised keys.

It is how it stops unsafe nodes.

It is how it retires stale models.

It is how it corrects false issuance.

It is how it protects public-safe outputs.

It is how it manages AI agent permissions.

It is how it preserves Project SPV evidence integrity.

It is how it keeps finance-readiness and insurance-readiness evidence current without becoming a regulated decision engine.

It is how it preserves accountability without erasing history.

Trust must be revocable because governance is dynamic. A system that can issue credentials but cannot revoke them is not zero-trust. It is static trust with cryptographic packaging.

The NSF principle is simple:

**Every credential that can authorize material action must be verifiably status-checkable, and where appropriate, revocable, suspendable, expirable, restrictable, supersedable, and correctable.**

That is the role of revocation infrastructure in the Nexus Sovereignty Framework: to make trust live, bounded, accountable, and capable of correction across humans, machines, institutions, jurisdictions, and time.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.therisk.global/organization/standardization/nexus-sovereignty/v.-verifiable-credentials/revocation-infrastructure.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.