---
# System prepended metadata

title: Comparison of Revocation mechanisms

---

# Comparison of Status mechanisms

## Contenders

- short-lived Credentials (no status)
- Deny-List (CRL, Idenitfier List for JSON/CBOR)
- StatusList (bitarray/bitstring, IETF Token Status List, W3C StatusList 2021)
- OCSP
- OCSP stapling / Status Attestations / Validity VCs / Non-Revocation Token
- Accumulator (e.g. Indy)
- TOTP + Bloom Filter (DynamicSLBloomFilter2023)

![status_mechanisms](https://hackmd.io/_uploads/BkR7753l0.png)


## revocation use cases

- important from german eIDAS proposal
- others?

## Evaluation Criteria

- Scalability
    - Does the effiency suffer for the issuance or the verifier when adding new elements
    - Option for Third Party Hosting/CDN?
- Privacy
    - Observability from Issuer (Traceability)
    - Observability from Verifier (Profiling)
    - Observability from Outsiders
- Complexity
    - Algorithm (is it easy to understand?), is the Specification publical available (for free)
    - Implementation (is it hard to implement? How many libraries exist to support it?)
    - Communication requirements
        - during issuance
        - during presentation
- Efficency (costs/time, required resources)
    - Efficiency for Issuer 
        - (how many resoures are required to update one credential)
        - providing the information
    - Efficiency for Holder
    - Efficiency for Verifier
- Feature
    - Historical data
    - Third Party hosting as a privacy feature
    - reversible status changes
- Offline capability and Caching
    - Scenario Holder is offline
    - Scenario Verifier is offline
- Dependancy
    - Bound to specific algorithms (e.g. crypto agility)
    - Bound to a specific system (DLT)