Skip to main content
European CommissionEBSI European Blockchain

Overview of EBSI's Revocation Methods

Last updated on

Expressing Status as a Verifiable Credential

When the Issuer issues a new VC, they also share the VC's status information. The status information —stating whether a VC is valid, suspended, or revoked—is shared with the VC when it is issued to a Holder or presented to a verifying organisation. This status information is connected to another type of VC called a Credential Status VC. Think of this as a digital "report card" that tells you whether the VC in question is valid. The Issuer of the VC is responsible for storing and keeping this report card up to date. EBSI's decentralised network plays the role of a proxy between the person or organisation checking the status of a VC (the Verifier) and the Issuer responsible for hosting the Credential Status VC. Contact points of the issuing organisation possessing the VC status information are publicly available through EBSI's Trusted Issuers Registry.

A legal entity is an organisation with a distinct legal existence, separate from its individual members or owners. In the EBSI VC ecosystem, legal entities typically include government agencies and educational institutions responsible for administering credentials to VCs. Before they have the right to issue VCs, they must request authorisation from EBSI or receive accreditation from a Trusted Accreditation Organisation (TAO). Both processes require the issuance of VCs to legal entities. VCs issued to legal entities can belong to three types:

  1. Verifiable Authorisation: A VC issued to a legal entity during the onboarding process that provides access to EBSI's infrastructure and initiates the trust chain.
  2. Verifiable Accreditation: A VC that asserts which types of VCs a Trusted Issuer can issue and under which policies.
  3. Verifiable Attestation: A VC that asserts statements or claims about the legal entity possessing the VC.

A legal entity's VC may need to change its status from valid to either revoked, suspended, or expired. Such changes can occur due to organisational restructuring in which a government agency undergoes a merger or split, resulting in the need to update their VCs.

Example scenarios may include:

  • Organisational restructuring: A government agency may undergo a merger or split, requiring it to update its VCs. For instance, if two educational institutions merge into one, the new entity may require updated Verifiable Authorisations or Accreditations to reflect the change in its structure and scope of credential issuing services.
  • Policy updates: Changes in regulations or industry standards may require the alteration of existing VCs. For example, if new amendments are added to the GDPR, a legal entity responsible for managing personal data may need to update its Verifiable Attestation to comply with the new requirements.
  • Termination of a legal entity's operations: When a legal entity ceases its operations, its VCs may expire or require revocation. Suppose a professional certification body goes out of business. Its Verifiable Accreditations may need to be revoked to prevent it from issuing new certifications and ensure the VC ecosystem remains accurate and up to date.

In each of these situations, it is important to maintain the integrity of the EBSI VC ecosystem and trust chain by supporting the management of legal entity VC status information. Since legal entities are often public organisations, their information can be made publicly available, and their VCs are not subject to the GDPR. Consequently, the status of a legal entity's VC can be managed in the Trusted Issuers Registry on EBSI's ledger.

Verifiable Accreditation Management Strategies

Accreditation status information is essential for verifying that a legal entity meets the necessary criteria to issue verifiable credentials. Depending on use case specific requirements, EBSI proposes two strategies enabling Verifiable Accreditation Issuers to store and manage accreditation status information of the credentials they issue.

Verifiable Accreditation Management Strategies

Strategy A: The Verifiable Accreditation status information is stored in the EBSI Trusted Issuers Registry

The EBSI Trusted Issuers Registry uses distributed ledger technology that allows for the secure storage and management of accreditation status information. The verifying organisation retrieves the accreditation status information directly from the Trusted Issuers Registry, which serves as a proxy between the Issuer and Verifier. This strategy also eliminates the burden of storing the accreditation status information from the Issuer.

Strategy B: The Verifiable Accreditation status information is hosted by the Issuer and obtained via the EBSI Trusted Issuers Registry

In this strategy, the Issuer of the Verifiable Accreditation is responsible for hosting the accreditation status information and making this information available through the EBSI Trusted Issuers Registry. This approach offers the advantage of allowing issuers to maintain control over the accreditation status information while also providing the benefits of the EBSI Trusted Issuers Registry regarding security and tamper-proofing. This approach is useful for issuers who have already established their own systems for managing accreditation status information and wish to integrate with the EBSI Trusted Issuers Registry.

Data Structures for Verifiable Accreditation Management

Two data structures or formats can be used to manage the status information of Verifiable Accreditations: W3C Status List and Certificate Revocation List (CRL).

W3C Status List

A Status List can efficiently store information about the status of a Verifiable Accreditation using a simple "Yes" or "No" format. For example, the Ministry of Education could use a W3C Status List to track a university's accreditation status. If the university is granted accreditation and continues to meet the criteria necessary to issue diplomas, its name will be on the list with a "yes" next to it. On the other hand, if a university is found to be no longer qualified to issue diplomas, its name will appear on the list with a "no". The W3C Status List provides a simple and efficient way for the Ministry of Education to manage the accreditation status of universities.

Certificate Revocation List

The CRL provides more detailed information than a simple "yes" or "no" status. Like the Status List example above, the Ministry of Education could use a CRL to keep track of the status of university accreditations. The key difference with a Status List is that if a university's accreditation status has been revoked, the revocation date, reason for revocation, and other related information may also be provided in the CRL.

Revocation of VCs Issued to Natural Persons (GDPR)

Natural persons, such as students, workers, or citizens, receive Verifiable Attestations issued by authorised and accredited legal entities. This type of VC asserts statements or claims about the holder, such as possession of a diploma or training certificate. To receive and use VCs, natural persons can register with an EBSI approved wallet provider to request, store, and present their VCs.

A natural person's VC may need to have its status changed from valid to either revoked, suspended, or expired due to changes in personal circumstances or inaccuracies found in the original VC.

Example scenarios may include:

  • Academic misconduct: A student may be found guilty of cheating on an examination or plagiarism. In such cases, the educational institution may need to revoke the student's VC for the course or degree in question, as it no longer accurately reflects the student's qualifications.
  • Erroneous issuance: A VC may have been issued incorrectly, containing incorrect information about the natural person's qualifications or achievements. For instance, a university may have mistakenly awarded a degree with honours when the student did not meet the required criteria.
  • Changes in personal circumstances: A natural person may have a change in their circumstances that requires updating or revoking their VC. For example, a student may need to withdraw from a course due to personal reasons or health issues, resulting in the revocation of their enrolment VC.

Regarding revocation, the status information for Verifiable Attestations belonging to natural persons must be managed per the GDPR. This means that the status information cannot be stored directly on EBSI's ledger. Instead, appropriate measures must be taken to ensure the privacy and security of personal data while still allowing for the efficient management and updating of VC status information.

Verifiable Attestation Management Strategies

The status information of Verifiable Attestations for natural persons can be managed using different strategies based on whether they are short-lived or long-lived VCs. This section outlines these strategies and differentiates them based on their advantages and limitations.

Verifiable Attestation Management Strategies

Short-lived VCs

Strategy A: Holder obtains a fresh VC

When using short-lived VCs, the holder obtains a fresh VC each time it is needed. As a result, a short-lived VC does not require additional revocation infrastructure.

Advantages

  • Leverages existing VC issuance infrastructure
  • Simplifies verification by only requiring an expiration date check
  • Ensures up-to-date information
  • Prevents tracking of holder status changes by the Verifier

Limitations

  • The Issuer becomes aware of the holder's activities, raising privacy concerns
  • Both the Issuer and holder must be online
  • The Issuer must support timely VC issuance

Long-lived VCs

Strategy B: Obtaining VC status directly from the Trusted Issuer

In this approach, the status information is retrieved directly from the Trusted Issuer

Advantages

  • Works even if the holder's wallet is offline or has poor connectivity
  • Provides up-to-date status information
  • Depending on the format, it can limit the duration for which the information is visible to the Verifier.

Limitations

  • The Issuer learns which Verifier received a VC, raising privacy concerns
  • Depending on the format, the holder may not be able to limit the duration for which a verifier can check the information
Strategy C: Obtaining VC status from the Trusted Issuer via EBSI

In this approach, the status information is retrieved from the Trusted Issuer through the EBSI network.

Advantages

  • Applicable to both VCs belonging to Legal Entities and Natural Persons
  • The Issuer only learns that a VC from the revocation/suspension list has been shared without the knowledge of who shared the information or with whom the information has been shared
  • Works even if the holder's wallet is offline (the Verifier must be online)
  • Depending on the format, it can limit the duration for which the information is visible to the Verifier.
  • Information is shared from the Issuer to the EBSI network to the Verifier, reducing additional traffic for the wallet.

Limitations

  • Depending on the format, the holder may not be able to limit the duration during which a verifier can check the information
Strategy D: Holder obtains a status VC from the Issuer or a third party

In this strategy, the holder obtains a separate VC containing status information from either the Issuer or a third party.

Data Structures for Verifiable Attestation Management

Verifiable attestation status information can be stored in one of three formats: W3C Status List, CRL, or as a Status VC. As W3C Status List and CRL-based formats match those used in managing Verifiable Accreditations belonging to legal entities, this section will focus on the Status VC. Additionally, within the CRL family of profiles, EBSI introduces a new mechanism, the Dynamic Status List, which enables the capability to constrain the time that the status information is visible. The mechanism is applicable to different data formats.

Status VC

A Status VC is a short-lived VC issued to the holder of a credential by either the Issuer or a trusted third party. When the holder shares their credential with a verifier, they share the Status VC along with the original VC. This approach is equivalent to requesting a fresh VC.