Release/2.2.0 (#554)

* Review/2.2.0 (#1310)

* Final changes to integrate Discussion Papers L and M

* Changes discussed for TS7 and TS8 were taken into account.

* Adding missing Technical Specifications, so they can be referenced from the ARF.

* Integrating Topic N into the ARF Annex 2, adding Topic N to the Change Notes in section 1.6

* Including Topic I Discussion Paper into the ARF

* Fixing a few markdown issues.

* Changes for Topic W in ARF main document, fixes and additions for including Topic W including requirements for Topic W in Annex 2

* Additions to main document to integrate Topic J paper

* Adding (adapted) HLRs from Topic J to Topic 30 plus some additional related changes to the ARF main doc.

* Fixing W2W requirement numbering

* Topic J update

* Topic H update r3

* Update `a-privacy-risks-and-mitigations.md` source

* Changelog update


* makefile updated

* Release/2.2.0 (#1313)

* Feature/2.2.0 (#1303)

* Changes to integrate Topic L and M

* Final changes to integrate Discussion Paper L and M

In addition, changes discussed this morning for TS7 and TS8 were taken into account.

* Fixing typo

* Adding missing Technical Specifications, so they can be referenced from the ARF.

* Integrating Topic N into the ARF Annex 2

Also solving #1294

* Adding Topic N to the Change Notes in section 1.6

* Solving #1278

* Including Topic I Discussion Paper into the ARF

Fixing a few markdown issues.

* Changes for Topic W in ARF main document

* Fixes and additions for including Topic W

* including requirements for Topic W in Annex 2

* Fixing broken links to TS3

* Fixing md issues

* Adding terms 'strong user authentication'and 'SUA attestation' to Annex 1

Also adding hyperlinks to mentioned Topics, and restoring alphabetical order.

* Last changes for inclusion of Topic W

* Feature/2.2.0 topic j (#1308)

* Solving #1304

* Solving #1192

* Additions to main document to integrate Topic J paper

* Making agreed changes to the W2W discussion in the main doc

* Adding (adapted) HLRs from Topic J to Topic 30

Plus some additional related changes to the ARF main doc.

* Fixing W2W requirement numbering

* Changelog update (#1312)

* Release/topic h j updates (#549)

* Topic J update

* Topic h update r3

* Update `a-privacy-risks-and-mitigations.md` source (#550)

* Changelog update

* makefile updated

* linting

Author: paolo-de-rosa

.vscode/settings.json

@@ -37,6 +37,8 @@
         "Klyne",
         "Kooper",
         "Lodderstedt",
+        "mdoc",
+        "mdocs",
         "mkdocs",
         "OJEU",
         "OMAPI",
@@ -55,8 +57,11 @@
         "RPACA",
         "RPRC",
         "Rulebook",
+        "SEMIC",
+        "SEMPER",
         "Sakimura",
         "SCAL",
+        "smartcard",
         "Sporny",
         "tdate",
         "Terbu",

CHANGELOG

@@ -5,6 +5,16 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.0.0/),
 and this project adheres to [Semantic Versioning](https://semverdoc.org/).
 
+## [2.2.0] - 2025 - 06 - 20
+
+Changes:
+- added results of "Topic L - User requesting data deletion to relying parties"
+- added results of "Topic M - User reporting unlawful or suspicious request of data to DPAs"
+- added results of "Topic N - Export and data portability"
+- added results of "Topic I - Natural person representing another natural person"
+- added results of "Topic W - Transactional data for payment and other use cases
+- added results of "Topic J - Wallet to Wallet interaction"
+
 ## [2.1.0] - 2025 - 06 - 06
 
 Changes:

Makefile

@@ -26,7 +26,7 @@ SOURCE_DOCS    := $(MAIN_DOC) $(ANNEXES_DOCS)
 # Directories and Build Information
 BUILD_DIR      := ./build
 SITE_DIR       := ./site
-VERSION        := 2.1.0
+VERSION        := 2.2.0
 BUILD          := $(shell date +%Y%m%d.%H%M%S)
 
 # Pandoc configuration

docs/annexes/annex-1/annex-1-definitions.md

@@ -41,14 +41,15 @@ and used in the ARF.
 | **Electronic identification scheme** | A system for electronic identification under which electronic identification means are issued to natural or legal persons or natural persons representing other natural persons or legal persons. |
 | **(Electronic) signature** | Data in electronic form which is attached to or logically associated with other data in electronic form and which is used by the signatory to sign. |
 | **(Electronic) seal** | Data in electronic form which is attached to or logically associated with other data in electronic form to ensure the latter’s origin and integrity |
-| **User** | A natural or legal person, or a natural person representing another natural person or a legal person, that uses trust services or electronic identification means provided in accordance with the [European Digital Identity Regulation]. |
 | **Person Identification Data (PID)** | A set of data that is issued in accordance with Union or national law and that enables the establishment of the identity of a natural or legal person, or of a natural person representing another natural person or a legal person. |
+| **Public Sector Body** | A state, regional or local authority, a body governed by public law or an association formed by one or several such authorities or one or several such bodies governed by public law, or a private entity mandated by at least one of those authorities, bodies or associations to provide public services, when acting under such a mandate. |
 | **Qualified Electronic Attestation of Attributes (QEAA)** | An electronic attestation of attributes which is issued by a qualified trust service provider and meets the requirements laid down in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e46-54-1). |
 | **Qualified Electronic Signature (QES)** | An advanced electronic signature that is created by a qualified electronic signature creation device, and which is based on a qualified certificate for electronic signatures. |
 | **Qualified Electronic Signature Creation Device (QSCD)** | Configured software or hardware used to create an electronic signature that meets the requirements laid down in [Annex II](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e38-51-1) of the [European Digital Identity Regulation]. |
 | **Qualified Trust Service Provider (QTSP)** | Qualified Trust Service Provider means a trust service provider who provides one or more qualified trust services and is granted the qualified status by the supervisory body. |
 |**Relying Party** | A natural or legal person that relies upon electronic identification, European Digital Identity Wallets or other electronic identification means, or upon a trust service |
-| **Public Sector Body** | A state, regional or local authority, a body governed by public law or an association formed by one or several such authorities or one or several such bodies governed by public law, or a private entity mandated by at least one of those authorities, bodies or associations to provide public services, when acting under such a mandate. |
+| **strong User authentication** | An authentication based on the use of at least two authentication factors from different categories of either knowledge, something only the user knows, possession, something only the user possesses or inherence, something the user is, that are independent, in that the breach of one does not compromise the reliability of the others, and is designed in such a way as to protect the confidentiality of the authentication data |
+| **User** | A natural or legal person, or a natural person representing another natural person or a legal person, that uses trust services or electronic identification means provided in accordance with the [European Digital Identity Regulation]. |
 
 **Table 1: Definition of terms used in the ARF originating from
 the [European Digital Identity Regulation]**
@@ -91,29 +92,34 @@ precedence.
 
 In some cases, a term has its origin in the context of
 a specific Topic in [Annex 2](../annex-2/annex-2-high-level-requirements.md). In
-such a case, the topic number appears in brackets following the definition. If
+such a case, the topic number is mentioned in a note. If
 the definition relies on an external source, such as a
 standard or a formal publication, that source is mentioned.
 
 | **Term** | **Definition** |
 |-----------|-----------|
-| Administrative validity period (of a PID or attestation) | The date(s) from and/or up to which the attributes in the attestation are valid, which are represented as attribute(s) in the attestation. *Note: Some attestations, for instance diplomas, do not have an administrative validity period* |
+| Administrative validity period (of a PID or attestation) | The date(s) from and/or up to which the attributes in the attestation are valid, which are represented as attribute(s) in the attestation. *Note: Some attestations, for instance diplomas, do not have an administrative validity period.* |
 | Attestation | When not further qualified, a collective term for a QEAA, PuB-EAA, or (non-qualified) EAA. |
 | Attestation Provider | When not further qualified, a collective term for QEAA Provider, PuB-EAA Provider, or (non-qualified) EAA Provider. |
-| Attestation Revocation List | A mechanism provided by a PID Provider or an Attestation Provider (or a trusted party acting on its behalf) for communicating the revocation status of PIDs and attestations, by publishing a list of identifiers of revoked PIDs or attestations. [Topic 7] |
-| Attestation Rulebook | A document describing the attestation type, namespace(s), and other features for a specific attestation type. [Topic 12] |
-| Attestation Status List | A mechanism provided by a PID Provider or an Attestation Provider (or a trusted party acting on its behalf) for communicating the revocation status of PIDs and attestations, by publishing status information (Valid or Invalid) for all relevant PIDs or attestations. [Topic 7] *Note: Which PIDs or attestations are relevant is determined by the entity publishing the status list. For example, a status list may contain all PIDs or attestations whose validity period is not over yet at the time of publication of the list.* |
-| Attestation type | An identifier for a type of attestation, unique within the context of the EUDI Wallet ecosystem [Topic 12] |
+| Attestation Revocation List | A mechanism provided by a PID Provider or an Attestation Provider (or a trusted party acting on its behalf) for communicating the revocation status of PIDs and attestations, by publishing a list of identifiers of revoked PIDs or attestations. *Note: See [Topic 7](../annex-2/annex-2-high-level-requirements.md#a237-topic-7---attestation-revocation-and-revocation-checking).* |
+| Attestation Rulebook | A document describing the attestation type, namespace(s), and other features for a specific attestation type. *Note: See [Topic 12](../annex-2/annex-2-high-level-requirements.md#a2312-topic-12---attestation-rulebooks).* |
+| Attestation Status List | A mechanism provided by a PID Provider or an Attestation Provider (or a trusted party acting on its behalf) for communicating the revocation status of PIDs and attestations, by publishing status information (Valid or Invalid) for all relevant PIDs or attestations. *Notes: -See [Topic 7](../annex-2/annex-2-high-level-requirements.md#a237-topic-7---attestation-revocation-and-revocation-checking). -Which PIDs or attestations are relevant is determined by the entity publishing the status list. For example, a status list may contain all PIDs or attestations whose validity period is not over yet at the time of publication of the list.* |
+| Attestation type | An identifier for a type of attestation, unique within the context of the EUDI Wallet ecosystem. *Note: See [Topic 12](../annex-2/annex-2-high-level-requirements.md#a2312-topic-12---attestation-rulebooks).*  |
 | Certificate Authority (CA) | An entity which is trusted by one or more parties in the EUDI Wallet ecosystem to create and seal certificates. |
 | Certificate Policy (CP) | A named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. |
-| Namespace | A specification of the attribute identifier, syntax and semantics of attributes that can be used in an attestation, having an identifier that is unique within the context of the EUDI Wallet ecosystem. [Topic 12] |
+| Holder (when used in the context of Wallet-to-Wallet interactions) | A User wishing to use their Wallet Unit to present attributes from a PID or attestation to the User of another Wallet Unit. *Notes: See also Verifier. - See [Topic 30](../annex-2/annex-2-high-level-requirements.md#a2330-topic-30---interaction-between-wallet-units).* |
+| Holder Wallet Unit | A Wallet Unit used by a Holder. |
+| Namespace | A specification of the attribute identifier, syntax and semantics of attributes that can be used in an attestation, having an identifier that is unique within the context of the EUDI Wallet ecosystem. *Note: See [Topic 12](../annex-2/annex-2-high-level-requirements.md#a2312-topic-12---attestation-rulebooks).* |
 | National Accreditation Bodies (NAB) | A body that performs accreditation with authority derived from a Member State under [Regulation (EC) No 765/2008](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=celex:32008R0765). |
-| Notification | The act of transferring information to the European Commission. [Topics 31] |
-| Pseudonym | Data uniquely representing a user which in itself does not allow to infer any user's attribute or person identification data, without the use of additional information that is kept separately by the issuer of the data uniquely representing the user. |
+| Notification | The act of transferring information to the European Commission. *Note: see [Topics 31](../annex-2/annex-2-high-level-requirements.md#a2331-topic-31---pid-provider-wallet-provider-attestation-provider-and-access-certificate-authority-notification-and-publication). |
+| Pseudonym | Data uniquely representing a User which in itself does not allow to infer the User's attributes or person identification data, without the use of additional information that is kept separately by the issuer of the data uniquely representing the user. *Note: See [Topic 11](../annex-2/annex-2-high-level-requirements.md#a2311-topic-11---pseudonyms).*|
 | Public Key Infrastructure (PKI) | Systems, software, and communication protocols that are used by EUDI Wallet ecosystem components to distribute, manage, and control public keys. A PKI publishes public keys and establishes trust within an environment by validating and verifying the public keys mapping to an entity. |
 | Qualified Electronic Signature Remote Creation Provider | A natural or a legal person that offers services related to the remote creation, validation, and management of qualified electronic signatures that meet legal requirements and standards in the [European Digital Identity Regulation] to be considered as legally equivalent to handwritten signatures. |
 | Relying Party Instance | A software and/or hardware module with the capability to interact with a Wallet Unit and to perform Relying Party authentication, that is controlled by a Relying Party. |
 | Selective Disclosure | The capability enabling the User to present a subset of the attributes included in a PID or attestation. |
+| SUA attestation| An attestation used for strong user authentication in the context of electronic payments, such that, when a Relying Party sends a presentation request for the attestation to a Wallet Unit, it includes transactional data in the request. *Note: See [Topic 20](../annex-2/annex-2-high-level-requirements.md#a2320-topic-20---strong-user-authentication-for-electronic-payments)* |
 | Technical validity period (of a PID or attestation) | The dates (and possibly times) from and up to which the attestation is valid, which are represented as metadata of the attestation. *Note: All PIDs and attestations have a technical validity period, which is typically much shorter than its administrative validity period (if existent). The technical validity period is chosen based on a risk analysis, e.g. with regard to User privacy.* |
 | Trust Anchor | An authoritative entity represented by a public key and associated data. *Note: based on RFC 5914.* |
 | Trusted List | Repository of information about authoritative entities in a particular legal or contractual context which provides information about their current and historical status. |
+| Verifier (when used in the context of Wallet-to-Wallet interactions) | A User wishing to use their Wallet Unit to request attributes from a PID or attestation from the User of another Wallet Unit. *Note: See [Topic 30](../annex-2/annex-2-high-level-requirements.md#a2330-topic-30---interaction-between-wallet-units)* |
+| Verifier Wallet Unit | A Wallet Unit used by a Verifier. |