5.1.1. Wallet Solution Requirements

This section lists the requirements about Wallet Providers and Wallet Solutions with their Wallet Instances.

  • The Wallet Solution MUST adhere to the specifications set by this document for obtaining Personal Identification (PID) and (Q)EAAs.

  • The Wallet Provider MUST expose a set of endpoints, exclusively available to its Wallet Solution instances, supporting the core functionalities of the Wallet Instances.

  • The Wallet Instance MUST periodically reestablish trust with its Wallet Provider, obtaining a fresh Wallet Attestation.

  • The Wallet Instance MUST establish trust with other participants of the Wallet ecosystem, such as Credential Issers and Relying Parties, presenting a Wallet Attestation.

  • The Wallet Instance MUST be compatible and functional on both Android and iOS operating systems and available on the Play Store and App Store, respectively.

  • The Wallet Instance MUST provide a mechanism to verify the User's actual possession and full control of their personal device.

  • The Wallet Instance MUST provide Users with an up-to-date list of Relying Parties with which the User has established a connection and, where applicable, all data exchanged;

  • The Wallet Instance MUST provide Users with a mechanism to request the erasure of personal attributes by a Relying Party pursuant to Article 17 of Regulation (EU) 2016/679, and to log each Erasure Request made.

5.1.1.1. Wallet Attestation Requirements

Wallet Attestation contains information regarding the security level of the device hosting the Wallet Instance. It primarily proves the authenticity, integrity, security, and in general the trustworthiness of a particular Wallet Instance.

The requirements for the Wallet Attestation are defined below:

  • The Wallet Attestation MUST provide all the relevant information to attest to the integrity and security of the device where the Wallet Instance is installed.

  • The Wallet Attestation MUST be signed by the Wallet Provider that has authority over and is the owner of the Wallet Solution, as specified by the overseeing Registration Authority. This ensures that the Wallet Attestation uniquely links the Wallet Provider to this particular Wallet Instance.

  • The Wallet Provider MUST periodically evaluate and guarrantee the integrity, the authenticity, and the genuineness of the Wallet Instance. The Wallet Provider verifies the Wallet Instance using the most secure flow made available by OS Provider's API, such as the Play Integrity API for Android and App Attest for iOS.

  • The Wallet Provider MUST possess a revocation mechanism for the Wallet Instance, allowing the Wallet Provider to terminate service for a specific Instance at any time.

  • The Wallet Attestation MUST be securely bound to the Wallet Instance's ephemeral public key.

  • The Wallet Attestation MAY be used multiple times during its validity period, allowing for repeated authentication and authorization without the need to request new attestations with each interaction. However, it is RECOMMENDED that Wallet Instances avoid using the same attestation repeatedly, due to privacy concerns such as linkability between different interactions.

  • The Wallet Attestation not implementing revocation check methods, MUST be short-lived and MUST have an expiration time, after which it MUST no longer be considered valid.

  • The Wallet Attestation MUST NOT be issued by the Wallet Provider if the authenticity, integrity, and genuineness of the Wallet Instance requesting it cannot be guaranteed.

  • Each Wallet Instance SHOULD be able to request multiple Wallet Attestations using different cryptographic public keys associated with them.

  • The Wallet Attestation MUST NOT contain information about the User in control of the Wallet Instance.

  • The Wallet Instance MUST secure a Wallet Attestation as a prerequisite for transitioning to the Operational state, as defined by EIDAS-ARF.

Note

Throughout this section, the services used to attest genuineness of the Wallet Instance and the device in which it is installed are referred to as Device Integrity Service API. The Device Integrity Service API is considered in an abstract fashion and it is assumed to be a service provided by a trusted third party (i.e., the OS Provider's API) which is able to perform integrity checks on the Wallet Instance as well as on the device where it is installed.

5.1.1.2. WSCD Requirements

To guarantee the utmost security, the cryptographic keys associated with a Wallet Instance (e.g., used to generate the Wallet Attestation) MUST be securely generated and stored within the Wallet Secure Cryptographic Device (WSCD). Only the legitimate User can access the private cryptographic keys, preventing unauthorized usage or tampering. The WSCD MAY be implemented using at least one of the approaches listed below:

  • Local Internal WSCD: The WSCD relies entirely on the device's native cryptographic hardware, such as the Secure Enclave on iOS, or the Trusted Execution Environment (TEE) and Strongbox on Android.

  • Local External WSCD: The WSCD is hardware external to the User's device, such as a smart card compliant with GlobalPlatform and supporting JavaCard.

  • Remote WSCD: The WSCD utilizes a remote Hardware Security Module (HSM).

  • Local Hybrid WSCD: The WSCD involves a pluggable internal hardware component within the User's device, such as an eUICC that adheres to GlobalPlatform standards and supports JavaCard.

  • Remote Hybrid WSCD: The WSCD involves a local component mixed with a remote service.

Warning

At the current stage, the implementation profile defined in this document supports only the Local Internal WSCD. Future versions of this specification MAY include other approaches depending on the required Authenticator Assurance Level (AAL).

For more detailed information, please refer to Wallet Instance Initialization and Registration and Wallet Attestation Issuance of this document.