Skip to main content
European CommissionEBSI European Blockchain

Credential Revocation and Status: The Context

Last updated on

Revocation in Verifiable Credentials: Why it Matters

What would happen if a student was found guilty of fraud or any other form of academic misconduct resulting in the revocation of their degree? How can a recruiter or university administrator verify whether the presented diploma is still valid? Verifiers, such as public administrations and businesses, must be able to verify the status and validity of VCs to maintain trust between the Issuer, holder, and verifying organisation. The absence of such a framework could increase the risk of fraudulent activity, eroding the trust and credibility of the entire VC ecosystem. This is where revocation and suspension come into play.

Revocation and suspension measures exist to ensure that the credential holder continues to meet specific criteria, such as possessing certain skills or completing an academic programme. By revoking or suspending a credential, issuers retain control over the credentials they issue, and the holder is held accountable for their actions—or lack thereof in the case of a holder's failure to renew a credential before its expiration. The revocation and suspension framework must include the following parameters for VCs:

  • The validity of a VC is determined by three elements: the VC's inherent properties, such as a validity date (the date at and after which the VC becomes valid), the authenticity of the public keys used to sign or seal the VC along with their supporting attestations, and the status of the VC itself.
  • The status of a VC indicates its current state, which can be valid (active and acceptable for authentication), revoked (withdrawn or cancelled permanently), or suspended (temporarily disabled but may be reinstated later).
  • A VC can also be cancelled after its expiration if an expiry date has been assigned. This is often the case for VCs with a short lifetime. Revocation and suspension follow the same implementation process, with the only difference being that suspension is temporary and reversible, whereas revocation is permanent and non-reversible. In this document, the term "revocation" will be used interchangeably to refer to both revocation and suspension.

Revocation and suspension follow the same implementation process, with the only difference being that suspension is temporary and reversible, whereas revocation is permanent and non-reversible. In this document, the term "revocation" will be used interchangeably to refer to both revocation and suspension

EBSI's Use Cases — Requirements for Revocation

EBSI's use cases define the following essential business requirements for the revocation framework:

  • Ensure compliance with GDPR;
  • Eliminate the traceability of holders;
  • Protect holder privacy;
  • Refrain from storing or processing personal data on the EBSI blockchain;
  • Prevent issuers or third parties from linking revocation checks to holders.

Moreover, EBSI's revocation framework must also accommodate the following three types of services:

  1. Revocation services associated with Issuers of VCs;
  2. Revocation services associated with Holders of VCs;
  3. Revocation services associated with VCs themselves.

By ensuring privacy and regulatory compliance, EBSI aims to foster a revocation framework that protects the rights and interests of all participants in the credential ecosystem while also ensuring that the framework supports various revocation service types.

Identifying Use-Case Specific Requirements

Owners of individual use cases should carefully analyse various revocation strategies to determine their appropriateness for their specific use case, considering the trade-offs involved. To identify use-case specific requirements, consider the following three criteria:

  1. Level of privacy preservation needed: Assess whether user tracking is permissible with the use case. For example, legal entities like public organisations may not require privacy-preserving approaches. However, natural persons, such as individuals or private entities, must have their privacy protected in compliance with privacy regulations.
  2. Use case time window: Determine if it's necessary to restrict the access of a credential to a specified time window. This may be important in cases where there is a high level of assurance (LoA), which means there is a high level of certainty of a service provider that a claim from an individual is authentic, such as with medical records. A limited time window can help protect sensitive information and minimise potential misuse of outdated or revoked credentials.
  3. Necessity of tracking signature validity: Evaluate whether monitoring the validity of signatures within the use case is essential. In some instances, tracking signature validity might be critical for maintaining the integrity and authenticity of credentials. Ensuring the validity of signatures can help prevent fraud and unauthorised access to sensitive information.

The complexity of revocation for verifiable credentials means there is no one-size-fits-all solution applicable to all use cases. However, by examining these criteria, use case owners can make more informed decisions about the revocation strategies that best meet their requirements, balancing the need for security, privacy, and functionality.