Attestation Revocation

Revocation is executed by updating a smart contract's state, such as flipping a boolean flag in a mapping or adding an entry to a revocation registry. This creates a permanent, verifiable record on the blockchain, ensuring all verifiers can check the credential's current status against the single source of truth.

Smart contracts enforce access control to determine who can revoke. Common models include:

• Issuer-Only: Only the original credential issuer can revoke.
• Multi-Signature: Requires approval from a defined set of signers.
• Time-Locked: Revocation is only possible after a specific delay or epoch. This prevents malicious or accidental invalidation of credentials.

A standardized pattern (like EIP-5539) uses a separate, gas-efficient smart contract as a revocation registry. Instead of storing all credential data, issuers post a cryptographic commitment (like a Merkle root) to this registry. Individual revocations are proven via Merkle proofs, separating revocation logic from credential issuance for scalability.

Advanced schemes like zk-SNARKs or BBS+ signatures enable holders to prove a credential is valid and unrevoked without revealing the credential's unique identifier or the revocation registry's entire state. This preserves privacy while maintaining the security guarantee of revocation checks.

Revocation is often used alongside expiration timestamps. A credential can become invalid through:

• Active Revocation: Manual invalidation by the issuer.
• Passive Expiry: Automatic invalidation after a pre-set validUntil timestamp. This combination allows for both emergency response and predictable credential lifecycle management.

Verifiers must query the on-chain state to confirm a credential is not revoked. To minimize gas costs, patterns like storing bitmaps or epoch-based revocation are used. For example, revoking all credentials issued before a certain block number is more efficient than revoking individual entries.

Revocation is typically managed by the attestation issuer or a designated revocation authority. It involves updating a revocation registry (like an on-chain smart contract or a verifiable credential status list) to flag an attestation's unique identifier (UID) as invalid. Verifiers must check this registry to confirm an attestation's current status before trusting its claims.

• Compliance & Legal Orders: Revoking credentials due to court orders or regulatory changes.
• Key Compromise: Invalidating attestations if an issuer's signing key is lost or stolen.
• Data Correction: Removing outdated or incorrect information from the ecosystem.
• User Privacy: Allowing users to revoke consent for data usage, as seen in decentralized identity frameworks.

A standardized smart contract interface for managing revocations on Ethereum. It provides a gas-efficient way to check if an attestation UID is revoked using a bitmap-based approach. This allows protocols like Ethereum Attestation Service (EAS) to offer scalable revocation checks without storing full data on-chain for each query.

Revocation strategies vary by implementation:

• On-Chain (EAS, SBTs): Status is stored and checked directly on a blockchain (e.g., via EIP-5539), providing maximum transparency and censorship resistance.
• Off-Chain (W3C VCs): Status lists are often hosted off-chain (e.g., JSON files) and referenced by a URL, with integrity protected by cryptographic hashes. This offers flexibility but introduces a dependency on the availability of the status endpoint.

For decentralized applications (dApps) and DeFi protocols, integrating revocation checks is essential for risk management. A protocol relying on attestations for KYC, creditworthiness, or reputation must query the relevant revocation registry during transaction validation. Failure to do so can lead to accepting invalid credentials, creating financial or legal exposure.

While individual attestations can be revoked, the attestation schema (the template defining its data structure) is often immutable once created. This separation ensures data integrity: revocation handles specific false statements, while the schema's permanence provides a consistent framework for interpreting all attestations of that type.

Revocation is essential when a private key is lost or stolen, a credential is issued in error, or the underlying data is proven false. This prevents malicious actors from using compromised attestations to gain unauthorized access or privileges. For example, a revoked KYC attestation would immediately invalidate a user's verified status across all integrated applications.

Many jurisdictions require the ability to revoke credentials to comply with data privacy laws (like GDPR's 'right to be forgotten'), sanctions lists, or changing licensing statuses. A revocation registry allows issuers to maintain an on-chain, auditable record of compliance actions without deleting the original attestation data.

Revocation enables time-bound or conditional access. This is used for:

• Subscription services: Revoking access after a membership expires.
• Event credentials: Invalidating a ticket or pass after an event concludes.
• Role-based permissions: Removing admin rights when a user changes teams. The attestation remains on-chain as a historical record, but its active status is revoked.

In decentralized systems like DAOs or airdrops, attestations prove 'unique humanity' or contribution. If a user is found to have gamed the system with multiple identities, revoking their proof-of-personhood attestations (e.g., from Worldcoin or BrightID) prevents them from accumulating undue influence or rewards, protecting the network's integrity.

When an attestation schema has a critical bug or security flaw, issuers can revoke all attestations issued under the old schema and re-issue them under a corrected one. This allows for protocol upgrades and maintenance while ensuring only valid, current credentials are accepted by verifiers.

In DeFi or on-chain credit scoring, a user's reputation is built from attestations of successful repayments or governance participation. Revocation acts as a penalty mechanism for bad actors—such as those who default on a loan—allowing their reputation score to be dynamically and transparently adjusted, which other protocols can trustlessly verify.

The most common revocation mechanism, where a revocation authority maintains a list of revoked attestation identifiers (e.g., cryptographic hashes). Verifiers must check this list, often implemented as a Certificate Revocation List (CRL) or a Bloom filter for privacy. This creates an active verification dependency and potential privacy leak.

A cryptographic method for efficient, private revocation using RSA accumulators or Merkle trees. A single accumulator value represents the set of all valid attestations; revoking one requires updating the accumulator. This allows for constant-size proofs and privacy-preserving verification, as the verifier only checks membership without revealing which specific attestation was revoked.

A passive revocation strategy where each attestation has a built-in expiry timestamp. While not revocation in the active sense, it limits the attestation's validity window, reducing the long-term impact of compromise. This is often used in conjunction with active methods (like lists) for defense-in-depth.

Revocation is only as secure as the revocation authority. Centralized authorities create a single point of failure. Risks include:

• Private key loss: Inability to sign new revocation lists.
• Malicious authority: Censorship or fraudulent revocation.
• Governance attacks: Takeover of the authority's decision-making process. Decentralized or multi-sig models mitigate this.

A critical security assumption: verifiers must check for revocation. If a verifier uses a stale cache or fails to query the revocation source, they may accept a revoked credential. Systems must enforce freshness proofs (e.g., signed timestamps on revocation lists) and define slashing conditions for verifiers who accept stale state.

Revocation mechanisms create a tension between privacy and accountability. Public lists reveal which identifiers are revoked, potentially leaking user activity. Zero-knowledge schemes (like accumulators) preserve privacy but add complexity. The design choice depends on the trust model and whether the system needs to publicly audit revocation actions.