Skip to content

Wallet Activation

This flow describes the wallet initialization process for the initial start-up of the wallet app after installation including the wallet activation.

Design Decisions

In the Wallet Activation process, the Wallet Instance (WI) initializes security-relevant components and establishes connections to its backend services, such that it is ready for use.

The Wallet Instance (WI) and the Wallet Provider Backend (WB) collaboratively needs to ensure the security capabilities and current state of the device it is running on with the aim to enable level of assurance high for the PID Issuance. To achieve this, the WI registers at the WB and performs security verifications using mobile platform mechanisms to get a wallet attestation issued. Additionally, the WI is protected using a Runtime Application Self-Protection (RASP) module, that monitors the security posture of the user device and WI locally and reports to the RASP backend, which is connected to the Wallet solution. If the security posture of the user device or WI is insufficient, the wallet activation will be aborted.

The processes of wallet activation additionally involve the user:

  • the user is required to set up the platform authenticator of the mobile operating system for device unlock, if they have not already done so
  • the user is asked to set up a method to revoke the means of authentication provided with the wallet, e.g. in case if the device is lost
  • the user is shown the introduction screens explaining the features and functionalities of the wallet app

However, the Remote WSCD registration is not part of the wallet activation (despite it being an initialization step described in the ARF). The reasoning behind this relates to the fact, that the Remote WSCD should only be used for high-assurance credentials requiring the additional security level, while other credentials should be secured using local native key stores. As the user sets their RWSCD-PIN (user_rwscd_pin) during this registration, UX tests have revealed that it is advantageous to delay this process to the PID issuance, such that users connect the RWSCD-PIN with the PID credential. In a feature-complete wallet, user's first use case may not involve the PID and thus a Remote WSCD account may not be necessary from the start.

ToDo

  • add some details on platform authenticator
  • clarify how to do early refusal if WI does not fulfill requirements by MDVM
  • integrate terms and conditions check

Data Flow

This section described the data flow of the wallet initialization in a sequence diagram and a more detailed table. Artifacts in italics are further explained in the data register chapter

Sequence Diagram

Wallet ActivationWallet ActivationUserWallet Instance . App .WI.Wallet Backend .WB.Runtime Application SelfUserUserWallet Instance / App (WI)Wallet Instance / App (WI)Wallet Backend (WB)Wallet Backend (WB)Runtime Application SelfProtection backend (RASP)Runtime Application SelfProtection backend (RASP)(001)open wallet(002)initialize RASP SDK(003)register at RASP backend and receiverasp_instance_id(004)check platform authenticator setup(005)wallet registration(006)issuance of wallet instanceattestation (WIA)(007)show introduction/new featuresscreens(008)offer and chose wallet revocationoptions(009)setup wallet revocation

Detailed Description

No Description
001 The user opens/launches the Wallet Instance / App.
002 The WI initializes the RASP SDK to start local runtime self protection. This step should happen immediately after app launch to enable root detection for the whole wallet activation flow.
003 The WI queries the RASP backend for registration through the RASP SDK. Within this process the RASP backend and RASP SDK establish a secure authenticated channel, e.g. using certificate signing requests. If the RASP backend attests the particular device running the SDK, it confirms the registration by providing a rasp_instance_id.
004 The WI checks that the platform authenticator of the operating system (Android/iOS) is set-up for device unlock. The check does not actually trigger the user to perform the authentication, as the user previously authenticated when unlocking the device. If the platform authenticator is not set-up, the user is directed to the settings page of the operating system. The wallet initialization only continues, once the platform authenticator is successfully set up. See Platform Authenticator for details.
005 The WI registers at the WB, establishing a persistent account secured by user device bound key. See Wallet Registration for details.
006 The WI requests the issuance of Wallet Instance Attestations (WIA) from the WB by proving its integrity and authenticity. See Wallet Attestation for details.
007 The WI shows screens for introduction or new features to the user. The screens should only be shown once.
008 The WI is offering and explaining possible options for revocation of the wallet as an authentication means to the user and the user is choosing one of the mechanisms for wallet revocation and follows the steps to set it up.
009 The WI and WB set up the chosen revocation mechanism. See Wallet Revocation for details.

Platform Authenticator