Merge pull request #625 from eu-digital-identity-wallet/release/2.7.3

To get all links working who refer to annex 2 (#1623) (#1624)

Author: paolo-de-rosa

CHANGELOG.md

@@ -5,7 +5,12 @@ 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.7.2] - 2025-11-11
+## [2.7.3] - 2025-11-12
+
+Changes:
+ - Updated links to new annex 2 file names.
+ 
+ ## [2.7.2] - 2025-11-11
 
 Changes:
  - Updated annexes 2 orders for pdf creation.
@@ -130,15 +135,14 @@ Editorial changes and fixing typos.
 
 ### Sections/topics with changes
 
-- [Main document](docs/architecture-and-reference-framework-main.md)
+- Main document
     - section 3.11, section 4.4,1, section 4.4.3.1, section 4.4.3.3, section
     4.6.4, section 4.6.6, section 6.1, section 6.3.1, section 6.3.2.1, section
     6.3.2.3, section 6.3.3, section 6.4.1, section 6.4.2, section 6.4.3, section
     6.6.2.2, section 6.6.2.7.2, section 6.6.3.3, section 6.6.3.4, section
     6.6.3.5, section 6.6.3.13,
 
-- [Annex 2](docs/annexes/annex-2/annex-2-high-level-requirements.md) (High-level
-Requirements)
+- Annex 2
     - Topic 3: PID_04, PID, 06, PID_07, PID_16
     - Topic 6: RPA_06, RPA_06a, RPA_06c, RPA_06d,
     - Topic 10: ISSU_24, ISSU_24a, ISSU_27, ISSU_34, ISSU_34a,

Makefile

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

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

@@ -92,7 +92,7 @@ Identity Regulation] or the Commission Implementing Regulations, the latter take
 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
+a specific Topic in [Annex 2](../annex-2/annex-2.01-high-level-requirements.md). In
 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.
@@ -102,27 +102,27 @@ standard or a formal publication, that source is mentioned.
 | 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. *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).*  |
+| 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.02-high-level-requirements-by-topic.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.02-high-level-requirements-by-topic.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.02-high-level-requirements-by-topic.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.02-high-level-requirements-by-topic.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. |
-| 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 (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.02-high-level-requirements-by-topic.md#a2330-topic-30---interaction-between-wallet-units).* |
 | Holder Wallet Unit | A Wallet Unit used by a Holder. |
-| Intermediary | A Relying Party that offers services to other (intermediated) Relying Parties to, on their behalf, connect to Wallet Units and request the User attributes that these intermediated Relying Parties need. *Note: See [Topic 52](../annex-2/annex-2-high-level-requirements.md#a2352-topic-52-relying-party-intermediaries)* |
+| Intermediary | A Relying Party that offers services to other (intermediated) Relying Parties to, on their behalf, connect to Wallet Units and request the User attributes that these intermediated Relying Parties need. *Note: See [Topic 52](../annex-2/annex-2.02-high-level-requirements-by-topic.md#a2352-topic-52-relying-party-intermediaries)* |
 | Keystore |  A hardware-backed repository and service in which non-critical cryptographic assets are generated, stored, and used exclusively inside a dedicated hardware security boundary. *Notes: - Examples include a Secure Element, a TPM, TEE, or secure enclave, or a remote HSM. - Critical cryptographic assets are generated, stored, and used in a WSCA/WSCD.* |
-| 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).* |
+| 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.02-high-level-requirements-by-topic.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. *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).*|
+| Notification | The act of transferring information to the European Commission. *Note: see [Topics 31](../annex-2/annex-2.02-high-level-requirements-by-topic.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.02-high-level-requirements-by-topic.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)* |
+| 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.02-high-level-requirements-by-topic.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 (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.02-high-level-requirements-by-topic.md#a2330-topic-30---interaction-between-wallet-units)* |
 | Verifier Wallet Unit | A Wallet Unit used by a Verifier. |

docs/annexes/annex-2/annex-2.01-high-level-requirements.md

@@ -10,11 +10,11 @@ are included in the [high-level-requirements.csv file](https://raw.githubusercon
 requirements. Insofar relevant, the texts in the introduction to each Topic in the original
 Annex 2 were moved to suitable sections in the ARF main document.
 
-For the convenience of readers, the high-level requirements in the .csv file are also included in two new .md files, called [annex-2-high-level-requirements-by-topic.md](./annex-2-high-level-requirements-by-topic.md) and [annex-2-high-level-requirements-by-category.md](./annex-2-high-level-requirements-by-category.md), which were generated from the .csv file. Note that in case of deviations between the .csv file and the .md files, the .csv file takes precedence.
+For the convenience of readers, the high-level requirements in the .csv file are also included in two new .md files, called [annex-2.02-high-level-requirements-by-topic.md](./annex-2.02-high-level-requirements-by-topic.md) and [annex-2.03-high-level-requirements-by-category.md](./annex-2.03-high-level-requirements-by-category.md), which were generated from the .csv file. Note that in case of deviations between the .csv file and the .md files, the .csv file takes precedence.
 
-The requirements in these files are identical, but they are ordered in a different manner.  The file [annex-2-high-level-requirements-by-topic.md](./annex-2-high-level-requirements-by-topic.md) contains the high-level requirements in the same order as the original (i.e., pre-v2.7.0) Annex 2 file, meaning ordered per discussion topic. It also contains the same Topic numbers and section indicators. However, Topics in the original file that did not contain any high-level requirements have been removed from the .csv file and hence from the resulting .md file.
+The requirements in these files are identical, but they are ordered in a different manner.  The file [annex-2.02-high-level-requirements-by-topic.md](./annex-2.02-high-level-requirements-by-topic.md) contains the high-level requirements in the same order as the original (i.e., pre-v2.7.0) Annex 2 file, meaning ordered per discussion topic. It also contains the same Topic numbers and section indicators. However, Topics in the original file that did not contain any high-level requirements have been removed from the .csv file and hence from the resulting .md file.
 
-The file [annex-2-high-level-requirements-by-category.md](./annex-2-high-level-requirements-by-category.md) orders the high-level requirements on the basis of their subject, meaning the entity that has to comply with each requirement. To enable this, a new system of requirement identifiers was developed, next to the existing identifiers which are based on topic. These new requirement identifiers have a simple, hierarchical format: PART-CATEGORY-SUBCATEGORY-ID, where
+The file [annex-2.03-high-level-requirements-by-category.md](./annex-2.03-high-level-requirements-by-category.md) orders the high-level requirements on the basis of their subject, meaning the entity that has to comply with each requirement. To enable this, a new system of requirement identifiers was developed, next to the existing identifiers which are based on topic. These new requirement identifiers have a simple, hierarchical format: PART-CATEGORY-SUBCATEGORY-ID, where
 
 - PART is either actor-specific requirements (AS) or ecosystem-wide requirements (EW).
 - CATEGORY is a two or three-letter code based on the six main categories established below. This provides immediate context.