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 credential-level revocation automatically during every verification flow. It determines whether the credential itself has been revoked by its issuer using the Status List mechanism described below. A second layer, certificate-level revocation, verifies that the X.509 certificate used to sign the credential has not been revoked by its Certificate Authority. This layer is optional and off by default.

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 per-credential isRevoked field is set to true, allowing your app to decide how to handle the revoked credential.

Handling revocation in your integration​

The connector reports revocation status as per-credential fields within the Presented Credentials Event, not as an overall flow failure. When a revoked credential is presented:

  • The event status is FULFILLED (the presentation flow completed successfully)
  • Each credential in the credentials map includes supportRevocation and isRevoked fields
  • If supportRevocation is true and isRevoked is true, the credential's issuer has revoked it
  • Your system must check the isRevoked field for each credential and decide whether to accept or reject the transaction

Revocation does not trigger VERIFICATION_FAILED. That status is reserved for cryptographic failures (invalid signatures, Key Binding JWT validation errors), DCQL mismatches, and transaction data hash failures—cases where the presentation itself is technically invalid. A revoked credential is a valid presentation of a credential that happens to be revoked, so the connector delivers the full credential data and lets your app decide what to do.

This design gives you full control over the revocation policy. The connector provides the revocation data; your app decides how to act on it.

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.

Certificate Revocation List (CRL) checking​

In addition to credential-level revocation (Status List), the connector can also check whether the X.509 certificates used to sign credentials have been revoked by their issuing Certificate Authority. In HAIP-compliant ecosystems, SD-JWT VC credentials include an x5c certificate chain in the JWT header—this is mandatory per the HAIP profile for issuer key resolution. CRL checking verifies that none of the certificates in that chain have been revoked. CRL checking is not mandated by the ARF, OID4VP, SD-JWT VC, or HAIP specifications—it is a standard X.509 PKI security practice (RFC 5280) that some EUDI federation deployments require. The connector implements it as an optional, configurable feature that is off by default.

How it works​

When a credential includes an x5c header (which is always the case for SD-JWT VCs in HAIP-compliant ecosystems), the connector performs up to two verification steps:

  1. Chain-internal validation—always runs when x5c is present, regardless of configuration. The connector verifies that each certificate in the chain is properly signed by the next, that all certificates are within their validity periods, and that Basic Constraints and Key Usage extensions are correct. This is standard X.509 path validation per RFC 5280. If this fails, the credential fails verification. Credentials without an x5c header (non-HAIP credential formats) are unaffected.

  2. Trust anchor resolution and CRL checking—runs only when enabled via configuration. The connector resolves the chain's last certificate against a set of configured trust anchors. It first attempts Authority Key Identifier (AKI) to Subject Key Identifier (SKI) matching per RFC 5280. If no match is found via AKI/SKI, it falls back to Issuer Distinguished Name matching combined with signature verification. Once a trust anchor is matched, the connector verifies the last certificate's signature against it, then fetches the Certificate Revocation List from each certificate's CRL Distribution Point extension, verifies the CRL's signature and freshness, and checks whether the certificate's serial number appears in the revocation list. If no valid CRL can be obtained from any distribution point, the certificate is treated as not revoked.

Callback fields​

When a credential includes an x5c certificate chain, the callback payload's per-credential object includes:

  • supportTrustAnchor—set to true when the credential was signed with an x5c header
  • isTrusted—whether the chain terminated at a configured trust anchor and the last certificate's signature was verified against it. false when trust anchor verification is off or no matching trust anchor is found. Only present when supportTrustAnchor is true.
  • isCertificateRevoked—whether any certificate in the chain was found on a CRL. false when trust anchor verification is off (CRL checking is skipped) or when no valid CRL could be obtained. Only present when supportTrustAnchor is true.

See Callback events for the full credential object field reference.

note

CRL checking is off by default and requires configuration. See Configure X.509 trust anchor verification for setup steps.

Further reading​