Credential Revocation
What happens when a credential needs to be invalidated before it expires? Understanding revocation mechanisms is crucial for maintaining trust in credential ecosystems.
Why Revocation Matters
Credentials may need to be invalidated before their natural expiration for various reasons. Without revocation mechanisms, verifiers would have no way to know if a credential is still valid.
Key Compromise
If an issuer's signing key is compromised, all credentials signed with that key may need revocation.
Status Change
A person's qualifications may change - a license suspended, employment terminated, or membership cancelled.
Issuance Error
Credentials issued in error or with incorrect information must be invalidated.
Fraud Prevention
If credential misuse is detected, revocation prevents further fraudulent use.
Revocation Mechanisms
Different credential formats use different approaches to revocation, each with trade-offs between privacy, latency, and complexity.
Status List Approaches
Status lists are the most common approach for verifiable credentials. Each credential is assigned an index in a bitstring, where the bit value indicates revocation status.
W3C Bitstring Status List
The W3C standard for VCDM credentials. Each credential references a status list URL and index. Verifiers download the compressed bitstring and check the relevant bit.
Token Status List (IETF)
Similar concept for JWT and SD-JWT credentials. Defines a standard way to reference and publish status lists compatible with OAuth/OIDC ecosystems.
Time-Bound Credentials
An alternative to explicit revocation is issuing credentials with very short validity periods. This approach is used by ISO mDOC and some other systems.
- No revocation infrastructure needed
- Maximum privacy (no status checks)
- Simple verification logic
- Natural credential refresh cycle
- Requires frequent credential refresh
- Holder must have connectivity to issuer
- Cannot immediately revoke (wait for expiry)
- May not suit all use cases
Mechanism Comparison
| Mechanism | Format | Privacy | Latency | Complexity |
|---|---|---|---|---|
| Bitstring Status List | W3C VCDM | Good (batch download) | Medium (cache) | Low |
| Token Status List | JWT/SD-JWT | Good (batch download) | Medium (cache) | Low |
| Validity Period | ISO mDOC | Excellent (no check needed) | None | Very Low |
| OCSP | Traditional PKI | Poor (real-time check) | High (network) | Medium |
| Accumulator | ZKP Systems | Excellent | Low | High |
Privacy Considerations
Revocation mechanisms can potentially leak information about credential usage. The choice of mechanism affects holder privacy.
Phone-Home Problem
MediumThreat
Real-time revocation checks (like OCSP) tell the issuer exactly when and where credentials are being used.
Mitigation
Use batch-downloadable status lists that verifiers can cache locally.
Status List Correlation
LowThreat
If credentials from different holders share status list positions, usage patterns could potentially be correlated.
Mitigation
Randomize status list index assignment. Use large status lists with sparse population.
Emerging Approaches
Research continues on more advanced revocation mechanisms that provide better privacy and efficiency guarantees.
Cryptographic Accumulators
Allow proving membership (or non-membership) in a set without revealing which specific element is being proven. Used in some privacy-focused credential systems.
ZK Revocation
Combining zero-knowledge proofs with revocation allows holders to prove their credential is not revoked without revealing any identifying information.
Validity Credentials
Short-lived "validity credentials" that attest to the current status of a long-lived base credential, combining time-bound and status-check approaches.
Implementation Best Practices
1 Choose Privacy-Preserving Mechanisms
Prefer status lists over real-time queries. Avoid mechanisms that allow issuers to track credential usage.
2 Enable Caching
Configure appropriate cache headers for status lists. Balance freshness requirements with performance.
3 Support Multiple Purposes
Distinguish between revocation (permanent) and suspension (temporary). Use appropriate statusPurpose values.
4 Plan for Scale
Size status lists appropriately. Consider sharding for large credential populations to manage list sizes.
Continue Learning
For technical implementation details of status lists in VCDM, see the dedicated revocation page.