Skip to main content
Lifecycle

Revocation Chaining Simulator

How revoking a Wallet Unit cascades to the PID. The Wallet Provider flips the WIA and KA status lists, the PID Provider polls them every 24 hours and revokes the PID, and the Relying Party sees only the PID status, implicitly the Wallet Unit status. Pick a cause, revoke the Wallet Unit, and click any artefact to read the token that carries the status reference. Grounded in EU ARF 2.9.0 and TS3 v1.5.

User, to the Wallet ProviderRevokes the Wallet Instance by setting its WIA index in the status list.Affected wallet units: This Wallet Unit only
1TriggerARF §6.5.4.2
A revocation cause occurs
Loss or theft, a security breach, the subject dying, or the Wallet Solution being withdrawn.
↓
2Wallet ProviderARF §6.5.4.2, TS3 §2.4.2
Revokes the Wallet Unit
Sets the WIA index, and depending on the cause the KA index, in the published status list. Revocation cannot be undone.
↓
3WUA status listsARF §6.5.3.4, §6.5.3.5; TS3 §2.5
The WIA and KA status flip
WIA
client_status
Wallet Instance index set in the WIA status list.
KA
key_storage_status
Not flipped for this cause; the KA index stays valid.
↓
4PID ProviderTS3 §2.4.3; CIR 2024/2977 Art 5(4)(b)
Polls the WIA and KA every 24 hours
Re-checks the WIA and KA it kept from issuance for the whole PID validity; if either is revoked (or the Wallet Provider is suspended), it must revoke the PID.
↓
5PIDARF §6.6.2.4
The PID status flips
The PID Provider sets the PID index in its own status list (the credential status claim).
↓
6Relying PartyARF §6.6.2.4
Sees a revoked PID
The Relying Party checks only the PID status. By verifying it, it implicitly verifies the revocation status of the Wallet Unit.

The chain runs one way. Revoking, expiring or deleting a PID does not revoke the Wallet Unit; it only moves it from Valid back to Operational (ARF §4.6.4, §4.6.6). Only the PID Provider is obliged to chain revocation; other Attestation Providers may, but need not. Slide to Population to see the same cause across a fleet.