From 6a1b454c623267614df110785dbd4449a8cae481 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Tue, 18 Nov 2025 13:47:11 +0200 Subject: [PATCH 01/15] =?UTF-8?q?Changed=20=E2=80=9C2.6.4=20Strong=20User?= =?UTF-8?q?=20Authentication=20for=20electronic=20payments=E2=80=9D=20sect?= =?UTF-8?q?ion=20title=20from=20H5=20to=20H4.=20The=20titles=20of=20its=20?= =?UTF-8?q?sibling=20sections=20are=20H4s.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/architecture-and-reference-framework-main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index 104a16eb..70649625 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/docs/architecture-and-reference-framework-main.md @@ -500,7 +500,7 @@ online, over the internet. For more details and high-level requirements for this use case, please see [Topic 4](./annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md#a233-topic-4---mdl-rulebook). -##### 2.6.4 Strong User Authentication for electronic payments +#### 2.6.4 Strong User Authentication for electronic payments Users would like to be able to authenticate themselves and their electronic payments securely and conveniently using their Wallet Units, so that From 2b6d55d1ebf309eaccae812a4dc045931fe99558 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Tue, 18 Nov 2025 15:29:54 +0200 Subject: [PATCH 02/15] =?UTF-8?q?Moved=20the=20second=20ordered-list=20ele?= =?UTF-8?q?ment=20to=20its=20own=20line=20in=20section=20=E2=80=9C3.15=20A?= =?UTF-8?q?ttestation=20Scheme=20Providers=20for=20QEAAs,=20PuB-EAAs=20and?= =?UTF-8?q?=20EAAs=E2=80=9D.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/architecture-and-reference-framework-main.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index 70649625..c1ca8018 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/docs/architecture-and-reference-framework-main.md @@ -1036,9 +1036,9 @@ PuB-EAA, or EAA) and publishes two complementary artefacts: 1. A human-readable Attestation Rulebook; see [Section 5.4](#54-attestation-rulebooks-and-attestation-schemes), the authoritative documentation that explains what the attestation represents and how it works, detailing identifiers, semantics, encodings, constraints, and -processing rules, trust model; and 2. A machine-readable attestation scheme that -mirrors the Rulebook so software can build requests to Wallet Units and validate -responses at runtime. +processing rules, trust model; and +2. A machine-readable attestation scheme that mirrors the Rulebook so software +can build requests to Wallet Units and validate responses at runtime. Relying Parties use the Rulebook to decide whether and how to adopt an attestation and to prepare their systems, while their Relying Party Instances From 261fed0d3916a83db7812882f10ebe41cbb0b162 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Wed, 19 Nov 2025 12:54:59 +0200 Subject: [PATCH 03/15] =?UTF-8?q?Removed=20an=20extra=20l=20from=20the=20s?= =?UTF-8?q?entence=20=E2=80=9CThis=20authenticates=20the=20Wallet=20Unit?= =?UTF-8?q?=20als=20a=20valid=20Wallet=20Unit=20provided=20by=20a=20truste?= =?UTF-8?q?d=20Wallet=20Provider.=E2=80=9D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/architecture-and-reference-framework-main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index c1ca8018..6ccd59a3 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/docs/architecture-and-reference-framework-main.md @@ -3300,7 +3300,7 @@ During the issuance of a PID or an attestation (see [Section 6.6.2.3](#6623-pid- a PID Provider or Attestation Provider can use this public key to verify that the Wallet Unit is in possession of the corresponding private key, and that this key is protected by the WSCA/WSCD described in the WUA. This authenticates the -Wallet Unit als a valid Wallet Unit provided by a trusted Wallet Provider. +Wallet Unit as a valid Wallet Unit provided by a trusted Wallet Provider. - Lastly, a WUA contains information allowing a PID Provider or an Attestation Provider to verify that the Wallet Provider did not revoke the Wallet Unit Attestation, and hence the Wallet Unit itself. The WUA and the revocation From a3981864bb1701fba8c0a5273f3ad167e0da3f99 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Wed, 19 Nov 2025 23:06:00 +0200 Subject: [PATCH 04/15] =?UTF-8?q?RPRC=5F12=20contained=20two=20points=20la?= =?UTF-8?q?beled=20=E2=80=9Cc)=E2=80=9D=20and=20zero=20points=20labeled=20?= =?UTF-8?q?=E2=80=9Cb)=E2=80=9D.=20Replaced=20the=20first=20=E2=80=9Cc)?= =?UTF-8?q?=E2=80=9C=20label=20to=20=E2=80=9Cb)=E2=80=9D.=20Now=20the=20re?= =?UTF-8?q?quirement=20has=20points=20labeled=20logically=20as=20=E2=80=9C?= =?UTF-8?q?a)=E2=80=9D,=20=E2=80=9Cb)=E2=80=9D=20and=20=E2=80=9Cc)?= =?UTF-8?q?=E2=80=9D.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../annex-2/annex-2.02-high-level-requirements-by-topic.md | 2 +- .../annex-2/annex-2.03-high-level-requirements-by-category.md | 2 +- hltr/high-level-requirements.csv | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md b/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md index 1d033612..060a2d49 100644 --- a/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md +++ b/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md @@ -950,7 +950,7 @@ for issuance), an underscore and a numerator, e.g. ISSU_10. | RPRC_09 | A Member State Registrar MAY decide that, during the registration process for Relying Parties, as specified in [Topic 27](./annex-2.02-high-level-requirements-by-topic.md#a2316-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties), a Provider of registration certificates associated to the Registrar must create and sign or seal one or more registration certificates. If the Registrar decides to do so, the Provider of registration certificates SHALL create and sign or seal a separate registration certificate for each intended use registered by each Relying Party, and issue it to the Relying Party. Each registration certificate SHALL comply with the requirements in the technical specification mentioned in RPRC_02. *Note: See also [Topic 52](./annex-2.02-high-level-requirements-by-topic.md#a2330-topic-52-relying-party-intermediaries).* | | RPRC_10 | If, during registration, a Relying Party received one or more registration certificates, it SHALL distribute these to all its Relying Party Instances. | | RPRC_11 | The contents of a registration certificate issued to a Relying Party SHALL at least one of the following: a) the URL of a web form provided by the Relying Party, which Users can use to send data deletion requests, b) an e-mail address of the Relying Party, on which the Relying Party is prepared to receive data deletion requests from Users, c) a telephone number of the Relying Party, on which the Relying Party is prepared to receive data deletion requests from Users. *Note: See [Topic 48](./annex-2.02-high-level-requirements-by-topic.md#a2327-topic-48---blueprint-for-requesting-data-deletion-to-relying-parties) for more information about data deletion requests.* | -| RPRC_12 | The contents of a registration certificate issued to a Relying Party SHALL contain the name and country of the Data Protection Authority supervising the Relying Party. In addition, the registration certificate SHALL contain at least one of the following: a) the URL of a web form provided by the DPA, which Users can use to report suspicious attribute presentation requests. c) an e-mail address of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users, c) a telephone number of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users. *Note: See [Topic 50](./annex-2.02-high-level-requirements-by-topic.md#a2328-topic-50---blueprint-to-report-unlawful-or-suspicious-request-of-data) for more information about reporting suspicious attribute presentation requests.* | +| RPRC_12 | The contents of a registration certificate issued to a Relying Party SHALL contain the name and country of the Data Protection Authority supervising the Relying Party. In addition, the registration certificate SHALL contain at least one of the following: a) the URL of a web form provided by the DPA, which Users can use to report suspicious attribute presentation requests, b) an e-mail address of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users, c) a telephone number of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users. *Note: See [Topic 50](./annex-2.02-high-level-requirements-by-topic.md#a2328-topic-50---blueprint-to-report-unlawful-or-suspicious-request-of-data) for more information about reporting suspicious attribute presentation requests.* | ##### C. Requirements on the issuance of registration certificates to PID Providers and Attestation Providers diff --git a/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md b/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md index c14fb0f2..deab7c4a 100644 --- a/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md +++ b/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md @@ -694,7 +694,7 @@ as statements of fact. |EW-DM-44-010 | RPRC_09 | A Member State Registrar MAY decide that, during the registration process for Relying Parties, as specified in [Topic 27](./annex-2.02-high-level-requirements-by-topic.md#a2316-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties), a Provider of registration certificates associated to the Registrar must create and sign or seal one or more registration certificates. If the Registrar decides to do so, the Provider of registration certificates SHALL create and sign or seal a separate registration certificate for each intended use registered by each Relying Party, and issue it to the Relying Party. Each registration certificate SHALL comply with the requirements in the technical specification mentioned in RPRC_02. | See also [Topic 52](./annex-2.02-high-level-requirements-by-topic.md#a2330-topic-52-relying-party-intermediaries). | |EW-DM-44-011 | RPRC_10 | If, during registration, a Relying Party received one or more registration certificates, it SHALL distribute these to all its Relying Party Instances.| | |EW-DM-44-012 | RPRC_11 | The contents of a registration certificate issued to a Relying Party SHALL at least one of the following: a) the URL of a web form provided by the Relying Party, which Users can use to send data deletion requests, b) an e-mail address of the Relying Party, on which the Relying Party is prepared to receive data deletion requests from Users, c) a telephone number of the Relying Party, on which the Relying Party is prepared to receive data deletion requests from Users.| See [Topic 48](./annex-2.02-high-level-requirements-by-topic.md#a2327-topic-48---blueprint-for-requesting-data-deletion-to-relying-parties) for more information about data deletion requests. | -|EW-DM-44-013 | RPRC_12 | The contents of a registration certificate issued to a Relying Party SHALL contain the name and country of the Data Protection Authority supervising the Relying Party. In addition, the registration certificate SHALL contain at least one of the following: a) the URL of a web form provided by the DPA, which Users can use to report suspicious attribute presentation requests. c) an e-mail address of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users, c) a telephone number of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users.| See [Topic 50](./annex-2.02-high-level-requirements-by-topic.md#a2328-topic-50---blueprint-to-report-unlawful-or-suspicious-request-of-data) for more information about reporting suspicious attribute presentation requests. | +|EW-DM-44-013 | RPRC_12 | The contents of a registration certificate issued to a Relying Party SHALL contain the name and country of the Data Protection Authority supervising the Relying Party. In addition, the registration certificate SHALL contain at least one of the following: a) the URL of a web form provided by the DPA, which Users can use to report suspicious attribute presentation requests, b) an e-mail address of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users, c) a telephone number of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users.| See [Topic 50](./annex-2.02-high-level-requirements-by-topic.md#a2328-topic-50---blueprint-to-report-unlawful-or-suspicious-request-of-data) for more information about reporting suspicious attribute presentation requests. | |EW-DM-44-014 | RPRC_16 | Either after receiving a presentation request or as a general User setting, a Wallet Unit SHALL offer the User the possibility to indicate whether the User wants to verify the information registered by the competent Registrar about the Relying Party the User is interacting with.| | |EW-DM-44-015 | RPRC_17 | If the User indicated that they want to verify the information registered about the Relying Party and the Relying Party sent a registration certificate to the Wallet Unit, the Wallet Unit SHALL verify the authenticity and validity of the registration certificate according to the technical specification meant in RPRC_02. If the outcome of the verification is negative, the Wallet Unit SHALL, when asking for User approval according to RPA_07, notify the User that it could not obtain the information registered about the entity.| | |EW-DM-44-016 | RPRC_18 | If the User indicated that they want to verify the information registered about the Relying Party, but the Relying Party did not send a registration certificate to the Wallet Unit, the Wallet Unit SHALL connect to the URL of the online service of the Registrar to obtain this information. If the Wallet Unit cannot connect to this URL or if it cannot verify the authenticity and validity of the registered information, it SHALL, when asking for User approval according to RPA_07, notify the User that it could not obtain the information registered about the Relying Party.| The URL of the Registrar is included in the extension of the presentation request, see RPRC_19a. | diff --git a/hltr/high-level-requirements.csv b/hltr/high-level-requirements.csv index b62eb487..a99880cd 100644 --- a/hltr/high-level-requirements.csv +++ b/hltr/high-level-requirements.csv @@ -549,7 +549,7 @@ EW-DM-44-009;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Reg EW-DM-44-010;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B Requirements on the issuance of registration certificates to Relying Parties;RPRC_09;A Member State Registrar MAY decide that, during the registration process for Relying Parties, as specified in [Topic 27](./annex-2.02-high-level-requirements-by-topic.md#a2316-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties), a Provider of registration certificates associated to the Registrar must create and sign or seal one or more registration certificates. If the Registrar decides to do so, the Provider of registration certificates SHALL create and sign or seal a separate registration certificate for each intended use registered by each Relying Party, and issue it to the Relying Party. Each registration certificate SHALL comply with the requirements in the technical specification mentioned in RPRC_02. ;See also [Topic 52](./annex-2.02-high-level-requirements-by-topic.md#a2330-topic-52-relying-party-intermediaries). EW-DM-44-011;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B Requirements on the issuance of registration certificates to Relying Parties;RPRC_10;If, during registration, a Relying Party received one or more registration certificates, it SHALL distribute these to all its Relying Party Instances.; EW-DM-44-012;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B Requirements on the issuance of registration certificates to Relying Parties;RPRC_11;The contents of a registration certificate issued to a Relying Party SHALL at least one of the following: a) the URL of a web form provided by the Relying Party, which Users can use to send data deletion requests, b) an e-mail address of the Relying Party, on which the Relying Party is prepared to receive data deletion requests from Users, c) a telephone number of the Relying Party, on which the Relying Party is prepared to receive data deletion requests from Users.;See [Topic 48](./annex-2.02-high-level-requirements-by-topic.md#a2327-topic-48---blueprint-for-requesting-data-deletion-to-relying-parties) for more information about data deletion requests. -EW-DM-44-013;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B Requirements on the issuance of registration certificates to Relying Parties;RPRC_12;The contents of a registration certificate issued to a Relying Party SHALL contain the name and country of the Data Protection Authority supervising the Relying Party. In addition, the registration certificate SHALL contain at least one of the following: a) the URL of a web form provided by the DPA, which Users can use to report suspicious attribute presentation requests. c) an e-mail address of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users, c) a telephone number of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users.;See [Topic 50](./annex-2.02-high-level-requirements-by-topic.md#a2328-topic-50---blueprint-to-report-unlawful-or-suspicious-request-of-data) for more information about reporting suspicious attribute presentation requests. +EW-DM-44-013;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;B Requirements on the issuance of registration certificates to Relying Parties;RPRC_12;The contents of a registration certificate issued to a Relying Party SHALL contain the name and country of the Data Protection Authority supervising the Relying Party. In addition, the registration certificate SHALL contain at least one of the following: a) the URL of a web form provided by the DPA, which Users can use to report suspicious attribute presentation requests, b) an e-mail address of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users, c) a telephone number of the DPA, on which the DPA is prepared to receive reports about suspicious attribute presentation requests from Users.;See [Topic 50](./annex-2.02-high-level-requirements-by-topic.md#a2328-topic-50---blueprint-to-report-unlawful-or-suspicious-request-of-data) for more information about reporting suspicious attribute presentation requests. AS-AP-44-001;Actor-Specific Requirements;Attestation & PID Providers;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;C. Requirements on the issuance of registration certificates to PID Providers and Attestation Providers;RPRC_13;A Registrar MAY decide that, during the registration process for PID Providers, QEAA Providers, PuB-EAA Provider, or non-qualified EAA Providers, as specified in [Topic 27](./annex-2.02-high-level-requirements-by-topic.md#a2316-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties), a Provider of registration certificates associated to the Member State Registrar must create and sign or seal a registration certificate and issue it to the registering party. If so, that registration certificate SHALL comply with the requirements in the technical specification mentioned in RPRC_02.; AS-AP-44-002;Actor-Specific Requirements;Attestation & PID Providers;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;C. Requirements on the issuance of registration certificates to PID Providers and Attestation Providers;RPRC_14;If, during registration, a PID Provider, QEAA Provider, PuB-EAA Provider, or non-qualified EAA Provider received a registration certificate, it SHALL distribute it to all its service supply points.;A service supply point is a system at which a Wallet Unit can start the process of requesting and obtaining a PID or attestation. AS-AP-44-003;Actor-Specific Requirements;Attestation & PID Providers;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;C. Requirements on the issuance of registration certificates to PID Providers and Attestation Providers;RPRC_15;The contents of a registration certificate issued to a PID Provider, a QEAA Provider, a PuB-EAA Provider, or a non-qualified EAA Provider SHALL contain the type(s) of attestation that this entity intends to issue to Wallet Units.; From 323fd544e4c38884fe195327b8e2033c4813e30a Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Thu, 20 Nov 2025 14:22:54 +0200 Subject: [PATCH 05/15] =?UTF-8?q?Removed=20extra=20=E2=80=9CA=E2=80=9D=20f?= =?UTF-8?q?rom=20the=20end=20of=20a=20bullet=20point.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/architecture-and-reference-framework-main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index 6ccd59a3..5ce542d9 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/docs/architecture-and-reference-framework-main.md @@ -3426,7 +3426,7 @@ need to be vigilant as well, just as with any website on the internet. means that the Wallet Provider is sure that the User is indeed the User that was associated with the Wallet Unit during activation. For this, the Wallet Provider uses the authentication methods established in the User's account during -activation, see [Section 6.5.3](#653-wallet-unit-activation).A +activation, see [Section 6.5.3](#653-wallet-unit-activation). 1. When the Wallet Unit and the Wallet Provider set up a communication channel, the Wallet Unit authenticates the Wallet Provider, meaning that the Wallet Unit is sure that it is dealing with the genuine Wallet Provider. Similarly, the From f80f8c0e2a5f1271ca7121377c427854c8d4d51b Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Thu, 20 Nov 2025 15:13:15 +0200 Subject: [PATCH 06/15] =?UTF-8?q?Replaced=20=E2=80=9CMost=20keystores=20wi?= =?UTF-8?q?ll=20note=20allow=20this=E2=80=9D=20with=20=E2=80=9CMost=20keys?= =?UTF-8?q?tores=20will=20not=20allow=20this=E2=80=9D.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/architecture-and-reference-framework-main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index 5ce542d9..e9f53b75 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/docs/architecture-and-reference-framework-main.md @@ -3505,7 +3505,7 @@ implies the User must be able to authenticate towards the existing HSM from the new Wallet Unit, and be recognised as an existing User. For attestations bound to a keystore (rather than a WSCA/WSCD), the properties of the keystore determine if it's possible to export the attestation private keys to a location -of the User's choosing. Most keystores will note allow this. +of the User's choosing. Most keystores will not allow this. The fact that the Migration Object does not contain private keys means that PIDs and device-bound attestations cannot be backed up and restored from the object From bc4312e5abcbcb5ac292ac2d8a768bc6eb23a737 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Thu, 20 Nov 2025 15:28:52 +0200 Subject: [PATCH 07/15] =?UTF-8?q?Replaced=20=E2=80=9Ca=20Access=20Certific?= =?UTF-8?q?ate=20Authority=E2=80=9D=20with=20=E2=80=9Can=20Access=20Certif?= =?UTF-8?q?icate=20Authority=E2=80=9D.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/architecture-and-reference-framework-main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index e9f53b75..2ea27061 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/docs/architecture-and-reference-framework-main.md @@ -2889,7 +2889,7 @@ fraudulently or as a result of an error. ##### 6.3.2.3 PID Provider or Attestation Provider receives an access certificate and a registration certificate -When a PID Provider or Attestation Provider is registered by a Member State, a +When a PID Provider or Attestation Provider is registered by a Member State, an Access Certificate Authority (see [Section 3.18](#318-access-certificate-authorities) issues one or more access certificates to the PID Provider or to the Attestation Provider. A PID Provider or an Attestation Provider needs such a certificate to From 2fffd9a447c18ad4008509bc42f5d680acde53cb Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Thu, 20 Nov 2025 15:29:35 +0200 Subject: [PATCH 08/15] Added missing closing parenthesis. --- docs/architecture-and-reference-framework-main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index 2ea27061..cf4f7cf6 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/docs/architecture-and-reference-framework-main.md @@ -2890,7 +2890,7 @@ fraudulently or as a result of an error. ##### 6.3.2.3 PID Provider or Attestation Provider receives an access certificate and a registration certificate When a PID Provider or Attestation Provider is registered by a Member State, an -Access Certificate Authority (see [Section 3.18](#318-access-certificate-authorities) +Access Certificate Authority (see [Section 3.18](#318-access-certificate-authorities)) issues one or more access certificates to the PID Provider or to the Attestation Provider. A PID Provider or an Attestation Provider needs such a certificate to authenticate itself towards a Wallet Unit when issuing a PID or an attestation From b25e4d5b71301a5b894476cd77c6701e5bdac18e Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Thu, 20 Nov 2025 15:31:49 +0200 Subject: [PATCH 09/15] Removed extra closing parenthesis. --- docs/architecture-and-reference-framework-main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index cf4f7cf6..25526c8e 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/docs/architecture-and-reference-framework-main.md @@ -3671,7 +3671,7 @@ authenticates the PID Provider or the Attestation Provider. To do so, the Wallet Unit verifies the access certificate presented to it by the PID Provider or Attestation Provider in its Issuer metadata according to [OpenID4VCI]. Additionally, to verify the legal status of the Provider and the type(s) of -attestation it issues), the Wallet Unit checks the registration information +attestation it issues, the Wallet Unit checks the registration information contained in the registration certificate (if available in the Issuer metadata) or in the online service of the Registrar indicated in the access certificate. From be36691d35853e5fd44b41f25c4128cbb6befca3 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Thu, 20 Nov 2025 16:16:42 +0200 Subject: [PATCH 10/15] =?UTF-8?q?Added=20missing=20space=20between=20?= =?UTF-8?q?=E2=80=9Cb)=E2=80=9D=20and=20the=20text=20that=20follows.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../annex-2/annex-2.02-high-level-requirements-by-topic.md | 2 +- .../annex-2/annex-2.03-high-level-requirements-by-category.md | 2 +- docs/discussion-topics/x-relying-party-registration.md | 2 +- hltr/high-level-requirements.csv | 2 +- 4 files changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md b/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md index 060a2d49..6a8c8f15 100644 --- a/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md +++ b/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md @@ -968,7 +968,7 @@ for issuance), an underscore and a numerator, e.g. ISSU_10. | RPRC_17 | If the User indicated that they want to verify the information registered about the Relying Party and the Relying Party sent a registration certificate to the Wallet Unit, the Wallet Unit SHALL verify the authenticity and validity of the registration certificate according to the technical specification meant in RPRC_02. If the outcome of the verification is negative, the Wallet Unit SHALL, when asking for User approval according to RPA_07, notify the User that it could not obtain the information registered about the entity. | | RPRC_18 | If the User indicated that they want to verify the information registered about the Relying Party, but the Relying Party did not send a registration certificate to the Wallet Unit, the Wallet Unit SHALL connect to the URL of the online service of the Registrar to obtain this information. If the Wallet Unit cannot connect to this URL or if it cannot verify the authenticity and validity of the registered information, it SHALL, when asking for User approval according to RPA_07, notify the User that it could not obtain the information registered about the Relying Party. *Note: The URL of the Registrar is included in the extension of the presentation request, see RPRC_19a.* | | RPRC_19 | If a Relying Party Instance received one or more registration certificates (see RPRC_10), it SHALL include a single registration certificate applicable for its current intended use in each presentation request to a Wallet Unit, according to the applicable standard's extension mentioned in RPRC_20. The registration certificate SHALL be included in the request by value, not by reference. The Relying Party Instance SHALL do so both in proximity and remote presentation flows. *Note: This ensures that no external requests are necessary to validate the Relying Party.* | -| RPRC_19a | A Relying Party Instance SHALL include in each presentation request the following information, according to the applicable standard's extension mentioned in RPRC_20a: a) the user-friendly name of the Relying Party, b)the unique identifier of the Relying Party, c) a User-friendly description of the intended use of the Relying Party, d) the URL of the Registrar of the Relying Party, and e) the identifier of the intended use of the Relying Party. *Note: Including items a) and b) enables the Wallet Unit to show to the User the name of the Relying Party. Including c) enables the Wallet Unit to inform the User about the intended use. Including c) and d) enables the Wallet Unit, if desired by the User, to request from the Registrar the attributes registered by the Relying Party for this intended use, as well as the corresponding privacy policy and other registered information. See [Technical Specification 5](../../technical-specifications/ts5-common-formats-and-api-for-rp-registration-information.md) for the definition of this information. Note that in case the Relying Party Instance is operated by an intermediary, items a) - e) pertain to the intermediated Relying Party, see also RPI_06.* | +| RPRC_19a | A Relying Party Instance SHALL include in each presentation request the following information, according to the applicable standard's extension mentioned in RPRC_20a: a) the user-friendly name of the Relying Party, b) the unique identifier of the Relying Party, c) a User-friendly description of the intended use of the Relying Party, d) the URL of the Registrar of the Relying Party, and e) the identifier of the intended use of the Relying Party. *Note: Including items a) and b) enables the Wallet Unit to show to the User the name of the Relying Party. Including c) enables the Wallet Unit to inform the User about the intended use. Including c) and d) enables the Wallet Unit, if desired by the User, to request from the Registrar the attributes registered by the Relying Party for this intended use, as well as the corresponding privacy policy and other registered information. See [Technical Specification 5](../../technical-specifications/ts5-common-formats-and-api-for-rp-registration-information.md) for the definition of this information. Note that in case the Relying Party Instance is operated by an intermediary, items a) - e) pertain to the intermediated Relying Party, see also RPI_06.* | | RPRC_20 | Relying Party Instances and Wallet Units SHALL support the extension for [ISO/IEC 18013-5] or the extension for [OpenID4VP], as specified in ETSI TS 119 472-2 and amended by a CIR in preparation, as applicable, for transferring a single Relying Party registration certificate from a Relying Party Instance to a Wallet Unit. *Note: The correct CIR will be referenced here when it is published.* | | RPRC_20a | Relying Party Instances and Wallet Units SHALL support the extension for [ISO/IEC 18013-5] or the extension for [OpenID4VP], as specified in ETSI TS 119 472-2 and amended by a CIR in preparation, as applicable, for transferring the information listed in RPRC_19a from a Relying Party Instance to a Wallet Unit. *Note: The correct CIR will be referenced here when it is published.* | | RPRC_21 | If the User indicated that they want to verify the information registered about a Relying Party and the Wallet Unit retrieved this information either from the registration certificate or from the online service of the Registrar (see RPRC_16 - RPRC_18), it SHALL verify that all attributes requested in the presentation request are included in the list of attributes registered by the Registrar. If the outcome of the verification is negative, the Wallet Unit SHALL, when asking for User approval according to RPA_07, notify the User about the requested attributes that the Relying Party did not register. | diff --git a/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md b/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md index deab7c4a..a409079e 100644 --- a/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md +++ b/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md @@ -699,7 +699,7 @@ as statements of fact. |EW-DM-44-015 | RPRC_17 | If the User indicated that they want to verify the information registered about the Relying Party and the Relying Party sent a registration certificate to the Wallet Unit, the Wallet Unit SHALL verify the authenticity and validity of the registration certificate according to the technical specification meant in RPRC_02. If the outcome of the verification is negative, the Wallet Unit SHALL, when asking for User approval according to RPA_07, notify the User that it could not obtain the information registered about the entity.| | |EW-DM-44-016 | RPRC_18 | If the User indicated that they want to verify the information registered about the Relying Party, but the Relying Party did not send a registration certificate to the Wallet Unit, the Wallet Unit SHALL connect to the URL of the online service of the Registrar to obtain this information. If the Wallet Unit cannot connect to this URL or if it cannot verify the authenticity and validity of the registered information, it SHALL, when asking for User approval according to RPA_07, notify the User that it could not obtain the information registered about the Relying Party.| The URL of the Registrar is included in the extension of the presentation request, see RPRC_19a. | |EW-DM-44-017 | RPRC_19 | If a Relying Party Instance received one or more registration certificates (see RPRC_10), it SHALL include a single registration certificate applicable for its current intended use in each presentation request to a Wallet Unit, according to the applicable standard's extension mentioned in RPRC_20. The registration certificate SHALL be included in the request by value, not by reference. The Relying Party Instance SHALL do so both in proximity and remote presentation flows.| This ensures that no external requests are necessary to validate the Relying Party. | -|EW-DM-44-018 | RPRC_19a | A Relying Party Instance SHALL include in each presentation request the following information, according to the applicable standard's extension mentioned in RPRC_20a: a) the user-friendly name of the Relying Party, b)the unique identifier of the Relying Party, c) a User-friendly description of the intended use of the Relying Party, d) the URL of the Registrar of the Relying Party, and e) the identifier of the intended use of the Relying Party.| Including items a) and b) enables the Wallet Unit to show to the User the name of the Relying Party. Including c) enables the Wallet Unit to inform the User about the intended use. Including c) and d) enables the Wallet Unit, if desired by the User, to request from the Registrar the attributes registered by the Relying Party for this intended use, as well as the corresponding privacy policy and other registered information. See [Technical Specification 5](../../technical-specifications/ts5-common-formats-and-api-for-rp-registration-information.md) for the definition of this information. Note that in case the Relying Party Instance is operated by an intermediary, items a) - e) pertain to the intermediated Relying Party, see also RPI_06. | +|EW-DM-44-018 | RPRC_19a | A Relying Party Instance SHALL include in each presentation request the following information, according to the applicable standard's extension mentioned in RPRC_20a: a) the user-friendly name of the Relying Party, b) the unique identifier of the Relying Party, c) a User-friendly description of the intended use of the Relying Party, d) the URL of the Registrar of the Relying Party, and e) the identifier of the intended use of the Relying Party.| Including items a) and b) enables the Wallet Unit to show to the User the name of the Relying Party. Including c) enables the Wallet Unit to inform the User about the intended use. Including c) and d) enables the Wallet Unit, if desired by the User, to request from the Registrar the attributes registered by the Relying Party for this intended use, as well as the corresponding privacy policy and other registered information. See [Technical Specification 5](../../technical-specifications/ts5-common-formats-and-api-for-rp-registration-information.md) for the definition of this information. Note that in case the Relying Party Instance is operated by an intermediary, items a) - e) pertain to the intermediated Relying Party, see also RPI_06. | |EW-DM-44-019 | RPRC_20 | Relying Party Instances and Wallet Units SHALL support the extension for [ISO/IEC 18013-5] or the extension for [OpenID4VP], as specified in ETSI TS 119 472-2 and amended by a CIR in preparation, as applicable, for transferring a single Relying Party registration certificate from a Relying Party Instance to a Wallet Unit.| The correct CIR will be referenced here when it is published. | |EW-DM-44-020 | RPRC_20a | Relying Party Instances and Wallet Units SHALL support the extension for [ISO/IEC 18013-5] or the extension for [OpenID4VP], as specified in ETSI TS 119 472-2 and amended by a CIR in preparation, as applicable, for transferring the information listed in RPRC_19a from a Relying Party Instance to a Wallet Unit.| The correct CIR will be referenced here when it is published. | |EW-DM-44-021 | RPRC_21 | If the User indicated that they want to verify the information registered about a Relying Party and the Wallet Unit retrieved this information either from the registration certificate or from the online service of the Registrar (see RPRC_16 - RPRC_18), it SHALL verify that all attributes requested in the presentation request are included in the list of attributes registered by the Registrar. If the outcome of the verification is negative, the Wallet Unit SHALL, when asking for User approval according to RPA_07, notify the User about the requested attributes that the Relying Party did not register.| | diff --git a/docs/discussion-topics/x-relying-party-registration.md b/docs/discussion-topics/x-relying-party-registration.md index 0fb15471..2eeba78b 100644 --- a/docs/discussion-topics/x-relying-party-registration.md +++ b/docs/discussion-topics/x-relying-party-registration.md @@ -682,7 +682,7 @@ In result, the following modification are therefore proposed: | RPACANot_01 | The European Commission SHALL establish technical specifications for the common set of information to be notified about Access Certificate Authorities and Registrars of Registration Certificates. | Keep with proposed changes | | RPACANot_02 | The common set of information to be notified about an Access Certificate Authority and Registrars of Registration Certificates SHALL include: 1. Identification data: i) MS/Country of establishment, ii) Name as registered in an official record, iii) Where applicable: - A business registration number from an official record, - Identification data from that official record. 2. Access Certificate Authority or Registration Certificate Authority trust anchors, i.e., public keys and name as per point 1) ii), supporting the authentication of Relying Parties by Wallet Units. | Keep with proposed changes | | RPACANot_04 | Access Certificate Authority and Registration Certificate Authority trust anchors SHALL be accepted because of their secure notification by the Member States to the Commission and by their publication in the corresponding Commission-compiled Access Certificate Authority and Registration Certificate Authority Trusted Lists which are signed or sealed by the Commission. *Note: The adopted version of the CIR for Relying Party registration will clarify how the Trusted List for Registrars of Registration Certificates are to be arranged, the certificates not being PKI/X.509 certificates as is the case with standard EU Trusted Lists. It is also to be clarified in the related technical specification if Access Certificate Authorities can sign other certificates than access certificates. * | Keep with proposed changes | -| RPACANot_06 | If an Access Certificate Authority is suspended or cancelled (see requirement GenNot_05 above), that Access Certificate Authority SHALL immediately revoke all of its valid access certificates. *Note: When the access certificates of an Intermediary that has its RPACs issued by said suspended or cancelled Access Certificate Authority are revoked, the End-Relying Parties depending on said Intermediary, while having valid registration certificates from a Registrar will have no access to transact with EUDI Wallet Users until the End-Relying Parties a) transit to another Intermediary that has RPAC issued by an active Access Certification Authority or b)the original Access Certificate Authority can continue its operations and re-issue earlier revoked certificates for the original Intermediary.* | New | +| RPACANot_06 | If an Access Certificate Authority is suspended or cancelled (see requirement GenNot_05 above), that Access Certificate Authority SHALL immediately revoke all of its valid access certificates. *Note: When the access certificates of an Intermediary that has its RPACs issued by said suspended or cancelled Access Certificate Authority are revoked, the End-Relying Parties depending on said Intermediary, while having valid registration certificates from a Registrar will have no access to transact with EUDI Wallet Users until the End-Relying Parties a) transit to another Intermediary that has RPAC issued by an active Access Certification Authority or b) the original Access Certificate Authority can continue its operations and re-issue earlier revoked certificates for the original Intermediary.* | New | | RPACANot_07 | If a Registrar of Relying Party Registration Certificates is suspended or cancelled (see requirement GenNot_05 above), that Registrar of Relying Party Registration Certificates SHALL immediately revoke all of its valid registration certificates. | New | | TLPub_01 | The European Commission SHALL establish technical specifications for the system enabling the publication by the Commission of the information notified by the Member States regarding PID Providers, Wallet Providers, PuB-EAA Providers, Access Certificate Authorities and Registrars of Registration Certificates. | Keep with proposed changes | | TLPub_02 | The European Commission SHALL establish technical specifications for the set of information to be published about: PID Providers, Wallet Providers,PuB-EAA Providers, Access Certificate Authorities and Registrars of Registration Certificates based on the information notified by the Member States. *Note: The information to be published MAY be different from the information to be notified per requirements PPNot_01, WPNot_01, PuBPNot_01, and RPACANot_01 above, respectively.* | Keep with proposed changes | diff --git a/hltr/high-level-requirements.csv b/hltr/high-level-requirements.csv index a99880cd..116dc739 100644 --- a/hltr/high-level-requirements.csv +++ b/hltr/high-level-requirements.csv @@ -557,7 +557,7 @@ EW-DM-44-014;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Reg EW-DM-44-015;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;RPRC_17;If the User indicated that they want to verify the information registered about the Relying Party and the Relying Party sent a registration certificate to the Wallet Unit, the Wallet Unit SHALL verify the authenticity and validity of the registration certificate according to the technical specification meant in RPRC_02. If the outcome of the verification is negative, the Wallet Unit SHALL, when asking for User approval according to RPA_07, notify the User that it could not obtain the information registered about the entity.; EW-DM-44-016;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;RPRC_18;If the User indicated that they want to verify the information registered about the Relying Party, but the Relying Party did not send a registration certificate to the Wallet Unit, the Wallet Unit SHALL connect to the URL of the online service of the Registrar to obtain this information. If the Wallet Unit cannot connect to this URL or if it cannot verify the authenticity and validity of the registered information, it SHALL, when asking for User approval according to RPA_07, notify the User that it could not obtain the information registered about the Relying Party.;The URL of the Registrar is included in the extension of the presentation request, see RPRC_19a. EW-DM-44-017;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;RPRC_19;If a Relying Party Instance received one or more registration certificates (see RPRC_10), it SHALL include a single registration certificate applicable for its current intended use in each presentation request to a Wallet Unit, according to the applicable standard's extension mentioned in RPRC_20. The registration certificate SHALL be included in the request by value, not by reference. The Relying Party Instance SHALL do so both in proximity and remote presentation flows.; This ensures that no external requests are necessary to validate the Relying Party. -EW-DM-44-018;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;RPRC_19a;A Relying Party Instance SHALL include in each presentation request the following information, according to the applicable standard's extension mentioned in RPRC_20a: a) the user-friendly name of the Relying Party, b)the unique identifier of the Relying Party, c) a User-friendly description of the intended use of the Relying Party, d) the URL of the Registrar of the Relying Party, and e) the identifier of the intended use of the Relying Party.;Including items a) and b) enables the Wallet Unit to show to the User the name of the Relying Party. Including c) enables the Wallet Unit to inform the User about the intended use. Including c) and d) enables the Wallet Unit, if desired by the User, to request from the Registrar the attributes registered by the Relying Party for this intended use, as well as the corresponding privacy policy and other registered information. See [Technical Specification 5](../../technical-specifications/ts5-common-formats-and-api-for-rp-registration-information.md) for the definition of this information. Note that in case the Relying Party Instance is operated by an intermediary, items a) - e) pertain to the intermediated Relying Party, see also RPI_06. +EW-DM-44-018;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;RPRC_19a;A Relying Party Instance SHALL include in each presentation request the following information, according to the applicable standard's extension mentioned in RPRC_20a: a) the user-friendly name of the Relying Party, b) the unique identifier of the Relying Party, c) a User-friendly description of the intended use of the Relying Party, d) the URL of the Registrar of the Relying Party, and e) the identifier of the intended use of the Relying Party.;Including items a) and b) enables the Wallet Unit to show to the User the name of the Relying Party. Including c) enables the Wallet Unit to inform the User about the intended use. Including c) and d) enables the Wallet Unit, if desired by the User, to request from the Registrar the attributes registered by the Relying Party for this intended use, as well as the corresponding privacy policy and other registered information. See [Technical Specification 5](../../technical-specifications/ts5-common-formats-and-api-for-rp-registration-information.md) for the definition of this information. Note that in case the Relying Party Instance is operated by an intermediary, items a) - e) pertain to the intermediated Relying Party, see also RPI_06. EW-DM-44-019;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;RPRC_20;Relying Party Instances and Wallet Units SHALL support the extension for [ISO/IEC 18013-5] or the extension for [OpenID4VP], as specified in ETSI TS 119 472-2 and amended by a CIR in preparation, as applicable, for transferring a single Relying Party registration certificate from a Relying Party Instance to a Wallet Unit.;The correct CIR will be referenced here when it is published. EW-DM-44-020;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;RPRC_20a;Relying Party Instances and Wallet Units SHALL support the extension for [ISO/IEC 18013-5] or the extension for [OpenID4VP], as specified in ETSI TS 119 472-2 and amended by a CIR in preparation, as applicable, for transferring the information listed in RPRC_19a from a Relying Party Instance to a Wallet Unit.;The correct CIR will be referenced here when it is published. EW-DM-44-021;Ecosystem-Wide Rules;Data Models & Attestation Rules;Topic 44 - Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;44;Registration certificates for PID Providers, Providers of QEAAs, PuB-EAAs, and non-qualified EAAs, and Relying Parties;D. Requirements on the presentation and verification of registration certificates of Relying Parties;RPRC_21;If the User indicated that they want to verify the information registered about a Relying Party and the Wallet Unit retrieved this information either from the registration certificate or from the online service of the Registrar (see RPRC_16 - RPRC_18), it SHALL verify that all attributes requested in the presentation request are included in the list of attributes registered by the Registrar. If the outcome of the verification is negative, the Wallet Unit SHALL, when asking for User approval according to RPA_07, notify the User about the requested attributes that the Relying Party did not register.; From ef0e8d437fbb5ef91ac923d2911d141edd5879b4 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Thu, 20 Nov 2025 16:40:35 +0200 Subject: [PATCH 11/15] =?UTF-8?q?Replaced=20=E2=80=9Cpresent=20the=20all?= =?UTF-8?q?=20approved=20User=20attributes=E2=80=9D=20with=20=E2=80=9Cpres?= =?UTF-8?q?ent=20the=20approved=20User=20attributes=E2=80=9D.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/architecture-and-reference-framework-main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index 25526c8e..1060ab1f 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/docs/architecture-and-reference-framework-main.md @@ -4242,7 +4242,7 @@ User feels that the Relying Party is actually requesting more data than needed, that implies that the Relying Party is not trustworthy. The User should not approve the presentation of any data in that case. -The Wallet Unit will present the all approved User attributes, and only these, +The Wallet Unit will present the approved User attributes, and only these, to the Relying Party Instance. ##### 6.6.3.6 Relying Party Instance verifies the authenticity of the PID or attestation From 92383b60a52fb82978deee0339700f93edfd9263 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Thu, 20 Nov 2025 17:30:55 +0200 Subject: [PATCH 12/15] =?UTF-8?q?Replaced=20=E2=80=9Care=20belonging?= =?UTF-8?q?=E2=80=9D=20with=20=E2=80=9Cbelong=E2=80=9D.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/architecture-and-reference-framework-main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index 1060ab1f..3aaf9064 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/docs/architecture-and-reference-framework-main.md @@ -4490,7 +4490,7 @@ belong to the same User. This can be done in different ways, including (but not necessarily limited to): - **Presentation-Based Binding**: A Relying Party may assume that attributes -presented in a single presentation response are belonging to the same User. +presented in a single presentation response belong to the same User. However, this means that the Relying Party trusts that the Wallet Unit is not hacked or fraudulent. In some high-security use cases, such trust may not be warranted. From 4f4306319784b8520c95dc103880d58336caeabe Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Fri, 21 Nov 2025 11:21:47 +0200 Subject: [PATCH 13/15] Moved the start of a bullet point from the end of the line to the start of the next line so that it renders properly as a bullet point. --- docs/architecture-and-reference-framework-main.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index 3aaf9064..3b3f7ea5 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/docs/architecture-and-reference-framework-main.md @@ -4558,12 +4558,12 @@ PIDs and device-bound attestations. mechanism to implement cryptographic binding between attestations. However, [Topic 18](./annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md#a2311-topic-18---combined-presentations-of-attributes) specifies high-level requirements for a cryptographic binding between -attestations scheme. - This ARF assumes that each Wallet Unit (and therefore -each WSCA/WSCD and keystore) contains attestations for only one User (see also -[Section 3.2](#32-users-of-wallet-units)). Therefore, a proof of cryptographic -binding between two attestations proves that these attestations belong to the -same User. However, some additional actions must be done to use such a mechanism -in practice: +attestations scheme. +- This ARF assumes that each Wallet Unit (and therefore each WSCA/WSCD and +keystore) contains attestations for only one User (see also [Section 3.2](#32-users-of-wallet-units)). +Therefore, a proof of cryptographic binding between two attestations proves +that these attestations belong to the same User. However, some additional +actions must be done to use such a mechanism in practice: - During attestation issuance, an Attestation Provider must request the Wallet Unit to bind the new attestation to an existing PID or attestation. For this, the Attestation Provider must verify that the existing PID or From 0efb221de6a42a15a26b469cb1a05d7a21c41370 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Fri, 21 Nov 2025 11:24:11 +0200 Subject: [PATCH 14/15] =?UTF-8?q?Replaced=20=E2=80=9Ca=20attestation?= =?UTF-8?q?=E2=80=9D=20with=20=E2=80=9Can=20attestation=E2=80=9D.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/architecture-and-reference-framework-main.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index 3b3f7ea5..0d0d71cd 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/docs/architecture-and-reference-framework-main.md @@ -4571,7 +4571,7 @@ actions must be done to use such a mechanism in practice: the Attestation Provider does this is out of scope of the ARF. For example, the Attestation Provider could request the User name and birth date from a PID on the Wallet Unit, verify that this information matches a record in its - database, issue a attestation corresponding to the information in that + database, issue an attestation corresponding to the information in that record, and then request the Wallet Unit to bind the public key in that attestation to the public key in the PID. - A Relying Party that has verified a proof of cryptographic binding between From 406af4cc3d02ec3b9911006a7a7abca21d9f4a70 Mon Sep 17 00:00:00 2001 From: Joel Posti Date: Sat, 22 Nov 2025 22:35:06 +0200 Subject: [PATCH 15/15] =?UTF-8?q?Replaced=20mid-list=20and=20mid-sentence?= =?UTF-8?q?=20=E2=80=9C.=20d)=E2=80=9D=20and=20=E2=80=9C.=20e)=E2=80=9D=20?= =?UTF-8?q?with=20=E2=80=9C,=20d)=E2=80=9D=20and=20=E2=80=9C,=20e)?= =?UTF-8?q?=E2=80=9D.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../annex-2/annex-2.02-high-level-requirements-by-topic.md | 4 ++-- .../annex-2/annex-2.03-high-level-requirements-by-category.md | 4 ++-- .../h-transaction-logs-kept-by-the-wallet.md | 2 +- docs/discussion-topics/n-export-and-data-portability.md | 2 +- hltr/high-level-requirements.csv | 4 ++-- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md b/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md index 6a8c8f15..43724830 100644 --- a/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md +++ b/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md @@ -541,7 +541,7 @@ for issuance), an underscore and a numerator, e.g. ISSU_10. | DASH_03b | For a Wallet-to-Wallet transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) the role of the Wallet Unit (Holder Wallet Unit or Verifier Wallet Unit), 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. | | DASH_03c | For a pseudonym registration or presentation transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) identifying information about the Relying Party, if known to the Wallet Unit, c) whether it is a pseudonym registration or pseudonym presentation transaction, d) in the case of non-completed transactions, the reason for such non-completion. *Note: Regarding point b), see PA_20 in [Topic 11](./annex-2.02-high-level-requirements-by-topic.md#a238-topic-11---pseudonyms).* | | DASH_04 | For a signature or seal creation transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) the document or data signed or sealed (if available to the Wallet Unit), c) in the case of non-completed transactions, the reason for such non-completion. | -| DASH_05 | For a PID or attestation issuance or re-issuance 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 available), 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 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, f) the URL of the associated Registrar's online service. *Note: this URL can be retrieved from the access certificate.* | +| DASH_05 | For a PID or attestation issuance or re-issuance 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 available), 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 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, f) the URL of the associated Registrar's online service. *Note: this URL can be retrieved from the access certificate.* | | DASH_05a | For the deletion of a PID or attestation by the User, the log SHALL contain at least: a) the date and time of the deletion event, b) the attestation type of the deleted PID or attestation. c) The name and unique identifier of the corresponding PID Provider or Attestation Provider. *Note: This requirement is not about deletion of transactions from the log, as per DASH_06a.* | | DASH_06 | The Wallet Provider SHALL ensure the confidentiality, integrity, and authenticity of all transactions included in the log. | | DASH_06a | Via the dashboard, the Wallet Unit SHALL enable the User to delete any transaction in the log. Before deleting any transactions, the Wallet Unit SHALL indicate to the User the potential consequences for the User's data protection rights. *Note: This requirement applies even in case the minimum retention period specified in applicable legislation (see DASH_02a) is not yet over.* | @@ -1026,7 +1026,7 @@ for issuance), an underscore and a numerator, e.g. ISSU_10. | RPI_02 | Empty | | RPI_03 | An intermediary SHALL register each intermediated Relying Party it is acting on behalf of at a Registrar in the Member State where the intermediated Relying Party is established, according all requirements in [Topic 44](./annex-2.02-high-level-requirements-by-topic.md#a2326-topic-44---registration-certificates-for-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties). If a Provider of registration certificates associated with the Registrar issues registration certificates, the intermediary SHALL receive a registration certificate for each of the registered intended uses of the intermediated Relying Party. | | RPI_04 | When registering an intermediated Relying Party, an intermediary SHALL provide legally valid evidence that this Relying Party will indeed use the services of this intermediary to interact with Wallet Units. The Registrar SHALL verify this evidence, and, if it is found to be correct, SHALL register the relationship between the intermediary and the intermediated Relying Party. *Note: Such evidence may, for instance, be a contract between the intermediary and the intermediated Relying Party.* | -| RPI_05 | When an intermediated Relying Party asks its intermediary to request some attributes from a Wallet Unit, it SHALL specify a) its user-friendly name, b) its unique identifier, c) the URL of its Registrar. d) the identifier of its intended use, e) a User-friendly description of its intended use. In addition, if the intermediated Relying Party has registration certificates, it SHALL indicate which single registration certificate the intermediary must include in the presentation request. *Note: a) See RPRC_19a for why the intermediary needs this information. b) Since a), b) and c) will not change for each request, specification of this information can be done once. The same is true for d) and e) if the intermediated Relying Party has only one registered intended use.* | +| RPI_05 | When an intermediated Relying Party asks its intermediary to request some attributes from a Wallet Unit, it SHALL specify a) its user-friendly name, b) its unique identifier, c) the URL of its Registrar, d) the identifier of its intended use, e) a User-friendly description of its intended use. In addition, if the intermediated Relying Party has registration certificates, it SHALL indicate which single registration certificate the intermediary must include in the presentation request. *Note: a) See RPRC_19a for why the intermediary needs this information. b) Since a), b) and c) will not change for each request, specification of this information can be done once. The same is true for d) and e) if the intermediated Relying Party has only one registered intended use.* | | RPI_06 | When requested by an intermediated Relying Party, an intermediary SHALL request a presentation of attributes from a specific Wallet Unit. In the request, the intermediary SHALL include the intermediary's access certificate meant in requirement RPI_01 and the registration certificate of the Relying Party, as meant in RPI_03, if available. In addition, whether or not a registration certificate is available, the intermediary SHALL include in the request the information about the intermediated Relying Party required in RPRC_19a. | | RPI_06a | Empty | | RPI_07 | In case a Wallet Unit receives a presentation request from an intermediary on behalf of an intermediated Relying Party, it SHALL display the names and identifiers of both the intermediary and the intermediated Relying Party to the User when asking for User approval, as described in RPA_07. *Note: In this case, the name and identifier of the intermediary are included in the access certificate presented by the Relying Party Instance, whereas the name and identifier of the intermediated Relying Party are included in the extension of the presentation request (see RPRC_19a), and in the registration certificate if available. If these names and identifiers are different, the Wallet Unit knows that the presentation request is from an intermediary on behalf of an intermediated Relying Party.* | diff --git a/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md b/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md index a409079e..86729ae6 100644 --- a/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md +++ b/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md @@ -143,7 +143,7 @@ as statements of fact. |AS-WP-19-008 | DASH_03b | For a Wallet-to-Wallet transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) the role of the Wallet Unit (Holder Wallet Unit or Verifier Wallet Unit), 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.| | |AS-WP-19-009 | DASH_03c | For a pseudonym registration or presentation transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) identifying information about the Relying Party, if known to the Wallet Unit, c) whether it is a pseudonym registration or pseudonym presentation transaction, d) in the case of non-completed transactions, the reason for such non-completion.| Regarding point b), see PA_20 in [Topic 11](./annex-2.02-high-level-requirements-by-topic.md#a238-topic-11---pseudonyms). | |AS-WP-19-010 | DASH_04 | For a signature or seal creation transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) the document or data signed or sealed (if available to the Wallet Unit), c) in the case of non-completed transactions, the reason for such non-completion.| | -|AS-WP-19-011 | DASH_05 | For a PID or attestation issuance or re-issuance 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 available), 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 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, f) the URL of the associated Registrar's online service.| this URL can be retrieved from the access certificate. | +|AS-WP-19-011 | DASH_05 | For a PID or attestation issuance or re-issuance 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 available), 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 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, f) the URL of the associated Registrar's online service.| this URL can be retrieved from the access certificate. | |AS-WP-19-012 | DASH_05a | For the deletion of a PID or attestation by the User, the log SHALL contain at least: a) the date and time of the deletion event, b) the attestation type of the deleted PID or attestation. c) The name and unique identifier of the corresponding PID Provider or Attestation Provider.| This requirement is not about deletion of transactions from the log, as per DASH_06a. | |AS-WP-19-013 | DASH_06 | The Wallet Provider SHALL ensure the confidentiality, integrity, and authenticity of all transactions included in the log.| | |AS-WP-19-014 | DASH_06a | Via the dashboard, the Wallet Unit SHALL enable the User to delete any transaction in the log. Before deleting any transactions, the Wallet Unit SHALL indicate to the User the potential consequences for the User's data protection rights.| This requirement applies even in case the minimum retention period specified in applicable legislation (see DASH_02a) is not yet over. | @@ -539,7 +539,7 @@ as statements of fact. |AS-RP-51-002 | RPI_02 | Empty| | |AS-RP-51-003 | RPI_03 | An intermediary SHALL register each intermediated Relying Party it is acting on behalf of at a Registrar in the Member State where the intermediated Relying Party is established, according all requirements in [Topic 44](./annex-2.02-high-level-requirements-by-topic.md#a2326-topic-44---registration-certificates-for-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties). If a Provider of registration certificates associated with the Registrar issues registration certificates, the intermediary SHALL receive a registration certificate for each of the registered intended uses of the intermediated Relying Party.| | |AS-RP-51-004 | RPI_04 | When registering an intermediated Relying Party, an intermediary SHALL provide legally valid evidence that this Relying Party will indeed use the services of this intermediary to interact with Wallet Units. The Registrar SHALL verify this evidence, and, if it is found to be correct, SHALL register the relationship between the intermediary and the intermediated Relying Party.| Such evidence may, for instance, be a contract between the intermediary and the intermediated Relying Party. | -|AS-RP-51-005 | RPI_05 | When an intermediated Relying Party asks its intermediary to request some attributes from a Wallet Unit, it SHALL specify a) its user-friendly name, b) its unique identifier, c) the URL of its Registrar. d) the identifier of its intended use, e) a User-friendly description of its intended use. In addition, if the intermediated Relying Party has registration certificates, it SHALL indicate which single registration certificate the intermediary must include in the presentation request.| a) See RPRC_19a for why the intermediary needs this information. b) Since a), b) and c) will not change for each request, specification of this information can be done once. The same is true for d) and e) if the intermediated Relying Party has only one registered intended use. | +|AS-RP-51-005 | RPI_05 | When an intermediated Relying Party asks its intermediary to request some attributes from a Wallet Unit, it SHALL specify a) its user-friendly name, b) its unique identifier, c) the URL of its Registrar, d) the identifier of its intended use, e) a User-friendly description of its intended use. In addition, if the intermediated Relying Party has registration certificates, it SHALL indicate which single registration certificate the intermediary must include in the presentation request.| a) See RPRC_19a for why the intermediary needs this information. b) Since a), b) and c) will not change for each request, specification of this information can be done once. The same is true for d) and e) if the intermediated Relying Party has only one registered intended use. | |AS-RP-51-006 | RPI_06 | When requested by an intermediated Relying Party, an intermediary SHALL request a presentation of attributes from a specific Wallet Unit. In the request, the intermediary SHALL include the intermediary's access certificate meant in requirement RPI_01 and the registration certificate of the Relying Party, as meant in RPI_03, if available. In addition, whether or not a registration certificate is available, the intermediary SHALL include in the request the information about the intermediated Relying Party required in RPRC_19a.| | |AS-RP-51-007 | RPI_06a | Empty| | |AS-RP-51-008 | RPI_07 | In case a Wallet Unit receives a presentation request from an intermediary on behalf of an intermediated Relying Party, it SHALL display the names and identifiers of both the intermediary and the intermediated Relying Party to the User when asking for User approval, as described in RPA_07.| In this case, the name and identifier of the intermediary are included in the access certificate presented by the Relying Party Instance, whereas the name and identifier of the intermediated Relying Party are included in the extension of the presentation request (see RPRC_19a), and in the registration certificate if available. If these names and identifiers are different, the Wallet Unit knows that the presentation request is from an intermediary on behalf of an intermediated Relying Party. | diff --git a/docs/discussion-topics/h-transaction-logs-kept-by-the-wallet.md b/docs/discussion-topics/h-transaction-logs-kept-by-the-wallet.md index 8aada796..57863095 100644 --- a/docs/discussion-topics/h-transaction-logs-kept-by-the-wallet.md +++ b/docs/discussion-topics/h-transaction-logs-kept-by-the-wallet.md @@ -337,7 +337,7 @@ In any case, the existing HLRs are listed in the tables below, along with a prop | 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_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 | diff --git a/docs/discussion-topics/n-export-and-data-portability.md b/docs/discussion-topics/n-export-and-data-portability.md index 4c403d56..1d8b8933 100644 --- a/docs/discussion-topics/n-export-and-data-portability.md +++ b/docs/discussion-topics/n-export-and-data-portability.md @@ -290,7 +290,7 @@ The existing HLRs are listed in the tables below, along with a proposal to keep, | DASH_2c | The Commission SHALL establish a technical specification for the common format of the log of transaction | New requirement | | DASH_03 | For a presentation 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 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, 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. | Keep as-is | | 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 proposed changes | -| 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_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_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. | Keep as-is | diff --git a/hltr/high-level-requirements.csv b/hltr/high-level-requirements.csv index 116dc739..7f3245bf 100644 --- a/hltr/high-level-requirements.csv +++ b/hltr/high-level-requirements.csv @@ -307,7 +307,7 @@ AS-WP-19-007;Actor-Specific Requirements;Wallet Providers;Topic 19 - User naviga AS-WP-19-008;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_03b;For a Wallet-to-Wallet transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) the role of the Wallet Unit (Holder Wallet Unit or Verifier Wallet Unit), 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.; AS-WP-19-009;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_03c;For a pseudonym registration or presentation transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) identifying information about the Relying Party, if known to the Wallet Unit, c) whether it is a pseudonym registration or pseudonym presentation transaction, d) in the case of non-completed transactions, the reason for such non-completion.;Regarding point b), see PA_20 in [Topic 11](./annex-2.02-high-level-requirements-by-topic.md#a238-topic-11---pseudonyms). AS-WP-19-010;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_04;For a signature or seal creation transaction executed through the Wallet Unit, the log SHALL contain at least: a) the date and time of the transaction, b) the document or data signed or sealed (if available to the Wallet Unit), c) in the case of non-completed transactions, the reason for such non-completion.; -AS-WP-19-011;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_05;For a PID or attestation issuance or re-issuance 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 available), 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 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, f) the URL of the associated Registrar's online service.;this URL can be retrieved from the access certificate. +AS-WP-19-011;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_05;For a PID or attestation issuance or re-issuance 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 available), 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 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, f) the URL of the associated Registrar's online service.;this URL can be retrieved from the access certificate. AS-WP-19-012;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_05a;For the deletion of a PID or attestation by the User, the log SHALL contain at least: a) the date and time of the deletion event, b) the attestation type of the deleted PID or attestation. c) The name and unique identifier of the corresponding PID Provider or Attestation Provider.;This requirement is not about deletion of transactions from the log, as per DASH_06a. AS-WP-19-013;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_06;The Wallet Provider SHALL ensure the confidentiality, integrity, and authenticity of all transactions included in the log.; AS-WP-19-014;Actor-Specific Requirements;Wallet Providers;Topic 19 - User navigation requirements (Dashboard logs for transparency);19;User navigation requirements (Dashboard logs for transparency);;DASH_06a;Via the dashboard, the Wallet Unit SHALL enable the User to delete any transaction in the log. Before deleting any transactions, the Wallet Unit SHALL indicate to the User the potential consequences for the User's data protection rights.;This requirement applies even in case the minimum retention period specified in applicable legislation (see DASH_02a) is not yet over. @@ -590,7 +590,7 @@ AS-RP-51-001;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party AS-RP-51-002;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_02;Empty; AS-RP-51-003;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_03;An intermediary SHALL register each intermediated Relying Party it is acting on behalf of at a Registrar in the Member State where the intermediated Relying Party is established, according all requirements in [Topic 44](./annex-2.02-high-level-requirements-by-topic.md#a2326-topic-44---registration-certificates-for-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties). If a Provider of registration certificates associated with the Registrar issues registration certificates, the intermediary SHALL receive a registration certificate for each of the registered intended uses of the intermediated Relying Party.; AS-RP-51-004;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_04;When registering an intermediated Relying Party, an intermediary SHALL provide legally valid evidence that this Relying Party will indeed use the services of this intermediary to interact with Wallet Units. The Registrar SHALL verify this evidence, and, if it is found to be correct, SHALL register the relationship between the intermediary and the intermediated Relying Party.;Such evidence may, for instance, be a contract between the intermediary and the intermediated Relying Party. -AS-RP-51-005;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_05;When an intermediated Relying Party asks its intermediary to request some attributes from a Wallet Unit, it SHALL specify a) its user-friendly name, b) its unique identifier, c) the URL of its Registrar. d) the identifier of its intended use, e) a User-friendly description of its intended use. In addition, if the intermediated Relying Party has registration certificates, it SHALL indicate which single registration certificate the intermediary must include in the presentation request.;a) See RPRC_19a for why the intermediary needs this information. b) Since a), b) and c) will not change for each request, specification of this information can be done once. The same is true for d) and e) if the intermediated Relying Party has only one registered intended use. +AS-RP-51-005;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_05;When an intermediated Relying Party asks its intermediary to request some attributes from a Wallet Unit, it SHALL specify a) its user-friendly name, b) its unique identifier, c) the URL of its Registrar, d) the identifier of its intended use, e) a User-friendly description of its intended use. In addition, if the intermediated Relying Party has registration certificates, it SHALL indicate which single registration certificate the intermediary must include in the presentation request.;a) See RPRC_19a for why the intermediary needs this information. b) Since a), b) and c) will not change for each request, specification of this information can be done once. The same is true for d) and e) if the intermediated Relying Party has only one registered intended use. AS-RP-51-006;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_06;When requested by an intermediated Relying Party, an intermediary SHALL request a presentation of attributes from a specific Wallet Unit. In the request, the intermediary SHALL include the intermediary's access certificate meant in requirement RPI_01 and the registration certificate of the Relying Party, as meant in RPI_03, if available. In addition, whether or not a registration certificate is available, the intermediary SHALL include in the request the information about the intermediated Relying Party required in RPRC_19a.; AS-RP-51-007;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_06a;Empty; AS-RP-51-008;Actor-Specific Requirements;Relying Parties;Topic 52 Relying Party intermediaries;52;Relying Party intermediaries;;RPI_07;In case a Wallet Unit receives a presentation request from an intermediary on behalf of an intermediated Relying Party, it SHALL display the names and identifiers of both the intermediary and the intermediated Relying Party to the User when asking for User approval, as described in RPA_07.;In this case, the name and identifier of the intermediary are included in the access certificate presented by the Relying Party Instance, whereas the name and identifier of the intermediated Relying Party are included in the extension of the presentation request (see RPRC_19a), and in the registration certificate if available. If these names and identifiers are different, the Wallet Unit knows that the presentation request is from an intermediary on behalf of an intermediated Relying Party.