Arf Topic T Support And Maintenance By Wal Part 1

1.2 Key words

This document uses the capitalised key words 'SHALL', 'SHOULD' and 'MAY' as specified in RFC 2119, i.e., to indicate requirements, recommendations and options specified in this document.

In addition, 'must' (non-capitalised) is used to indicate an external constraint, for instance a self-evident necessity or a requirement that is mandated by an external document. The word 'can' indicates a capability, whereas other words, such as 'will' and 'is' or 'are' are intended as statements of fact.

1.3 Document structure

This document is structured as follows:

• Chapter 2 introduces support and maintenance expectations set on Wallet Providers based on the [European Digital Identity Regulation] and the ARF, and lists the Annex 2 HLRs found to relate (also, in addition to their home topic) with support and maintenance on the latest ARF version (2.6.0).
• Chapter 3 opens the discussion whether specific high-level requirements are desirable.
• Chapter 4 will list the additions and changes that will be made to the ARF as a result of discussing this topic with Member States.

2. Existing requirements related to Wallet Provider's support and maintenance duties

2.1 Regulatory requirements

The [European Digital Identity Regulation] specifies related to support and maintenance duties of the Wallet Providers as follows:

Article 5a (10): "Providers of European Digital Identity Wallets shall ensure that users can easily request technical support and report technical problems or any other incidents having a negative impact on the use of European Digital Identity Wallets.

Article 5a (14) states on data minimisation and logical separation of any personal data and other data held by the Wallet Provider: "Users shall have full control of the use of and of the data in their European Digital Identity Wallet. The provider of the European Digital Identity Wallet shall neither collect information about the use of the European Digital Identity Wallet which is not necessary for the provision of European Digital Identity Wallet services, nor combine person identification data or any other personal data stored or relating to the use of the European Digital Identity Wallet with personal data from any other services offered by that provider or from third-party services which are not necessary for the provision of European Digital Identity Wallet services, unless the user has expressly requested otherwise. Personal data relating to the provision of the European Digital Identity Wallet shall be kept logically separate from any other data held by the provider of the European Digital Identity Wallet.

..."

2.2 Sections in the ARF related to Wallet Solution and Wallet Unit lifecycle management

The Trust model discussion in the ARF main text (Section 6) has the following lifecycle management related subsections, and although not directly mentioning the support duties of the Wallet Provider, may be relevant for this topic:

Section 6.2.3 of the main document discusses what happens on Wallet Unit level if a Wallet Provider is cancelled or suspended. Informing duty by the Wallet Provider of such event for the Wallet Users is defined in Annex 2/Topic 38 part B part of the ARF.

Section 6.5 of the main document discusses Wallet Unit lifecycle related trust. Once a Wallet User has a Wallet Unit in Operational or Valid state, the Wallet Unit is managed by the User and the Wallet Provider, and this management includes at least revoking the Wallet Unit when necessary.

The ARF sub-section 6.5.4 covers the details (bold text effect added by the editor):

The Wallet Provider is responsible at least to:

• perform installation of a new version of the Wallet Solution as necessary - this is mentioned in Topic 40 part C, WIAM_11.
• update the WUAs as necessary - covered in Topic 9.
• revoke the Wallet Unit in case its security is compromised - covered in Topic 38.

Management will also include regular updates of the Wallet Instance application to ensure its continued security and functionality.

No technical requirements are currently specified regarding e.g. automatic installation of Wallet Solution updates and their regularity, or on conducting constant monitoring on the health level of the overall Wallet Solution via analysis of the operational Wallet Instances in the installed base.

2.3 Existing high-level requirements in the ARF

The following HLRs were found relevant for the topic of support and maintenance (involving either the Solution management, informing the Wallet User or providing lifecycle support for the Wallet Solution) under existing Annex 2 topics.

2.3.1 Topic 9

Topic 9 covers HLRs for Wallet Unit Attestation (WUA). WUA_03 below relates to (invisible to the Wallet User) readiness maintenance by the Wallet Provider (for ensuring a valid WUA at all times).

2.3.2 Topic 38

Topic 38 covers HLRs addressing Wallet Unit revocation. HLRs having a link between the Wallet Provider and Wallet User have been picked for this topic discussion

2.3.3 Topic 40

Annex 2 Topic 40 discusses requirements related to the installation of a Wallet Instance by the User, the subsequent activation of the Wallet Unit by the User and the Wallet Provider, and the management of the Wallet Unit throughout its lifetime. Part C covers high-level technical requirements for Wallet Unit management in WIAM_11 - WIAM_21, of which the maintenance & support related are listed below in Section 2.3.

3 Discussion

3.1 Non-functional requirements

The support and maintenance functions of the Wallet Provider are in the current ARF mostly implicit and embedded under technical topics that either link to issuance, revocation or lifecycle management of technical artefacts (functional requirements under various topics).

Some functions of a Wallet Provider related to sustained customer support, data protection and active engineering towards keeping the Wallet Instances of an Wallet Solution up to date are part of Wallet certification. This is covered via implementing acts and by the Member States' national certification schemes, and are beyond the mandate of the [European Digital Identity Regulation]. Thus, the ARF will not list non-functional requirements for the topic(s).

3.2 Wallet Instance maintenance related data collection

Wallet Solution maintenance requires monitoring of the solution functions by the Wallet Provider, including Wallet Instances used by the users. It is customary for the mobile application developers to collect limited bug and error reports at runtime for improvement purposes (the development team will receive these and prioritise error fixes according to professional error severity analysis). Error logs collected should never contain personal data of the User. Question of what data of the Wallet User, or of the Wallet Instance should be monitored for this purpose was discussed in the first meeting to collect suitable data points, and are documented in table 1.

In case the Wallet Instance is run mostly remote (at the Wallet Solution Provider server with associated HSM), the Wallet Instance can be just a 'viewer' app, and therefore multiple apps can be viewed as the same Wallet Instance. Nevertheless, the ARF defines (see topic 38, WURevocation_09) how the Wallet Provider must handle situation where one 'viewer app', one part of its components is no longer secure - The Wallet Unit is revoked entirely in case the data collected from a single device/app triggers need to revoke an individual app instance.

List of possible data types to be collected, reasons for collection and how the Wallet Instance monitoring should occur (frequency, mechanisms, should the collection require Wallet User's approval beyond standard app vendor practices) is collected in the following table, and is recommended to be added to section 6.5.3.2 of the ARF:

Table 1. Data recommended for maintenance related Wallet Unit -level monitoring

3.2.1 Crash logs

Device OS-dependent app crash logs will probably collect a rich set of data (many of listed items above) automatically. App developers should write custom crash logs for sending them to Wallet Provider's server for further analysis. For iOS developers see article Acquiring crash reports and diagnostic logs, and respectively Android vitals for Android/Google Play distributed apps. Beyond baseline tools, several third party tools exist for creating developer-friendly crash report analytics.

A new HLR on custom crash logs is suggested for inclusion under the topic (see section 4.1, WPSM_02).

3.3 Monitoring data for the Wallet Unit's security posture

3.3.1 Backgrounder - the PDS2 Directive

The need to track the security posture of a Wallet Unit was initially raised in topic AA discussion on strong customer authentication and related requirements from the regulation that applies to the European financial institutions, especially the Payment Service Providers (PSPs). The [RTS SCA] contains generic requirements for PSPs in Article 2 to have transaction monitoring mechanisms to detect unauthorised or fraudulent transactions:

1. Payment service providers shall have transaction monitoring mechanisms in place that enable them to detect unauthorised or fraudulent payment transactions for the purpose of the implementation of the security measures referred to in points (a) and (b) of Article 1. Those mechanisms shall be based on the analysis of payment transactions taking into account elements which are typical of the payment service user in the circumstances of a normal use of the personalised security credentials.

2. Payment service providers shall ensure that the transaction monitoring mechanisms take into account, at a minimum, each of the following risk-based factors: (a) lists of compromised or stolen authentication elements; (b) the amount of each payment transaction; (c) known fraud scenarios in the provision of payment services; (d) signs of malware infection in any sessions of the authentication procedure; (e) in case the access device or the software is provided by the payment service provider, a log of the use of the access device or the software provided to the payment service user and the abnormal use of the access device or the software.

The ARF does not cover for fraud or risk signals collection from the Wallet Units or making them available to Relying Parties such as PSPs. Technically collection and delivery would be feasible and could be done at the Wallet Providers discretion, but the very intent of [European Digital Identity Regulation] to maximise privacy preservation in the EUDI ecosystem prevents this. Fraud signal detection for payment services is not in the ARF scope, and there is no intention to include a complete set of requirements related to this topic.

3.3.2 Security posture of Wallet Instance

Although complete fraud or risk signal collection is not in scope of the ARF, it is recommended for and in the interests of the Wallet Providers to keep an active understanding of individual Wallet Instance's security posture, if this can be done with a privacy-preserving approach, in a similar way used with other eID means (where e.g. user device IP address monitoring is conducted by the Relying Parties for the purpose of security anomaly detection).

A Wallet Unit is a unique configuration of a Wallet Solution that includes Wallet Instances. The Wallet Instance is the application installed and configured on a Wallet User’s device or environment. The presented data or tool types in this paper in some cases mainly affect Wallet Instances, while Wallet Units might contain of multiple Wallet Instances (and multiple WSCDs/WSCAs).

Security posture monitoring done by the Wallet Providers offloads part of the detection tasks from the PSPs when it comes to their regulatory tasks, and allows the Wallet Providers to take care of at-risk Wallet Instances through technical means: Although not monitored in runtime similar to the payment applications and service providers, the Wallet Instances with high-risk or critical security posture level should be revoked at the Wallet Provider's earliest convenience, following at least the requirements set in the ARF Topic 38, which guide the Wallet Provider to revoke all Wallet Instances of the Wallet Unit. A compromised Wallet Instance is thus seen in the ARF as compromising the entire Wallet Unit.

We suggest to add new high-level requirements on security posture monitoring for the Wallet Providers to check regularly a relevant set of security information about the Wallet Instance as part of the support and maintenance function.

A collection of fraud or risk signal related information used in context of mobile devices is collected below to table 2, with indication whether the data should be collected by the Wallet Provider under the proposed new HLRs on security posture monitoring.

Table 2. Information typically screened to execute fraud signal analysis on mobile devices

Note that this paper takes no position over what information e.g. Relying Parties can and should monitor - either enforced through their domain-specific, enforcing regulation or internal security processes.

Several of the signals are related to User behaviour patterns and thus will have no real value to the Wallet Provider (to conclude on the security posture of the User's device). Taking into account this aspect, as well as expectation of strict Wallet User privacy preservation with their use of a Wallet Solution, the table 2 brings in the minimal additional list of monitorable security posture information compared to ones marked OK in table 1 earlier.

Other detection means are likely to be used by the Relying Parties such as payment service providers, which are able to monitor and check prior to providing access to the service not just the Wallet Instance they interact with, but related applications/services utilised as part of their use case. For example, malware detection (identifying a fraudulent/compromised Wallet, browser or other device software involved in the use case) and related blacklisting is very likely to happen also by the Relying Party's internal device posture check tools. In this case the ecosystem or business vertical should agree a common process for informing the Wallet Provider whose Wallet Instance has been compromised.

3.3.3 Criteria for mandatory revocation and suspension

The Wallet Provider should based on previous section build analysis mechanisms that allow continuous detection of changes in signals relevant to the security posture of Wallet Instances it has deployed. A potential, 4-level security posture framework that could be applied is introduced in table 3.

Table 3. Four-level Wallet Instance security posture framework.

Note 1: If the issue is with a key managed by a remote WSCD, then at least all Wallet Units managed by that WSCD should be revoked, even if only one abuse has been identified. Similarly, for the part of the Wallet Instance that is implemented remotely, any issue should impact all the Wallet Units managed by that server.

In case of compromised Wallet Instance the Wallet Provider shall disable the Wallet Instance from conducting transactions. The minimum mechanism specified by the ARF is revocation of the Wallet Unit Attestation (WUA) within 24 hours from identifying a risk. The Wallet Providers may have also other (more real-time) tools to disable a Wallet Unit when needed.

Wallet Provider shall consider the Wallet Unit as "Compromised" and initiate Revocation when there is a high probability that the private keys used for attestation, authentication, or signing have been leaked or accessed by an unauthorised entity.

Level 4 (Critical) is the designated threshold for mandatory Wallet Unit Revocation.

Mandatory revocation should according to the framework occur immediately when the Wallet Provider detects any of the following:

1. Confirmed Key Extraction/Leakage: The system detects evidence that the cryptographic material (e.g., the private key corresponding to the Wallet Unit Attestation (WUA) or the keys securing credentials) has been accessed outside of the device's local or local native WSCD.

2. Active Malicious Environment: The application is running on a rooted/jailbroken device and is simultaneously being actively debugged, manipulated, or monitored by a known attack tool. The combination of root access and active manipulation suggests an imminent threat to key material.

3. Unremedied High-Severity Breach: If the device state falls into the High-Risk (Suspended) category (e.g., detected tampering) and the user or system fails to mitigate the issue within a pre-defined, short window.

4. Security Component Failure: Confirmed, irrecoverable failure of the secure hardware module (local or local native WSCD) where the key material is stored.

The new HLRs are proposed in Section 4 below.