Skip to content

3.1.4 Wallet Deletion

This flow describes the deletion of the Wallet Instance, which consists of two independent parts: the user deletes the Wallet Instance app from the device and the accounts at the backends are deleted according to the data retention policy.

Design Decisions

The Wallet Deletion is performed by the user deleting (uninstalling) the Wallet Instance app. The mobile operating system deletes the app storage and all keys of the app in the local Hardware Key Store (HKS), including the possession factor wi_mdvm_auth_prvk, the holder binding keys wi_eaa_device_prvk and the encryption at rest key wi_data_enc_symk. As all sensitive data of the WI is encrypted with wi_data_enc_symk (see encryption at rest), any residual data that survives the uninstall, e.g. in a backup, cannot be decrypted anymore. The WI currently offers no separate deletion flow in the app.

The user is additionally advised to discard the wb_wi_revocation_code in the terms and conditions, i.e. to delete the PDF file or the entry in the password manager, as it is no longer needed once the wallet is deleted.

As the uninstall of the app is not reported to the app by the operating system, the WI cannot request the deletion of its accounts at the point in time when the user deletes the wallet. Instead, the account records at the backends are subject to a data retention policy and are deleted once the Wallet Instance has been inactive for the retention period, see backend deletion.

The Wallet Deletion has to be distinguished from the Wallet Revocation:

  • the revocation is an out-of-band mechanism for the case that the user has lost the access to its device. It blocks the accounts at the backends and the credentials are revoked at the PID/EAA Providers through revocation chaining.
  • the deletion removes the Wallet Instance and all of its local data from the device. The PID/EAA Providers do not learn about the deletion and no revocation chaining is triggered, so the credentials are not revoked. This is not a security problem, as the deletion of the app destroys all device binding keys in the local HKS and the *rwsca_bound_wrapped_key*s, so that no remaining copy of a credential could be presented anymore.

Backend Deletion

The Wallet Instance holds an account at each of the four backends (MDVM, WB, RWSCA and PNS), which are deleted based on the last activity of the Wallet Instance. The MDVM stores a last-seen timestamp for each account in its MDVM account database, which is updated on every successful MDVM operation of the WI. To keep the last-seen timestamp up-to-date, the WI renews its mdvm_token on app start-up, if the last successful renewal is older than one month (without this renewal, the timestamp would only reflect the last use of a backend operation, e.g. an PID/EAA issuance or PID presentation, but EAA presentations do not require backend interaction). The retention period is 3 years without any contact of the Wallet Instance. This accounts for un-used and revoked Wallet Instances alike.

The MDVM regularly scans its account database for accounts that exceeded the retention period and publishes a purge event for each of them to the purge queue. All four backends consume these events and execute their respective Purge Account operations (WB, RWSCA, MDVM and PNS), analogous to the revocation propagation between backends.

Data Flow

This section describes the data flow of the deletion of the backend accounts in a sequence diagram and a more detailed table. Artifacts in italics are further explained in the data register chapter

Sequence Diagram

Backend DeletionMobile Device Vulnerability Management .MDVM.MDVM account databaseMessage Queue .MQ.Mobile Device Vulnerability Management (MDVM)Mobile Device Vulnerability Management (MDVM)MDVM account databaseMDVM account databaseMessage Queue (MQ)Message Queue (MQ)(001)scan for accounts that exceeded the retention period(002)publish purge events containing the JWK thumbprints of the affectedwi_mdvm_auth_pubk

Detailed Description

No Description
001 The MDVM regularly scans the MDVM account database for accounts whose last-seen timestamp, or whose timestamp of the revocation event for accounts with a REVOKED mdvm_wi_state, is older than the retention period of 3 years, see backend deletion.
002 The MDVM publishes one purge event per affected Wallet Instance to the purge queue. Each event contains the JWK thumbprint of the wi_mdvm_auth_pubk, which identifies the Wallet Instance across all backends, see message queue for details on the identification of Wallet Instances between the backends.