Topic H - Transaction logs kept by the Wallet
(Version 1.0, updated 9 July 2025)
1 Introduction
1.1 Discussion Paper Topic Description
This document is the Discussion Paper for the European Digital Identity Cooperation Group regarding Topic H: Transaction logs kept by the Wallet.
The ARF Development Plan [ARF_DevPlan] describes this Topic as follows:
Define High-level requirements for implementing transaction logs generated by the wallet. Key trade-offs need consideration, including balancing the availability of logs that enable users to request data deletion from a Relying Party (RP) against the risk of that data potentially being exposed, particularly to the Wallet Provider. Similarly, there is a trade-off between ensuring data availability if a user changes devices and mitigating the associated risks of data exposure.
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', 'is' or 'are' are intended as statements of fact.
1.3 Document Structure
The document is structured as follows:
-
Chapter 2 presents the legal requirements for functionality related to transaction logs kept by the Wallet.
-
Chapter 3 presents and discusses a list of identified issues, with suggested changes and/or new High-Level Requirements related to this topic.
-
Chapter 4 presents a log of the additions and changes that will be made to High Level Requirements in the ARF as a result of discussing this topic with the Member States.
-
Chapter 5 refers to other topics related to transaction logs kept by the Wallet.
-
Chapter 6 presents the additions and changes that will be made to the ARF main document as a result of discussions.
2 Legal Requirements for transaction logs
2.1 [European Digital Identity Regulation] about transaction logs
The [European Digital Identity Regulation] requires the Wallets to:
- keep the history of transaction (a "transaction log"), to allow the User to track all transactions executed through the Wallet Unit,
- the transaction log shall contain at least:
- the time and date of the transaction,
- the counterpart identification,
- the personal data requested,
- the data shared,
- enable and support execution of User's privacy and data protection rights, as set out by [GDPR].
Below are the actual excerpts from the Regulation, including the recitals and the articles that establish these requirements.
Recital (13)
European Digital Identity Wallets should have the function of a common dashboard embedded into the design, in order to ensure a higher degree of transparency, privacy and control of the users over their personal data. That function should provide an easy, user-friendly interface with an overview of all relying parties with whom the user shares data, including attributes, and the type of data shared with each relying party. It should allow users to track all transactions executed through the European Digital Identity Wallet with at least the following data: the time and date of the transaction, the counterpart identification, the personal data requested and the data shared. That information should be stored even if the transaction was not concluded. It should not be possible to repudiate the authenticity of the information contained in the transaction history. Such a function should be active by default. It should allow users easily to request the immediate erasure by a relying party of personal data pursuant Article 17 of Regulation (EU) 2016/679 and easily to report the relying party to the competent national data protection authority where an allegedly unlawful or suspicious request for personal data is received, directly via the European Digital Identity Wallet.
Recital (15)
This Regulation sets out the harmonised conditions for the establishment of a framework for European Digital Identity Wallets to be provided by Member States. All Union citizens, and residents in the Union as defined by national law, should be empowered to securely request, select, combine, store, delete, share and present data related to their identity and request the erasure of their personal data in a user-friendly and convenient way, under the sole control of the user, while enabling selective disclosure of personal data. This Regulation reflects shared European values and respects fundamental rights, legal safeguards and liability, thus protecting democratic societies, Union citizens and residents in the Union. Technologies used to achieve those objectives should be developed aiming towards the highest level of security, privacy, user convenience, accessibility, wide usability and seamless interoperability.[...]
Recital (19)
[...] Reliance on the legal identity should not hinder European Digital Identity Wallet users to access services under a pseudonym, where there is no legal requirement for legal identity for authentication.[...]
Recital (32)
The use, free of charge, of European Digital Identity Wallets should not result in the processing of data beyond data that is necessary for the provision of European Digital Identity Wallet services. This Regulation should not allow the processing of personal data stored in or resulting from the use of the European Digital Identity Wallet by the provider of the European Digital Identity Wallet for purposes other than the provision of European Digital Identity Wallet services. To ensure privacy, European Digital Identity Wallet providers should ensure unobservability by not collecting data and not having insight into the transactions of the users of the European Digital Identity Wallet. Such unobservability means that the providers are not able to see the details of the transactions made by the user. However, in specific cases, on the basis of explicit prior consent by the user in each of those specific cases, and fully in accordance with Regulation (EU) 2016/679, providers of European Digital Identity Wallets could be granted access to the information necessary for the provision of a particular service related to European Digital Identity Wallets.
Article 5
Pseudonyms in electronic transaction
Without prejudice to specific rules of Union or national law requiring users to identify themselves or to the legal effect given to pseudonyms under national law, the use of pseudonyms that are chosen by the user shall not be prohibited.
Article 5a(4)
4.European Digital Identity Wallets shall enable the user, in a manner that is user-friendly, transparent, and traceable by the user, to: [...] (d) access a log of all transactions carried out through the European Digital Identity Wallet via a common dashboard enabling the user to: (i) view an up-to-date list of relying parties with which the user has established a connection and, where applicable, all data exchanged; (ii) easily request the erasure by a relying party of personal data pursuant to Article 17 of the Regulation (EU) 2016/679; (iii) easily report a relying party to the competent national data protection authority, where an allegedly unlawful or suspicious request for data is received;
Article 5a(16)
The technical framework of the European Digital Identity Wallet shall: (a) not allow providers of electronic attestations of attributes or any other party, after the issuance of the attestation of attributes, to obtain data that allows transactions or user behaviour to be tracked, linked or correlated, or knowledge of transactions or user behaviour to be otherwise obtained, unless explicitly authorised by the user; [...]
2.2 [CIR 2024/2979] about transaction logs
The [CIR 2024/2979] specifies the following requirements related to transaction logs:
- the Wallet Unit shall log data related to transactions,
- the log shall at least contain:
- the time and date of the transaction;
- the name, contact details, and the unique identifier of the corresponding wallet-relying party and the Member State in which that wallet-relying party is established, or in case of other wallet units, relevant information from the wallet unit attestation;
- the type or types of data requested and presented in the transaction;
- in the case of non-completed transactions, the reason for such non-completion
- the transaction logs should allow investigating of suspicious behaviour of Relying Parties, PID and Attestation Providers,
- the transaction log shall be protected to preserve integrity, authenticity and confidentiality,
- the transaction log shall be included in User's data backup and recovery processes, as well as migration from one Wallet Unit to another,
Below are the actual excerpts from the Regulation, including the recitals and the articles that establish these requirements.
Recital (11)
Logging transactions is an important tool to provide transparency, in the form of providing an overview of the transactions to the wallet user. Furthermore, logs should be used to enable the swift and easy sharing of certain information, at the request of the wallet user, with the competent supervisory authorities established pursuant Article 51 of Regulation (EU) 2016/679, in case of suspicious behaviour of wallet-relying parties.
Recital (13)
Data export and portability objects can log the person identification data and electronic attestations of attributes that have been issued to a particular wallet unit. These objects allow wallet users to extract the relevant data from their wallet unit in order to strengthen their right to data portability. Wallet providers are encouraged to use the same technical solutions to also implement backup and recovery processes for wallet units, making it possible to recover lost wallet units or to transfer information from one wallet provider to another, where appropriate and insofar as this can be done without impairing the right to data protection and the security of the digital identity ecosystem.
Article 9
Transaction logs
1. Irrespective of whether or not a transaction is successfully completed, wallet instances shall log all transactions with wallet-relying parties and other wallet units, including electronic signing and sealing.
2. The logged information shall at least contain:
(a) the time and date of the transaction;
(b) the name, contact details, and the unique identifier of the corresponding wallet-relying party and the Member State in which that wallet-relying party is established, or in case of other wallet units, relevant information from the wallet unit attestation;
(c) the type or types of data requested and presented in the transaction;
(d) in the case of non-completed transactions, the reason for such non-completion.
3. Wallet providers shall ensure integrity, authenticity and confidentiality of the logged information.
7. Wallet providers shall enable wallet users to export the logged information referred to in paragraph 2.
3 Discussion
3.1 Introduction
This topic has been discussed already in the context of Topic N - Export and Data Portability. Refer to Discussion Paper for more. The outcome of that discussion has been taken into account in this paper.
As presented in the chapter 2, the purpose of the transaction log is clearly defined: to enable user to view the history of transactions (together with information what Relying Parties received User's data and types of data) and to execute data protection rights. Other possible purposes, like using the log to investigate identity theft or other frauds, are out of the scope of ARF.
3.2 The scope of logging
According to Recital (13) of [European Digital Identity Regulation]
It should allow users to track all transactions executed through the European Digital Identity Wallet with at least the following data: the time and date of the transaction, the counterpart identification, the personal data requested and the data shared.
or Article 9 of [CIR 2024/2979]
2. The logged information shall at least contain:
(a) the time and date of the transaction;
(b) the name, contact details, and the unique identifier of the corresponding wallet-relying party and the Member State in which that wallet-relying party is established, or in case of other wallet units, relevant information from the wallet unit attestation;
(c) the type or types of data requested and presented in the transaction;
(d) in the case of non-completed transactions, the reason for such non-completion.
the scope of logged data is not closed and provides possibility to log more data.
The need to log additional data may be related for instance to:
- PID and Attestation deletion events,
- sending reports to DPAs,
- User's data export and import processes and Wallet Unit migrations,
- qualified electronic signatures and seals generated by or through the Wallet Unit.
Therefore it is justified and necessary that Wallet Units logs more data than literally listed in the above mentioned legal acts.
The ARF defines the following events to be logged:
- all types of transaction executed through the Wallet Unit: issuance and re-issuance transactions, presentation transactions, signature and seal creation transactions, attribute deletion requests sent to a Relying Party, and reports sent to a Data Protection Authority (DASH_02, DASH_2a, DASH_03, DASH_04, DASH_05, Mig_01),
- transactions related to qualified electronic signatures and seals generated by or through the Wallet Unit (QES_13),
- sending reports to DPAs (RPT_DPA_05),
- attribute deletion requests (DATA_DLT_05, DATA_DLT_06).
At the same time, as the result of discussion on Topic N, the scope of logged information is to cover also PID or Attestation deletion events (update of DASH_02).
Therefore, at this stage, general questions may be raised:
- Are there any other types of events that should be logged?
- Are there types of events that should NOT be logged?
Basing on the feedback, the following changes to HLRs are proposed to DASH_02:
- adding sealing transactions,
- adding signing and sealing certificate issuance transactions,
- rewording deletion transactions,
- adding Wallet-to-Wallet transactions.
See chapter 4.1 for the proposed new text of DASH_02.
3.3 The level of detail and privacy protection
Recital (32) of [European Digital Identity Regulation]
To ensure privacy, European Digital Identity Wallet providers should ensure unobservability by not collecting data and not having insight into the transactions of the users of the European Digital Identity Wallet. Such unobservability means that the providers are not able to see the details of the transactions made by the user. However, in specific cases, on the basis of explicit prior consent by the user in each of those specific cases, and fully in accordance with Regulation (EU) 2016/679, providers of European Digital Identity Wallets could be granted access to the information necessary for the provision of a particular service related to European Digital Identity Wallets.
as well as Article 5a(16)
The technical framework of the European Digital Identity Wallet shall: (a) not allow providers of electronic attestations of attributes or any other party, after the issuance of the attestation of attributes, to obtain data that allows transactions or user behaviour to be tracked, linked or correlated, or knowledge of transactions or user behaviour to be otherwise obtained, unless explicitly authorised by the user; [...]
require that the details of transactions shall not be visible to or accessible by Wallet Providers, which may be interpreted that the transaction log:
- should not contain details of transactions, or
- if such details are logged, they should be protected from being accessed by the Wallet Provider (or any actor other than the User) w/o an explicit consent of the User (and given separately for each specific case).
Currently the ARF already specifies number of detailed information that is to be logged, for instance in the requirements DASH_02, DASH_03 and other (see section 4). Therefore the ARF envisions User's consent, as defined in DASH_10:
| Index | Requirement specification |
|---|---|
| DASH_10 | The Wallet Unit SHALL make the logs accessible to the Wallet Provider if this is necessary for the provisioning of the Wallet Unit, and only after obtaining explicit consent from the User via the dashboard. |
To conclude, at this stage, general questions may be raised:
- Are there any situations that may require refraining from logging of (some) transaction details?
- Are the current HLRs sufficient in this context?
Basing on the feedback, the following changes HLRs are proposed:
- adding intended use information to the transaction log (modification of DASH_03),
- introducing a new HLR to clarify that actual data like attributes values or transactional data content shall not be logged (DASH_03c),
- deletion of DASH_10 and adding a new requirement WIAM_12a, that strengthens protection of the User's data in general, including the transaction log.
See chapter 4 for the proposed new text of DASH_03, DASH_03c and WIAM_12a.
3.4 Pseudonyms
[European Digital Identity Regulation] (eg. Recital (19), Article 5) gives the right to Users to use pseudonyms in transactions with the Wallet.
In ARF, this is addressed by the [Topic 11]. In particular, as presented in PA_08
| Index | Requirement specification |
|---|---|
| PA_08 | A Wallet Unit SHOULD enable to the User to manage pseudonyms within the Wallet Unit in a user-friendly and transparent manner. Users SHOULD be informed about when and with which Relying Party their pseudonyms were used and be able to view a complete transaction log (including canceled or unsuccessful transactions). |
the user shall be able to review all the transactions where the pseudonyms were used.
Therefore, for clarity and consistency, it is proposed to mention "pseudonym transactions" as part of the scope of transaction log in the HLR DASH_02, as well as to add a new requirement to provide scope of details for such type of event (DASH_03a).
At the same time, it is proposed to update PA_08, to replace "SHOULD" with "SHALL".
See chapter 4 for the proposed new text of DASH_02, DASH03a and PA_08.
3.5 Transaction log security
Referring again to Recital (32) and Article 5a(16) of [European Digital Identity Regulation] (see section 3.2), as well as Article 9(3)
3. Wallet providers shall ensure integrity, authenticity and confidentiality of the logged information.
the transaction log shall be protected.
In the current ARF (taking into account changes resulting from Topic N related discussion), there are requirements DASH_06 and Mig_05:
| Index | Requirement specification |
|---|---|
| DASH_06 | The Wallet Provider SHALL ensure the confidentiality, integrity, and authenticity of all transactions included in the log. |
| Mig_05 | The Wallet Unit SHALL store the Migration Object in such a way that its confidentiality, integrity and authenticity is protected and that it is protected against use by others than the User. Note: This could be done, for example, by using password-based cryptography to encrypt the object. |
that refers to protecting the transaction log and Migration Object (that contains also the transaction log) used in a Wallet Unit migration scenarios.
In this context we can imagine, that depending on the Wallet Solution architecture, the transaction logs can be stored:
- locally in a Wallet Unit,
- in a remote location - in case of a cloud-based Wallet Solution or due to security management reasons possibly (backup, archiving, audit purposes).
Therefore, at this stage, a general question may be raised:
- Is there a need for additional HLR(s) to address protection of transaction log itself?
Following the feedback, the current HLRs are sufficient in this respect. Only a minor change was introduced to DASH_07 in respect to log storage location (see chapter 4).
3.6 Log format
To enable migration between Wallet Units from different Wallet Solutions/Wallet Providers, the log format should be specified in a Technical Specification. Therefore, as part of the Topic N discussion, it was proposed to add a new HLR, as below:
| Index | Requirement specification | Proposal |
|---|---|---|
| DASH_2c | The Commission SHALL establish a technical specification for the common format of the log of transactions. | New requirement as proposed in Topic N Discussion (no further changes) |
The above requirement is being introduced to ARF.
3.7 Wallet to Wallet transaction logging
During the discussion, it was identified, that the transaction log should also include Wallet-to-Wallet transactions. Therefore, apart from modification of DASH_02 (see section 3.2), it is proposed to add a new HLR (W2W_08) - refer to chapter 4.7.
3.8 Transaction log deletion
ARF envisions for Users possibility to delete transactions from the log. This is contained in the requirement DASH_06a:
| Index | Requirement specification |
|---|---|
| DASH_06a | Via the dashboard, the Wallet Unit SHALL enable the User to delete any transaction in the log. The Wallet Unit SHALL ensure that no other entity can delete transactions from the log, except possibly for the reason mentioned in DASH_02a. |
Following the feedback, it is proposed to extend the requirements to
- to assure Users awareness about consequences of log deletion, such as hindering execution of data protection rights, as well as to offer and instruct how to export the log before deletion;
- clarify the relation of the User's right to delete the transactions in the log vs the log retention time requirements.
In result:
- modifications of DASH_06a and DASH_02a,
- creation of a new requirement DASH_06b
were proposed. Refer to chapter 4.1 for details.
4 Current HLRs and Proposals of Changes
ARF contains a number of High-Level Requirements related to the topic, included in the following sections:
- Topic 19 - User navigation requirements (Dashboard logs for transparency)
- Topic 34 - Migrate to a different Wallet Solution
- Topic 16 - Signing documents with a Wallet Unit
- Topic 48 - Blueprint for requesting data deletion to Relying Parties
- Topic 50 - Blueprint to report unlawful or suspicious request of data
- Topic 11 - Pseudonyms
- Topic 30 - Interaction between Wallet Units
- Topic 40 - Wallet Instance installation and Wallet Unit activation and management
At the same time all of them have been discussed in the context of Topic N discussion. In any case, the existing HLRs are listed in the tables below, along with a proposal to keep, change, add, or remove the HLR.
4.1 Topic 19 - User navigation requirements (Dashboard logs for transparency)
| Index | Requirement specification | Proposal |
|---|---|---|
| DASH_01 | A Wallet Provider SHALL enable a User to access a user-friendly dashboard functionality in their Wallet Unit | Keep with proposed changes |
| DASH_02 | The Wallet Unit SHALL log all transactions executed through the Wallet Unit, including any transactions that were not completed successfully. This log SHALL include all types of transaction executed through the Wallet Unit: issuance and re-issuance transactions, presentation transactions, pseudonym presentation transactions, signing and sealing certificate issuance transactions, signature and seal creation transactions (see Topic 16), attribute deletion requests sent to a Relying Party (see Topic 48), ~~and complaints lodged with~~ reporting to a Data Protection Authority ~~(see Topic 50)~~, PID or Attestation deletion transactions, and Wallet-to-Wallet transactions. Note: For the data to be logged for an attribute deletion request or ~~a complaint~~ reporting to the DPA, see Topic 48 and Topic 50, respectively. | Keep with proposed changes |
| DASH_02a | The Wallet Unit SHALL retain transactions in the log at least for the time period specified in applicable legislation. If the Wallet Unit must delete transactions from the log, for instance because of size limitations, the Wallet Unit SHALL notify the User via the dashboard before doing so (indicating potential consequence of hindering execution of data protection rights) and SHALL instruct the User how to export the transactions that are about to be deleted; see DASH_07. | Keep with proposed changes |
| DASH_02c | The Commission SHALL establish a technical specification for the common format of the log of transaction. | New requirement as proposed in Topic N discussion (no further changes) |
| DASH_03 | For a presentation transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) the name, contact details (if the registration certificate was available), and unique identifier of the corresponding Relying Party, and the Member State in which that Relying Party is established, or relevant information from the WUA of the Requestor Wallet Unit (see Topic 30), c) the name, contact details (if a registration certificate was available), and unique identifier of the intermediary, if an intermediary is involved in the transaction, d) the attestation type(s) and the identifier(s) of the attribute(s) that were requested, as well as those that were presented, e) in the case of non-completed transactions, the reason for such non-completion, f) URL address of the Registrar's on-line service, g) information on the intended use and URL to the privacy policy, as registered by the Relying Party at the competent Registrar (if made available to the Wallet Unit). Notes: the URL address can be retrieved from the access certificate; intended use information may be retrieved from the Registration Certificate or from the Registrar's online service (see Topic 44). | Keep with proposed changes (aggregating changes from topic N and H discussions) |
| DASH_03a | For a pseudonym presentation transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) the name, contact details (if the registration certificate was available), and unique identifier of the corresponding Relying Party, and the Member State in which that Relying Party is established, or relevant information from the WUA of the Requestor Wallet Unit (see Topic 30), c) the name, contact details (if a registration certificate was available), and unique identifier of the intermediary, if an intermediary is involved in the transaction, d) the attestation type(s) and the identifier(s) of the attribute(s) that were requested, as well as those that were presented, e) in the case of non-completed transactions, the reason for such non-completion, f) URL address of the Registrar's on-line service, g) information on the intended use and URL to the privacy policy, as registered by the Relying Party at the competent Registrar (if made available to the Wallet Unit). Notes: the URL address can be retrieved from the access certificate; intended use information may be retrieved from the Registration Certificate or from the Registrar's online service (see Topic 44). | New requirement |
| DASH_03b | For a presentation and pseudonym presentation transactions executed through the Wallet Unit, the log SHALL NOT contain the value of any attributes presented or the value of any transactional data included in the presentation request. | New requirement |
| DASH_03c | For a Wallet-to-Wallet transaction, the log SHALL contain at least: a) date and time of the transaction, b) role of the Wallet Unit (Presenter or Verifier), c) the attestation type(s) and the identifier(s) of the attribute(s) that were requested, as well as those that were presented, d) in the case of non-completed transactions, the reason for such non-completion. | New requirement |
| DASH_04 | For a signature and seal creation transaction executed through the Wallet Unit, the dashboard SHALL display to the User at least: a) the date and time of the transaction, b) the document or data signed (where possible), c) in the case of non-completed transactions, the reason for such non-completion. | Keep with changes proposed in Topic N discussion (no further changes) |
| DASH_04a | For signing and sealing certificate issuance transactions executed through the Wallet Unit, the dashboard SHALL display to the User at least: a) the date and time of the transaction, b) the issued certificate or certificate identifier (where possible), c) in the case of non-completed transactions, the reason for such non-completion. | New requirement |
| DASH_04b | For PID or Attestation deletion transactions from the transaction log, the dashboard SHALL display to the User at least: a) the date and time of the deletion transaction, b) the type of deleted transaction, c) in the case of non-completed transactions, the reason for such non-completion. | New requirement |
| DASH_05 | For an issuance or re-issuance transaction executed through the Wallet Unit, the dashboard SHALL display to the User at least: a) the date and time of the transaction, b) the name, contact details, and unique identifier of the corresponding PID Provider or Attestation Provider, c) the attestation type requested, as well as the attestation type issued, d) the number of attestations requested and/or issued (i.e., the size of the batch in case of batch issuance). d) in the case of non-completed transactions, the reason for such non-completion. e) for a re-issuance transaction, whether it was triggered by the User or by the Wallet Unit without involvement of the User. | Keep as-is |
| DASH_06 | The Wallet Provider SHALL ensure the confidentiality, integrity, and authenticity of all transactions included in the log. | Keep as-is |
| DASH_06a | Via the dashboard, the Wallet Unit SHALL enable the User to delete any transaction in the log. ~~The Wallet Unit SHALL ensure that no other entity can delete transactions from the log, except possibly for the reason mentioned in DASH_02a.~~ If the User decides to delete transactions from the log, the Wallet Unit SHALL notify the User via the dashboard before doing so (indicating potential consequence of hindering execution of data protection rights) and SHALL instruct the User how to export the transactions that are about to be deleted; see DASH_07. Note: This requirement applies even in case the minimum retention period specified in applicable legislation (see DASH_02a) is not yet over. | Keep with proposed changes |
| DASH_06b | The Wallet Unit SHALL ensure that no other entity (than the User) can delete transactions from the log, except possibly for the reason mentioned in DASH_02a. | New requirement |
| DASH_07 | The dashboard SHALL allow the User to export the details of one or more transactions in the log to a file, while ensuring their confidentiality, authenticity and integrity. The file SHALL be stored in an external storage or remote storage location of the User's choice, from among the storage options supported by the Wallet Unit and SHALL use the common format and security measures specified according to DASH_02c. | Keep with proposed changes |
| DASH_10 | The Wallet Unit SHALL make the logs accessible to the Wallet Provider if this is necessary for the provisioning of the Wallet Unit, and only after obtaining explicit consent from the User via the dashboard. | Delete |
4.2 Topic 34 - Migrate to a different Wallet Solution
A. Back-up requirements
| Index | Requirement specification | Proposal |
|---|---|---|
| Mig_05 | The Wallet Unit SHALL store the Migration Object in such a way that its confidentiality, integrity and authenticity is protected and that it is protected against use by others than the User. Note: This could be done, for example, by using password-based cryptography to encrypt the object. | Keep with changes proposed in Topic N discussion (no further changes) |
B. Restore Requirements
| Index | Requirement specification | Proposal |
|---|---|---|
| Mig_07a | The Wallet Unit SHALL ask the User whether they want to restore the log from the Migration Object. When the User agrees, the Wallet Unit SHALL restore the log, and SHALL append future transactions to this log according to the requirements in Topic 19. | Keep as-is |
4.3 Topic 16 - Signing documents with a Wallet Unit
| Index | Requirement specification | Proposal |
|---|---|---|
| QES_13 | Wallet Providers SHALL ensure that a Wallet Unit provides a log of transactions related to qualified electronic signatures and seals generated by or through the Wallet Unit, allowing the User to view the history of previously signed data or documents, according to the requirements in Topic 19. Note: If the signature is generated by a remote Signature Creation Application, the Wallet is at minimum used to authenticate the User to the remote QTSP and to obtain the User's consent for the usage of the private signing key. The logs then record information about these processes. | Keep with changes proposed in Topic N discussion (no further changes) |
4.4 Topic 48 - Blueprint for requesting data deletion to Relying Parties
| Index | Requirement specification | Proposal |
|---|---|---|
| DATA_DLT_05 | A Wallet Unit SHALL include attribute deletion requests in a log so they can be presented to the User via the dashboard (as specified in Topic 19). | Keep as-is |
| DATA_DLT_06 | DATA_DLT_06 The log SHALL include as a minimum: - Date of attribute deletion request, - Relying Party to which the request was made, - Attributes requested to be removed. | Keep as-is |
4.5 Topic 50 - Blueprint to report unlawful or suspicious request of data
| Index | Requirement specification | Proposal |
|---|---|---|
| RPT_DPA_05 | A Wallet Unit SHALL keep reports sent to the DPA in a log file so that it can be presented to the User in the dashboard (as specified in Topic 19). | Keep as-is |
4.6 Topic 11 - Pseudonyms
| Index | Requirement specification | Proposal |
|---|---|---|
| PA_08 | A Wallet Unit ~~SHOULD~~SHALL enable to the User to manage pseudonyms within the Wallet Unit in a user-friendly and transparent manner. Users ~~SHOULD~~SHALL be informed about when and with which Relying Party their pseudonyms were used and be able to view a complete transaction log (including canceled or unsuccessful transactions). | Keep with proposed changes |
4.7 Topic 30 - Interaction between Wallet Units
| Index | Requirement specification | Proposal |
|---|---|---|
| W2W_08 | Wallet Providers SHALL ensure that a Wallet Unit provides a log of transactions related to Wallet-to-Wallet transactions, allowing the User to view the history of the presentation requests and responses (sent or received respectively, depending on the role of a Wallet Unit in a transaction). | New requirement |
4.8 Topic 40 - Wallet Instance installation and Wallet Unit activation and management
| Index | Requirement specification | Proposal |
|---|---|---|
| WIAM_12a | The Wallet Unit SHALL ensure that the Wallet Provider cannot access the contents of the Wallet Unit, in particular to learn a) which attestations are present on the Wallet Unit, b) the status of these attestations, c) the value of attributes in these attestations, and d) the contents of the Wallet Unit log meant in DASH_02. | New requirement |
5 Relation to Other Topics
5.1 Changes to other topics
This topic is related to Topic N - Export and Data Portability. Some further changes to DASH_02 have been proposed, on top of the proposal resulting from the discussion on Topic N. The final wording of the DASH_02 will be thus as proposed in this paper.
Other changes to HLRs related to transaction logs topic proposed in the Topic N Discussion Paper, are valid and remain unchanged.
5.2 Relation to Risk Register (tbd)
The risk register for European Digital Identity Wallets [RiskRegister] contains the following risks that are related to the Relying Party registration:
| Risk type | Risk id | Related risk titles |
|---|---|---|
More specifically, [RiskRegister] describes the following threats to a Wallet:
| ID | Threat description | Related risks |
|---|---|---|
6 Additions and Changes to the ARF
See sections 4 and 5 above. In addition, transactional data related aspects in the main text of the ARF will be updated accordingly.