Skip to main content

Revocation chaining: How revoking a Wallet Unit reaches the PID and other EAAs

For: Developers, solution architects, and product managers building or integrating EUDI Wallet issuance, PID provision, and verification flows, who need to understand what actually happens when a wallet is lost, stolen, or compromised.

Revoking a PID is not a single switch. When a Wallet Unit is lost or breached, the credentials already issued to it have to lose their validity too, but no single party can flip them all at once. Instead, revocation travels down a chain: the Wallet Provider revokes the Wallet Unit, the PID Provider notices and revokes the PID, and the Relying Party, checking only the PID, sees the result. This article explains that chain, why it is built the way it is, and how each link is held together by the specifications.

Try it, and read on

You can watch every step of it, and try each scenario yourself, in the Revocation Chaining Simulator.

This article builds on two companions: the Wallet Unit Attestation (WUA) and WSCA and WSCD.

1.0 The problem: Revocation is not a single action​

In the EUDI Wallet ecosystem no one party owns the whole picture [1]. The Wallet Provider makes the wallet, but it never sees the contents: it cannot read, let alone revoke, the PID stored inside. The PID Provider issued the PID, but it does not run the device and cannot tell, on its own, that the phone was stolen last night. The Relying Party trusts a PID at presentation time, but it has never met the wallet and is not allowed to see the wallet's own attestations.

So when a device is lost, three different actors each hold one piece of the answer, and the design has to make them act in the right order without any of them overstepping. That ordered propagation is what we call revocation chaining.

A useful way to hold it in mind: the Wallet Provider knows the wallet is gone, the PID Provider is the only one who can revoke the PID, and the Relying Party is the only one who needs the final answer. Chaining is how a fact known at the top reaches the party at the bottom.

2.0 The chain in one picture​

The revocation chain in six steps: a cause is raised, the Wallet Provider revokes the Wallet Unit by setting the WIA and KA status-list indices, the WIA and KA status flip, the PID Provider polls those indices every 24 hours and revokes the PID, the PID status flips, and the Relying Party sees a revoked PID.

Figure 01: Revocation propagates in six steps. A cause is raised, the Wallet Provider revokes the Wallet Unit by setting the WIA and, where relevant, KA status-list indices, the PID Provider polls those indices every 24 hours and revokes the PID, and the Relying Party, checking only the PID status, sees a revoked credential. Two links hold the chain together, marked A and B.

The chain has six steps and, crucially, two links where responsibility passes from one party to the next. Everything else is plumbing. Get the two links right and the rest follows.

Try it: open the simulator in Single mode, pick a cause, and press Revoke the Wallet Unit. Watch the outcome propagate down the six stages, and click any WIA, KA, or PID to read the real, signed token that carries its status reference.

The first link is a legal obligation made technical. A PID Provider must check the revocation status of both the WIA and the KA it received during issuance, at least once every 24 hours, for the entire validity period of the PID; if either has been revoked, it must revoke the PID [2] [3]. This is what turns "the Wallet Provider revoked the wallet" into "the PID is now revoked". The Wallet Provider never touches the PID; it only changes the status of the Wallet Unit, and the PID Provider does the rest.

The second link is what makes the whole scheme usable at presentation time. A Relying Party checks only the PID's own status; it never sees the WIA or the KA. The ARF is explicit that this is enough: by verifying the revocation status of the PID, the Relying Party implicitly verifies the revocation status of the Wallet Unit [1]. The chain collapses a multi-party trust question into a single status check that any Relying Party already knows how to make.

4.0 What makes the chain possible: status lists and the maintenance period​

4.1 Three Token Status Lists, two owners​

Every WIA, KA, and PID carries a reference to an entry in a Token Status List [4]: a published, indexed array where each position records whether one attestation is valid or revoked. Revoking something does not change the token in the holder's wallet; it flips the bit at that token's index in the list the issuer publishes.

There are three lists, owned by two parties.

Two owners and three status lists: the Wallet Provider maintains the WIA status list and the KA status list and revokes a Wallet Unit by setting the relevant indices; the PID Provider maintains the PID status list and, during its 24-hour check, reads the Wallet Provider lists and sets the PID index if it sees a revocation; a Relying Party reads only the PID list.

Figure 02: The Wallet Provider maintains the WIA status list and the KA status list, and revokes a Wallet Unit by setting the relevant indices. The PID Provider maintains the PID status list; during its 24-hour check it reads the Wallet Provider's lists and, if it sees a revocation, sets the PID's own index. A Relying Party only ever reads the PID list.

The KA list is worth a closer look. A Wallet Provider can use a type-shared index, where all Key Attestations describing the same WSCD or keystore category share one index, or a per-KA index, where each Key Attestation has its own [2]. The choice matters at scale: with a type-shared index, a single flip revokes every wallet of that type at once.

Try it: switch the simulator to Population mode to see all three status lists at once across a fleet of citizens, grouped by key storage (WSCD A, WSCD B, or a device Keystore). Toggle between the type-shared and per-KA index models and revoke a WSCD type to watch one index flip take out an entire group.

4.2 The maintenance period​

Link A only works if the WIA and KA are still checkable for as long as the PID lives. That is guaranteed by a commitment separate from the token's own short lifetime: the WIA and KA each carry a maintenance period during which the Wallet Provider promises to keep the status entry up to date [1] [2]. The rule that ties it together is that the PID's technical validity must end before both the WIA maintenance period and the KA maintenance period. A WIA can therefore be valid for only a few hours as a freshness check while its status remains maintainable for the whole life of any PID issued against it.

5.0 How the Wallet Provider revokes: causes and granularity​

5.1 The causes​

The Wallet Provider revokes a Wallet Unit at least in these circumstances [1]:

  • The user asks for it, typically after losing the device or having it stolen.
  • The security of the Wallet Unit is breached or compromised, detected through the Wallet Provider's own monitoring.
  • A PID Provider requests it because the person using the wallet has died.
  • The Wallet Solution is suspended (optionally) or withdrawn (mandatorily).

5.2 What gets set, and how widely​

Revocation is not all-or-nothing. Depending on the cause, the Wallet Provider sets different indices [1]:

  • To revoke the whole Wallet Unit, it revokes the Wallet Instance by setting its WIA index.
  • If a single Wallet Secure Cryptographic Device is breached, it revokes that device and the Wallet Instance using it.
  • If a whole type of device is breached, it revokes every Wallet Instance using a device of that type. With a type-shared KA index this is a single flip.
  • If a keystore is breached, it revokes that keystore, and normally the Wallet Instances using it as well.

5.3 Revoking narrowly: The keystore case​

There is one important exception, and it is the clearest illustration of why the chain is more subtle than "revoke everything". If a keystore is breached, the Wallet Provider may, on the basis of a documented risk analysis, decide not to revoke the Wallet Instance. In that case only the attestations bound to that keystore are impacted, and the presentation of the PID remains available to the user [1].

Two outcomes side by side. On the left, a lost device or instance breach: the WIA is revoked, the KA is valid, and the PID is revoked. On the right, a keystore breach with a risk analysis: the WIA is valid, the KA for that keystore is revoked, and the PID stays valid because only keystore-bound attestations are affected.

Figure 03: Two outcomes. On the left, a lost device: the WIA is revoked, so the PID Provider revokes the PID. On the right, a risk-analysed keystore breach: the KA for that keystore is revoked but the WIA stays valid, the PID Provider sees nothing to act on, and the PID keeps working.

Try it: in the simulator, choose the cause Keystore breach, risk analysis keeps the PID usable and revoke. The KA index flips red, but the WIA and PID stay green, and the Issuer summary reports zero PIDs revoked. Compare it with User reports a lost or stolen device to see the whole chain go red instead.

6.0 How the PID Provider keeps the PID in step​

Link A is a loop the PID Provider runs for the life of every PID [2] [3]:

  1. At issuance, keep the WIA and KA the wallet presented, along with their status references.
  2. At least every 24 hours, fetch each Token Status List and read the bit at the recorded index.
  3. Also check that the Wallet Provider has not been suspended or cancelled on its Trusted List.
  4. If the WIA is revoked, or the KA is revoked, or the Wallet Provider is suspended or cancelled, revoke the PID.

Because the maintenance period (Section 4.2) guarantees the lists stay answerable for the whole life of the PID, this loop cannot be starved of information. And because the PID Provider writes to its own status list, the revocation it makes is immediately visible to every Relying Party through Link B.

7.0 The chain runs one way​

Chaining flows downward only. Revoking, expiring, or deleting a PID does not revoke the Wallet Unit; it simply moves the Wallet Unit from the Valid state back to Operational, and expiration and revocation are independent transitions [1]. Nor is the obligation universal: only the PID Provider is required to chain revocation from the Wallet Unit. Other Attestation Providers may apply the same 24-hour discipline to give Relying Parties the same assurance, but they are not obliged to.

8.0 Try it: The Revocation Chaining Simulator​

The Revocation Chaining Simulator turns everything above into something you can operate. It builds real, signed tokens in the browser, so the WIA, KA, and PID you click into genuinely decode and verify.

  • Single mode traces one citizen through the six-stage chain, showing the result of each step and its exact specification citation.
  • Population mode applies the same cause to a fleet of citizens over the three Token Status Lists, so you can see a WSCD type breach revoke a whole cohort while a single loss revokes just one, and watch the Issuer's behaviour summarised as "revoked N of M".

Suggested experiments:

  • Revoke with lost or stolen device and follow the red result down the chain.
  • Switch to Keystore breach, risk analysis keeps the PID usable and confirm the PID survives.
  • In Population mode, flip between type-shared and per-KA KA indices and revoke a WSCD type to feel the difference in blast radius.
  • Click a PID to see its own status claim, the index the PID Provider flips in Link A.

9.0 Conclusion​

Revocation chaining is the mechanism that lets a decentralised ecosystem behave coherently when a wallet is lost. No single party revokes everything; instead, the Wallet Provider changes the Wallet Unit's status, an obligation (Link A) turns that into a PID revocation, and a single status check (Link B) delivers the result to the Relying Party. Token Status Lists and the maintenance-period commitment are what make the links reliable, and the granularity rules, including the risk-analysed keystore case, are what keep revocation proportionate. If you remember one sentence: revoking a Wallet Unit does not revoke a PID directly, it obliges the PID Provider to, and the Relying Party only ever needs to ask about the PID.

References​

  1. European Digital Identity Wallet Architecture and Reference Framework (ARF) 2.9.0. See in particular Sections 4.6.4, 4.6.6, 6.5.3.4, 6.5.3.5, 6.5.4.2, and 6.6.2.4.
  2. Technical Specification 3: Wallet Unit Attestation (TS3), v1.5. See Sections 2.4.2, 2.4.3, 2.5.1, and 2.5.2.
  3. Commission Implementing Regulation (EU) 2024/2977, Article 5(4)(b): a PID Provider must revoke a PID when the Wallet Unit to which it was issued is revoked.
  4. IETF Token Status List (OAuth Status List), the status mechanism referenced by TS3 for WIAs, KAs, and issued credentials.
  5. OpenID for Verifiable Credential Issuance (OpenID4VCI) v1.0, the issuance protocol that TS3 profiles.
  6. Regulation (EU) 2024/1183 (eIDAS 2.0), the regulatory basis for the EUDI Wallet.