Merge pull request #304 from eu-digital-identity-wallet/niscy-01-patch

Consistent Spelling & Capitalization in the ARF and accompanying Anne…

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

@@ -112,4 +112,4 @@ from the eIDAS Regulation or the amendment proposal:**
 
 
 [^1]: <https://www.privacy-regulation.eu/en/article-32-security-of-processing-GDPR.htm>,
-    Article 32, section 1 (c)
+    Article 32, Section 1 (c)

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

@@ -31,7 +31,7 @@ but, for instance, by an external standard or specification. The word
 
 ### A.2.2 Structure and order of presentation of the HLRs 
 
-Topics presented in [section A.2.3](##a23-high-level-requirements) are ordered by a Topic number.
+Topics presented in [Section A.2.3](##a23-high-level-requirements) are ordered by a Topic number.
 
 Each Topic includes a short description, followed by the High-Level
 Requirements (HLRs), identified by a unique identifier. The identifier
@@ -338,7 +338,7 @@ WSCA.
 
 | **Index** | **Requirement** |
 |-----------|--------------|
-| WTE_28 | A WSCA SHALL be able to verify the authentication factors of a User, in accordance with the requirements in [Commission Implementing Regulation (EU) 2015/1502](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015R1502) section 2.2.1. |
+| WTE_28 | A WSCA SHALL be able to verify the authentication factors of a User, in accordance with the requirements in [Commission Implementing Regulation (EU) 2015/1502](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015R1502) Section 2.2.1. |
 | WTE_29 | A WSCA SHALL be able to generate a new key pair on request of the Wallet Instance. |
 | WTE_30 | A WSCA SHALL be able to prove possession of the private key corresponding to a public key on request of a Wallet Instance, for example by signing a challenge with that private key. |
 | WTE_31 | A WSCA SHALL register each newly generated key pair as either a WTE key or an attestation key, depending on information provided by the Wallet Instance in the key generation request. The internal registry used by the WSCA for this purpose SHALL be protected against modification by external parties. |
@@ -368,7 +368,7 @@ A - Generic HLRs
 | ISSU_02 | Wallet Providers SHALL ensure that their Wallet Solution supports the attestation formats specified in: <ul><li>ISO/IEC 18013-5, see [ISO18013-5].</li><li>"SD-JWT-based Verifiable Credentials (SD-JWT VC)", see [SD-JWT-VC].</li></ul> with additions and changes as documented in this Annex and in future technical specifications created by or on behalf of the Commission. |
 | ISSU_03 | Wallet Providers SHALL ensure that their Wallet Solution supports the presentation protocols specified in: <ul><li>ISO/IEC 18013-5, see [ISO18013-5].</li><li>OpenID for Verifiable Presentations, see [OpenID4VP].</li></ul> with additions and changes as documented in this Annex and in future technical specifications created by or on behalf of the Commission. |
 | ISSU_04 | The OpenID4VCI protocol specified in [OpenID4VCI] SHALL enable PID Providers and Attestation Provider to issue to a Wallet Instance a batch of multiple PIDs or attestations that are simultaneously valid and contain the same attributes. |
-| ISSU_05 | A Wallet Instance SHALL support a process to activate a newly issued PID or attestation, in accordance with [Commission Implementing Regulation (EU) 2015/1502](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015R1502) section 2.2.2. The goal of the activation process is to verify that the PID or attestation was delivered into the Wallet Instance and WSCA of the User to whom it belongs. The Wallet Instance SHALL NOT allow a User to use a non-activated PID or attestation. |
+| ISSU_05 | A Wallet Instance SHALL support a process to activate a newly issued PID or attestation, in accordance with [Commission Implementing Regulation (EU) 2015/1502](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32015R1502) Section 2.2.2. The goal of the activation process is to verify that the PID or attestation was delivered into the Wallet Instance and WSCA of the User to whom it belongs. The Wallet Instance SHALL NOT allow a User to use a non-activated PID or attestation. |
 | ISSU_06 | After a Wallet Instance receives a PID or an attestation from a PID Provider or Attestation Provider, it SHALL verify that the PID or attestation it received matches the request. |
 | ISSU_07 | After a Wallet Instance receives a PID from a PID Provider, it SHALL validate the signature or seal of the PID using a trust anchor provided in a PID Provider Trusted List made available in accordance with [[Topic 31](#a2331-topic-31---pid-provider-wallet-provider-attestation-provider-and-access-certificate-authority-notification-and-publication)]. |
 | ISSU_08 | After a Wallet Instance receives a QEAA from a QEAA Provider, it SHALL validate the qualified signature or seal of the QEAA in accordance with Art.32 of the eIDAS Regulation. For the verification, the Wallet Instance SHALL use a trust anchor provided in a QEAA Provider Trusted List made available in accordance with [Art. 22](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv%3AOJ.L_.2014.257.01.0073.01.ENG#d1e2162-73-1) of the eIDAS Regulation. |
@@ -469,7 +469,7 @@ C.  Requirements regarding attestation namespaces
 
 | **Index** | **Requirement specification** |
 | -----| --------|
-| ARB_6 |  The body responsible for an Attestation Rulebook SHALL  define all attributes that an attestation of that type may  contain within one or more attribute namespace(s). An attribute namespace SHALL fully define the identifier, the syntax, and the semantics of each attribute within that  namespace have an identifier that is unique within the scopeof the EUDI Wallet ecosystem.|
+| ARB_6 |  The body responsible for an Attestation Rulebook SHALL  define all attributes that an attestation of that type may  contain within one or more attribute namespace(s). An attribute namespace SHALL fully define the identifier, the syntax, and the semantics of each attribute within that  namespace have an identifier that is unique within the scope of the EUDI Wallet ecosystem.|
 | ARB_7 | When determining the attributes to be included in a new  attestation type, the party responsible for the applicable Attestation Rulebook SHOULD consider referring to attributes that have been defined already in a namespace included in   the catalogue as specified in [Topic 25](#a2325-topic-25---unified-definition-and-controlled-vocabulary-for-attestation-attributes) + [26](#a2326-topic-26---attestations-catalogue), rather than   unnecessarily re-defining all attributes within a new  namespace. |
 | ARB_8 | The body responsible for an Attestation Rulebook SHOULD,  when specifying a new attestation namespace, take into  consideration existing conventions for attribute identifier  values and attribute syntaxes. These conventions MAY depend on the format of the attestation, i.e., CBOR for ISO/IEC    18013-5 compliant attestations or JSON for \[SD-JWT VC\]-compliant attestations. |
 | ARB_9 | The body responsible for an Attestation Rulebook SHOULD  ensure that the value of the namespace identifier uses the general format \[Reverse Domain Name\].\[Domain Specific Extension\].\[Version\], where the Domain Name SHOULD be controlled by the responsible body. |
@@ -731,7 +731,7 @@ See [Topic 10](#a2310-topic-10---issuing-a-pid-or-attestation-to-the-eudi-wallet
 
 In this use case, the User is utilizing the Wallet Instance for
 identification purposes in proximity scenarios. The User is concerned
-about sharing personal data in proximity, while ithe User\'s objectives
+about sharing personal data in proximity, while the User\'s objectives
 include identifying themselves to services requiring user identification
 and maintaining control over their personal data sharing. 
 
@@ -829,7 +829,7 @@ entity to receive an access certificate that Wallet Instances can use to
 authenticate them
 
 This Topic specifies high-level requirements related to the registration
-of the abovementioned entities. 
+of the above mentioned entities. 
 
 *HLRs*
 
@@ -1039,8 +1039,8 @@ A.  Generic requirements for notification
 
 | **Index** | **Requirement specification** |
 |-----------|-----------------|
-| GenNot_01 | The European Commission SHALL establish technical specifications for a common system enabling the notification of PID Providers, PuB-EAA Providers, Wallet Providers, and Relying Party Access Certificate Authorities by Member States to the Commission. <p><br> Note: Notification does not apply to QEAA Providers and (non-qualified) EAA Providers, as explained in sections D and F below, respectively. |
-| GenNot_02 | As part of the specifications referred to in GenNot_01, the European Commission SHALL establish standard operating procedures for the notification of a PID Provider, PuB-EAA Provider, Wallet Provider or Relying Party Access Certificate Authorities to the Commission. <p><br> Note: The outcome of the notification procedure is the publication of the information notified by the Member State according to [Article 5a](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e1347-1-1) (18) in a machine and human readable manner using the common system mentioned in section H, TLPub_01. |
+| GenNot_01 | The European Commission SHALL establish technical specifications for a common system enabling the notification of PID Providers, PuB-EAA Providers, Wallet Providers, and Relying Party Access Certificate Authorities by Member States to the Commission. <p><br> Note: Notification does not apply to QEAA Providers and (non-qualified) EAA Providers, as explained in Sections D and F below, respectively. |
+| GenNot_02 | As part of the specifications referred to in GenNot_01, the European Commission SHALL establish standard operating procedures for the notification of a PID Provider, PuB-EAA Provider, Wallet Provider or Relying Party Access Certificate Authorities to the Commission. <p><br> Note: The outcome of the notification procedure is the publication of the information notified by the Member State according to [Article 5a](https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:32024R1183#d1e1347-1-1) (18) in a machine and human readable manner using the common system mentioned in Section H, TLPub_01. |
 | GenNot_03 | The common system mentioned in GenNot_01 SHALL enable: <ol type="a"><li>A secure notification channel between MS & COM for all notifications.</li><li>A notification, verification, and publication process and associated validation steps (with follow-up and monitoring) at the Commission side.</li><li>Collected data to be processed, consolidated, signed/sealed and published in both a machine-processable Trusted List and in a human-readable format, manually and/or automatically using e.g. a web service and/or API.</li></ol> |
 | GenNot_04 | As regard to GenNot_03, point b), the Commission SHALL verify whether the notified data is complete and meets the technical specifications, while the Member States SHALL be responsible for the correctness of the notified information. |
 | GenNot_05 | As part of the specifications referred to in GenNot_01, the European Commission SHALL establish standard operating procedures for the withdrawal of a PID Provider, PuB-EAA Provider, Wallet Provider, or Relying Party Access Certificate Authority. These operating procedures SHALL include unambiguous conditions for withdrawal. As an outcome of the withdrawal procedure, the status of the withdrawn PID Provider, PuB-EAA Provider, Wallet Provider, or Relying Party Access Certificate Authority in the Trusted List SHALL be changed to Invalid. |
@@ -1050,7 +1050,7 @@ B.  Requirements for the notification of PID Providers
 | **Index** | **Requirement specification** |
 |-----------|-----------------|
 | PPNot_01 | The European Commission SHALL establish technical specifications for the common set of information to be notified about PID Providers. |
-| PPNot_02 | The common set of information to be notified about a PID Provider SHALL include: <ol><li>Identification data:<ol><li>MS/Country of establishment,</li><li>Name as registered in an official record,</li><li>Where applicable:<ol><li>A business registration number from an official record,</li><li>Identification data from that official record.</li></ol></li></ol></li><li>PID Provider trust anchors, i.e., public keys and name as per point 1) ii) above, supporting the authentication of PIDs issued by the PID Provider,</li><li>PID Provider Access CA trust anchors, i.e., public keys and CA name, supporting the authentication of the PID Provider by Wallet Instances at the service supply point(s) listed per point 4) below.</li><li>Service supply point(s), i.e., the URL(s) at which a Wallet Instance can start the process of requesting and obtaining a PID.</li></ol><p>Notes: <ul><li>Relating to point 3) above: PID Provider Access CA trust anchors are notified separately from the Relying Party Access CA (see section G below), since PID Providers are -legally speaking- not Relying Parties.</li><li>For the concept of an Access CA, see also \[[Topic 27](#a2327-topic-27---relying-party-registration)\] and section 6.3.2 of \[ARF\]. </li></ul> |
+| PPNot_02 | The common set of information to be notified about a PID Provider SHALL include: <ol><li>Identification data:<ol><li>MS/Country of establishment,</li><li>Name as registered in an official record,</li><li>Where applicable:<ol><li>A business registration number from an official record,</li><li>Identification data from that official record.</li></ol></li></ol></li><li>PID Provider trust anchors, i.e., public keys and name as per point 1) ii) above, supporting the authentication of PIDs issued by the PID Provider,</li><li>PID Provider Access CA trust anchors, i.e., public keys and CA name, supporting the authentication of the PID Provider by Wallet Instances at the service supply point(s) listed per point 4) below.</li><li>Service supply point(s), i.e., the URL(s) at which a Wallet Instance can start the process of requesting and obtaining a PID.</li></ol><p>Notes: <ul><li>Relating to point 3) above: PID Provider Access CA trust anchors are notified separately from the Relying Party Access CA (see Section G below), since PID Providers are -legally speaking- not Relying Parties.</li><li>For the concept of an Access CA, see also \[[Topic 27](#a2327-topic-27---relying-party-registration)\] and Section 6.3.2 of \[ARF\]. </li></ul> |
 | PPNot_03 | PID Providers SHALL ensure that all PIDs they issue can be authenticated using the PID Provider trust anchors notified to the Commission. |
 | PPNot_04 | PID Providers SHALL ensure that their PID Provider access certificates can be authenticated using the PID Provider Access CA trust anchors notified to the Commission. <p><br>Note: \[[Topic 6](#a236-topic-6---relying-party-authentication-and-user-approval)\] describes how access certificates will be used. |
 | PPNot_05 | PID Provider 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 PID Provider Trusted List which is sealed by the Commission. |