Skip to main content

Revocation mechanisms

Credentials can be revoked by their issuers at any time. A user might lose their device, a document might expire, or eligibility might change. As a Relying Party, you need assurance that a presented credential is still valid at the moment of verification.

The Truvity EUDIW Connector checks revocation status automatically during every verification flow.

The Status List mechanism​

The EUDI ecosystem uses the IETF Token Status List specification (draft-ietf-oauth-status-list) to manage revocation in a privacy-preserving way.

Rather than querying the issuer about a specific credential (which would reveal the holder's activity to the issuer), the connector fetches a published Status List that contains the status of many credentials at once. A Status List is a bitstring in which each bit or group of bits denotes the current revocation or suspension status of one attestation. Each credential is assigned an index in the list at issuance. During verification, the connector checks the value at that index to determine whether the credential has been revoked.

This approach ensures unlinkability. The issuer publishes the list without knowing which specific credential a Relying Party is checking.

note

Attestations with a validity period of less than 24 hours may not include revocation information. The ARF does not require revocation data for short-lived attestations because their brief validity period inherently limits the window of exposure.

Automatic verification​

You do not need to fetch or parse Status Lists yourself. The connector handles this automatically when it receives a presentation:

  1. Extracts status information from the presented credential
  2. Fetches the latest Status List from the issuer's published endpoint
  3. Checks the credential's status at its assigned index

If the credential has been revoked, the connector reports this in the Presented Credentials Event delivered to your callback. The event status is set to VERIFICATION_FAILED, and the errorDetails field describes the failure.

Handling revocation in your integration​

The connector treats revocation as a verification failure. When a revoked credential is presented:

  • The Presented Credentials Event status is VERIFICATION_FAILED
  • The errorDetails field in the callback payload describes the revocation failure
  • Your system should handle this the same way it handles other verification failures

If the connector cannot fetch or validate the Status List (for example, because the issuer's endpoint is unavailable), the presentation also results in a VERIFICATION_FAILED status. This strict behavior is a deliberate implementation choice by the connector. The ARF allows Relying Parties to perform a risk analysis and potentially accept credentials when revocation status is unavailable, but the connector opts for the stricter approach to provide maximum security by default.

PID and Wallet Unit revocation​

When you verify that a PID is not revoked, you also gain assurance that the underlying Wallet Unit is still valid. The ARF requires PID Providers to regularly check whether the Wallet Unit has been revoked, and to revoke the PID if it has. This means there is no need for a separate mechanism to verify Wallet Unit revocation directly with the Wallet Provider. PID revocation checking implicitly covers Wallet Unit revocation.

Further reading​