Credential Status

The W3C-recommended standard for efficient revocation. It uses a bitstring status list where each credential is assigned a specific bit position. A value of 0 indicates the credential is valid, while 1 indicates revoked. This allows a single, compact list to manage the status of thousands of credentials, drastically reducing on-chain data and computational overhead compared to per-credential checks.

Credential status supports two distinct states of invalidity. Revocation is permanent, typically used when a credential should never be valid again (e.g., a lost ID). Suspension is temporary, allowing an issuer to pause a credential's validity (e.g., for investigation) with the potential to later reinstate it. The status list bit can represent either state, with the semantics defined by the issuer's governance policy.

Status checks are performed by verifiers (relying parties) without contacting the issuer directly. The verifier fetches the current status list (hosted at a URI in the credential's credentialStatus field) and checks the bit at the credential's index. This enables offline-first, privacy-preserving verification while ensuring the credential's validity is governed by a trusted, updatable source.

The technical field embedded within a Verifiable Credential that defines how to check its status. It is a JSON object containing:

• id: The unique URI of the status list.
• type: The status method (e.g., StatusList2021Entry).
• statusPurpose: Either revocation or suspension.
• statusListIndex: The integer position of the credential's status bit in the list.
• statusListCredential: The URI of the Verifiable Credential that contains the status list itself.

Status lists can be anchored to different infrastructures for trust and availability. On-Chain models store the list's hash or the list itself on a blockchain (e.g., Ethereum, ION), providing strong tamper-evidence and censorship resistance. Off-Chain models host the list on a traditional web server or distributed file system (e.g., IPFS), offering higher scalability and lower cost, with trust derived from the issuer's signature on the status list VC.

Advanced status protocols enable privacy-preserving revocation checks. Using zero-knowledge proofs (ZKPs), a holder can prove their credential is not revoked without revealing the credential's unique identifier or its position in the status list. This prevents verifiers from correlating different presentations from the same holder, a critical feature for building anonymous yet accountable credential systems.

An earlier bitstring-based status protocol that stores revocation status in a verifiable credential itself. The issuer signs a credential containing the revocation list, which verifiers must fetch and parse.

• Key Difference: The list is a signed credential, not a standalone resource.
• Trade-off: Simpler to implement but requires verifiers to process the entire list object.

A flexible, schema-based approach using JSON-LD contexts. It defines a credentialStatus property within the credential, pointing to a service endpoint or a cryptographic proof for checking status.

• Use Case: Enables custom status mechanisms like smart contract checks or Oracle queries.
• Advantage: Highly extensible and can integrate with existing blockchain or database systems.

Status checking integrated with OpenID Connect Self-Issued OP (SIOP) flows. Relies on the OIDC provider's backend to assert credential validity during the authentication handshake, often using a distributed ledger or a centralized registry.

• Context: Primarily for decentralized identity (DID) and sign-in protocols.
• Mechanism: Status is embedded within the ID Token or verified via a separate endpoint call.

A status mechanism where the credential points to a live, queryable registry (e.g., a smart contract, API, or blockchain). The verifier queries this registry in real-time using a credential-specific identifier.

• Characteristics: Enables real-time revocation and complex status logic.
• Drawback: Requires the registry to be highly available and introduces latency.

The most fundamental status controls: validFrom and validUntil timestamps defined in the credential's payload. Validity is determined by comparing current time against these fields.

• Universal: Supported by all credential formats.
• Limitation: Cannot handle mid-term revocation; only provides binary expiration.

A W3C standard that defines a privacy-preserving method for credential revocation using a bitstring status list. Each credential is mapped to a specific bit in a cryptographically signed list. A value of 0 indicates the credential is valid, while 1 indicates it is revoked. This allows for efficient, batch status checks without revealing which specific credential is being verified.

• Mechanism: Status is encoded in a JSON Web Signature (JWS) or JSON Web Token (JWT).
• Privacy: Verifiers only learn if the credential is valid, not the holder's other credentials.
• Example: A university issues a diploma VC and publishes a status list. Employers can check the list's signature and the relevant bit to confirm the diploma is still valid.

A decentralized ledger-based approach, often used with Decentralized Identifiers (DIDs), where credential issuers publish revocation events to a verifiable data registry (e.g., a blockchain). The status is checked by querying the registry for the credential's unique identifier.

• Common in: Hyperledger Indy, Sovrin, and other SSI (Self-Sovereign Identity) frameworks.
• Process: The issuer creates a revocation registry on the ledger. To revoke, they publish a cryptographic accumulator delta (like a CL signature).
• Verification: The verifier fetches the latest registry state and the non-revocation proof from the holder to cryptographically verify status.

The most basic form of status management, using time-based fields within the credential's metadata. Validity is determined by comparing the current time against these predefined fields.

• validFrom: The datetime when the credential becomes active.
• validUntil or expirationDate: The datetime after which the credential is no longer valid.
• Limitation: This method cannot handle mid-lifecycle revocation (e.g., a driver's license being suspended). It is often used in conjunction with a revocation mechanism like a status list.

A standard RFC 7662 method where a verifier (resource server) queries the authorization server's introspection endpoint to check the active state of a presented token. While not a native VC standard, this pattern is adapted for credential status in some enterprise and OpenID Connect implementations.

• Flow: The verifier sends the token to a trusted issuer endpoint.
• Response: The endpoint returns a JSON object with an active boolean and other metadata.
• Use Case: Often used for API access tokens and can be extended to manage the status of Verifiable Presentations in walled-garden ecosystems.

Advanced cryptographic schemes allow a holder to prove a credential is valid without revealing its unique identifier, enabling privacy-preserving status checks. This is a core feature of Zero-Knowledge Proof (ZKP) based credentials.

• Mechanism: Using BBS+ signatures or similar, the holder can generate a proof that their credential is both unrevoked and contains certain claims, without disclosing the credential ID or other sensitive data.
• Benefit: Prevents correlation across different verifications, as the verifier cannot link the status check back to a specific entry in a public revocation list.

A large-scale, real-world deployment of credential status checking. The EU DCC system used a blacklist (revocation list) of compromised or invalid certificate identifiers.

• Status Mechanism: National health authorities published signed JSON lists of revoked certificate unique identifiers (UVCI).
• Verification App Flow: The verifier app would download the latest revocation list, check its digital signature, and then check if the presented certificate's ID was on the list.
• Scale: Demonstrated the operational challenges of distributing and updating revocation lists across multiple jurisdictions in near real-time.

A blockchain-anchored method, often used with Indy-style credentials, where a revocation registry (e.g., a cryptographic accumulator) is published to a ledger. The credential includes a revocation registry identifier and a private witness. To prove validity, the holder demonstrates their credential is not in the published accumulator without revealing its specific identifier, offering strong privacy.

The trade-off between decentralization and efficiency in status verification.

• On-Chain: Status is written to a public ledger (e.g., Ethereum, Sovrin). Provides tamper-proof audit trails but incurs transaction costs and latency.
• Off-Chain: Status is managed by the issuer via an API or a status list credential. Offers high performance and low cost but re-introduces a point of centralization and issuer availability risk.

How status verification can leak sensitive information about the credential holder.

• Correlation: Frequent checks of the same status list can link a holder's activities across different verifiers.
• Timing Attacks: The act of checking status can reveal the exact moment a credential is presented.
• Identifier Exposure: Some methods require sending a unique credential identifier to the issuer's server, breaking holder-centric privacy models.

Advanced cryptographic techniques that allow a holder to prove a credential is valid without revealing its full identifier or linking to previous presentations.

• Zero-Knowledge Proofs (ZKPs): Enable a holder to generate a proof that their credential's status bit is 0 (valid) without revealing the index.
• BBS+ Signatures: Allow for derived proofs where status can be proven as part of a larger selective disclosure set, minimizing data leakage.

The security dependency on the credential issuer's operational status and integrity.

• Availability Risk: If an issuer's status endpoint goes offline, all credentials become unverifiable, creating a single point of failure.
• Censorship Risk: A malicious or coerced issuer could falsely revoke credentials or deny status checks.
• Mitigations: Use decentralized status lists (e.g., on IPFS), long-lived status credentials, or persistent on-chain registries to reduce this dependency.

A Verifiable Credential is a tamper-evident digital claim issued by an issuer to a holder. It is the foundational data structure whose validity is governed by a credential status mechanism. VCs are cryptographically signed and can represent attributes like diplomas, licenses, or memberships. The status property within a VC points to the method used to check its revocation or suspension.

The Status List 2021 specification is a W3C-standardized method for managing credential revocation. It uses a compressed bitstring where each bit represents the status (e.g., 0=valid, 1=revoked) of a single credential. This allows issuers to revoke many credentials by publishing and signing a single, compact status list, enabling efficient and privacy-preserving status checks without revealing which specific credential is being verified.

A Revocation Registry is a decentralized, on-chain data structure, often used in Indy-based systems and AnonCreds, that tracks the revocation status of credentials. Issuers publish cryptographic accumulators (like a revocation accumulator) to a ledger. Verifiers check a credential's status by using a non-revocation proof provided by the holder, which cryptographically proves the credential is not listed in the current registry, without revealing the credential's unique identifier.

The statusPurpose property in a Verifiable Credential's credentialStatus object specifies the reason for the status check. The two primary purposes defined by the W3C are:

• revocation: The credential has been permanently invalidated by the issuer.
• suspension: The credential is temporarily invalid and may be reinstated later. This distinction allows for more granular control over a credential's lifecycle and the issuer's policies.

A Decentralized Identifier (DID) is a globally unique identifier controlled by the subject (e.g., holder or issuer) without a central registry. DIDs are foundational for credential status as they provide the persistent, verifiable endpoints (DID URLs) used in the credentialStatus field. The issuer's DID is used to sign the status list or registry update, allowing any verifier to cryptographically confirm the status information's authenticity and integrity.

Selective Disclosure is a privacy-enhancing technique where a holder reveals only specific claims from a credential without exposing the entire document. Credential status mechanisms must support this model. For example, when presenting a proof, the holder must also provide a valid non-revocation proof for the credential(s) used, without revealing unnecessary information about other credentials they hold or their full identity, maintaining minimal disclosure.