Merge pull request #405 from vrk-kpa/orthography-fixes-2025-02-18

Orthography fixes 2025-02-18

Author: paolo-de-rosa

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

@@ -86,9 +86,9 @@ identification and authentication of a User using their Wallet Unit.
 
 *Short description*
 
-A User can obtain their mobile Driver's Licence (mDL) from an mDL Provider and store it in an Wallet Unit. The User can then present the mDL to a Relying Party upon request to prove their driving rights conveniently, securely, and in compliance with the Driving Licences Directive, once it is adopted.
+A User can obtain their mobile Driving Licence (mDL) from an mDL Provider and store it in an Wallet Unit. The User can then present the mDL to a Relying Party upon request to prove their driving rights conveniently, securely, and in compliance with the Driving Licences Directive, once it is adopted.
 
-This Topic contains high-level requirements related to a User presenting a mobile Driver's Licence (mDL) to a Relying Party in a supervised or unsupervised scenario, and also in an unsupervised scenario, in proximity mode.
+This Topic contains high-level requirements related to a User presenting a mobile Driving Licence (mDL) to a Relying Party in a supervised or unsupervised scenario, and also in an unsupervised scenario, in proximity mode.
 
 *HLRs*
 
@@ -393,7 +393,7 @@ This Topic also contains the high-level requirements for [Topic 23](#a2323-topic
 | ISSU_32a | An Attestation Provider SHALL sign its metadata (as defined in OpenID4VCI) using the private key corresponding to its Attestation Provider access certificate. |
 | ISSU_33 | For the verification of Attestation Provider access certificates, a Wallet Unit SHALL accept the trust anchors in all Attestation Provider Access Certificate Authority Trusted List(s). *Note: Attestation Provider Access Certificate Authority Trusted Lists are explained in [[Topic 27](#a2327-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties)]. There may be separate Access Certificate Authority Trusted Lists for QEAA Providers, PuB-EAA Providers, and EAA Providers.* |
 | ISSU_33a | A Wallet Provider SHALL support all Attestation Providers, meaning that its Wallet Units SHALL be capable of requesting the issuance of a QEAA, PuB-EAA, or non-qualified EAA from these Providers at the User's request. |
-| ISSU_34 | A Wallet Unit SHALL authenticate and validate the Attestation Provider access certificate before requesting the issuance of an attestation. The Wallet Unit SHALL verify at least that the access certificate indicates that its subject is a QEAA Provider, Pub-EAA Provider, or EAA Provider, that the access certificate is authentic and is valid at the time of validation, and that the issuer of the access certificate is a CA that is in the Attestation Provider Access Certificate Authority Trusted List, as documented in [[Topic 27](#a2327-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties)]. *Note: PID Providers, QEAA Providers, and PuB-EAA Providers are trusted by other actors in the EUDI Wallet ecosystem to not fraudulently issue attestations (or PIDs) that they are not legally allowed to issue. This trust is warranted since these kinds of providers operate within a regulated framework and are regularly audited. However, non-qualified EAA Providers are unregulated and may not be completely trustworthy. Therefore, before requesting an EAA from a non-qualified EAA Provider, a Wallet Unit may need to verify that that EAA Provider is authorised or registered to issue the type of EAA the Wallet Unit is requesting. Such verification requirements, as well as the mechanisms allowing to do this, may be defined in the applicable Rulebook.* |
+| ISSU_34 | A Wallet Unit SHALL authenticate and validate the Attestation Provider access certificate before requesting the issuance of an attestation. The Wallet Unit SHALL verify at least that the access certificate indicates that its subject is a QEAA Provider, PuB-EAA Provider, or EAA Provider, that the access certificate is authentic and is valid at the time of validation, and that the issuer of the access certificate is a CA that is in the Attestation Provider Access Certificate Authority Trusted List, as documented in [[Topic 27](#a2327-topic-27---registration-of-pid-providers-providers-of-qeaas-pub-eaas-and-non-qualified-eaas-and-relying-parties)]. *Note: PID Providers, QEAA Providers, and PuB-EAA Providers are trusted by other actors in the EUDI Wallet ecosystem to not fraudulently issue attestations (or PIDs) that they are not legally allowed to issue. This trust is warranted since these kinds of providers operate within a regulated framework and are regularly audited. However, non-qualified EAA Providers are unregulated and may not be completely trustworthy. Therefore, before requesting an EAA from a non-qualified EAA Provider, a Wallet Unit may need to verify that that EAA Provider is authorised or registered to issue the type of EAA the Wallet Unit is requesting. Such verification requirements, as well as the mechanisms allowing to do this, may be defined in the applicable Rulebook.* |
 
 #### A.2.3.11 Topic 11 - Pseudonyms  
 
@@ -459,7 +459,7 @@ C.  Requirements regarding attestation attribute schemas
 | ARB_17 | The Schema Provider for an Attestation Rulebook describing a type of attestation that is a non-qualified EAA SHOULD include in the Rulebook one or more attributes representing the set of data meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point c) of the [European Digital Identity Regulation]. |
 | ARB_18 | The Schema Provider for an Attestation Rulebook describing a type of attestation that is a QEAA or a PuB-EAA SHALL  include in the Rulebook one or more attributes or metadata representing the set of data meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point e) or [Annex VII](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-56-1) point e) of the [European Digital Identity Regulation]. |
 | ARB_19 | The Schema Provider for an Attestation Rulebook describing a type of attestation that is a non-qualified EAA SHOULD include in the Rulebook one or more attributes representing the set of data meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point e) of the [European Digital Identity Regulation]. |
-| ARB_20 | The Schema Provider for an Attestation Rulebook describing a type of attestation that is a QEAA or a PuB-EAA SHALL include in the Rulebook one or more attributes or metadata representing the location meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point h) or [Annex VII](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-56-1) point h) of the [European Digital Identity Regulation]. For a QEAA, this location SHALL indicate at least the URL at which a machine-readable version of the  trust anchor to be used for verifying the QEAA can be found or looked up. For a Pub-EAA, this location SHALL indicate at least the URL at which a machine-readable version of the qualified certificate that signed the PuB-EAA can be found or looked up. |
+| ARB_20 | The Schema Provider for an Attestation Rulebook describing a type of attestation that is a QEAA or a PuB-EAA SHALL include in the Rulebook one or more attributes or metadata representing the location meant in [Annex V](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-54-1) point h) or [Annex VII](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e40-56-1) point h) of the [European Digital Identity Regulation]. For a QEAA, this location SHALL indicate at least the URL at which a machine-readable version of the  trust anchor to be used for verifying the QEAA can be found or looked up. For a PuB-EAA, this location SHALL indicate at least the URL at which a machine-readable version of the qualified certificate that signed the PuB-EAA can be found or looked up. |
 | ARB_21 | The Schema Provider for an Attestation Rulebook describing a type of attestation that is a non-qualified EAA SHOULD include in the Rulebook one or more attributes or metadata representing the location at which a machine-readable version of the trust anchor to be used for verifying the EAA can be found or looked up.*Note: What this location indicates precisely is dependent on the nature of the mechanism used for distributing trust anchors; see requirement ARB_26.* |
 
 D.  Miscellaneous requirements

docs/architecture-and-reference-framework-main.md

@@ -382,7 +382,7 @@ are described in Figure 1 and detailed in the following sections.
 3. Person Identification Data (PID) Providers, see [Section 3.4](#34-person-identification-data-pid-providers),
 4. Trusted List Providers, see [Section 3.5](#35-trusted-list-provider),
 5. Qualified Electronic Attestation of Attributes (QEAA) Providers, see [Section 3.6](#36-qualified-electronic-attestation-of-attributes-qeaa-providers),
-6. Electronic Attestation of Attributes issued by or on behalf of a public sector body responsible for an authentic source (Pub-EAA) Providers, see [Section 3.7](#37-eaa-issued-by-or-on-behalf-of-a-public-sector-body-responsible-for-an-authentic-source-pub-eaa-providers),
+6. Electronic Attestation of Attributes issued by or on behalf of a public sector body responsible for an authentic source (PuB-EAA) Providers, see [Section 3.7](#37-eaa-issued-by-or-on-behalf-of-a-public-sector-body-responsible-for-an-authentic-source-pub-eaa-providers),
 7. Electronic Attestation of Attributes (EAA) Providers, see [Section 3.8](#38-non-qualified-electronic-attestation-of-attributes-eaa-providers),
 8. Qualified Electronic Signature Remote Creation Providers, see [Section 3.9](#39-qualified-electronic-signature-remote-creation-qesrc-providers),
 9. Authentic Sources, see [Section 3.10](#310-authentic-sources),
@@ -523,7 +523,7 @@ User attributes from the PID in the Wallet Unit.
 The terms and conditions of these services are for each QEEA Provider to
 determine, beyond what is specified in the [European Digital Identity Regulation].
 
-### 3.7 EAA issued by or on behalf of a public sector body responsible for an authentic source (Pub-EAA) Providers
+### 3.7 EAA issued by or on behalf of a public sector body responsible for an authentic source (PuB-EAA) Providers
 
 As specified in the [European Digital Identity Regulation], an attestation may
 be issued by or on behalf of a public sector body responsible for an Authentic
@@ -541,7 +541,7 @@ to [Section 6.6.3.6](#6636-relying-party-instance-verifies-the-authenticity-of-t
 
 the [European Digital Identity Regulation] stipulates that PuB-EAAs, like QEAAs, have the same legal effect
 as attestations in paper form. It is up to the Member States to define terms and
-conditions for the provisioning of Pub-EAAs, but PuB-EAA Providers will comply
+conditions for the provisioning of PuB-EAAs, but PuB-EAA Providers will comply
 with the same technical specifications and standards as Providers of PIDs and
 other attestations.
 
@@ -605,7 +605,7 @@ In Figure 1 this is indicated by the arrow 'provides qualified data'.
 
 Relying Parties are natural or legal persons that rely upon an electronic
 identification scheme or on a Trust Service. They request attributes contained
-within a PID, QEAA, Pub-EAA or EAA from the Wallet Unit, subject to the approval
+within a PID, QEAA, PuB-EAA or EAA from the Wallet Unit, subject to the approval
 of the User and within the limits of applicable legislation and rules.
 
 The reason for reliance on the Wallet Unit may be a legal requirement, a
@@ -1871,7 +1871,7 @@ certificate does not contain further information about its authorisation or
 registration to issue attestations of a specific type, for instance an mDL or
 diploma. Authorisation is dealt with in the following manner:
 
-- For QEAA Providers and Pub-EAA Providers, no authorisation is necessary, since
+- For QEAA Providers and PuB-EAA Providers, no authorisation is necessary, since
 these kinds of Providers are trusted by other actors in the EUDI Wallet
 ecosystem to not fraudulently issue attestations that they are not legally
 allowed to issue. This trust is warranted since these kinds of Providers operate
@@ -2078,7 +2078,7 @@ PID Provider. Each Wallet Provider will, prior to or during installation of a
 Wallet Instance, let the User know which PID Providers are supported by this
 Wallet Solution.
 
-For QEAAs, Pub-EAAs, and non-qualified EAAs, the situation is different.
+For QEAAs, PuB-EAAs, and non-qualified EAAs, the situation is different.
 Providers of such attestations will support all Wallet Solutions and are not
 allowed to discriminate between them when processing a request for the issuance
 of an attestation. Conversely, a Wallet Solution supports all Attestation