Merge pull request #400 from emlun/typos-etc

Fix some typos, formatting etc.

Author: paolo-de-rosa

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

@@ -175,7 +175,7 @@ B.  User approval
 
 | **Index** | **Requirement specification** |
 |-----------|--------------|
-| RPA_07 | A Wallet Unit SHALL ensure the User approved the release of any attribute(s) in the Wallet Unit to a Relying Party, prior to releasing these attribute. A Wallet Unit SHALL always allow the User to refuse releasing an attribute requested by the Relying Party. |
+| RPA_07 | A Wallet Unit SHALL ensure the User approved the release of any attribute(s) in the Wallet Unit to a Relying Party, prior to releasing these attributes. A Wallet Unit SHALL always allow the User to refuse releasing an attribute requested by the Relying Party. |
 | RPA_08 | A Wallet Unit SHALL ensure that (one of) its WSCA(s) has authenticated the User before allowing the User to give or refuse approval for releasing any attributes. *Note: See [[Topic 09](#a239-topic-9---wallet-unit-attestation)] for information about the WSCA.* |
 | RPA_09 | A Relying Party SHOULD communicate in the request which attributes are needed for which purpose (use case, service), if this is supported by the protocol used for communication with the Wallet Unit. *Notes: - This could be done, for instance, by grouping the attributes and describing the use case, service, or purpose of each group. - The purpose of this recommendation is that a Relying Party makes clear to the User what the intended use, the service being accessed, or the specific purpose is of each requested attribute. For example, a service may legally require attributes for age verification (e.g., birthdate), but the Relying Party may additionally want a User address (e.g., street, location, PObox, country) in order to offer added-value services. Age verification attributes and address attributes should be grouped separately, and the purposes should be clearly distinguished. This allows the User to be better informed about the request, and also allows them to approve one purpose but deny the other; see RPA_10.* |
 | RPA_10 | If a Wallet Unit receives a request indicating one or more purposes (use cases, services) for requesting attributes, the Wallet Instance SHOULD show these to the User when asking for User approval. Moreover, the Wallet Unit SHOULD ensure that for each purpose, the User gives approval either to release all attributes requested for that purpose, or none of them. *Note: This means that a User should either approve the release of all attributes in a given group or to deny the entire group. The Wallet Unit should not allow partial approval within a group. Partial approval would mean that the Relying Party cannot deliver the service, but nevertheless receives some User attributes. This would be a violation of the User's privacy.*  |
@@ -192,7 +192,7 @@ Note: This Topic does not pertain to access certificates for Relying Parties, PI
 
 | **Index** | **Requirement specification** |
 |-----------|--------------|
-| VCR_01 | A PID Provider, QEAA Provider, PuB-EAA Provider, or Wallet Provider SHALL use one of the following methods for revocation of a PID, QEAA, PuB-EAA, or WUA: - Only issue short-lived attestations having a validity period of 24 hours or less, such that revocation will never be necessary,Use an Attestation Status List mechanism specified per VCR_11, or - Use an Attestation Revocation List mechanism specified per VCR_11. *Note: The 24-hour period originates from  ETSI EN 319 411-1 V1.4.1, requirement REV-6.2.4-03A. This requires that the process of revocation must take at most 24 hours. Consequently, revocation may make no sense if the attestation is valid for less than 24 hours, because it may reach the end of its validity period before it is revoked.* |
+| VCR_01 | A PID Provider, QEAA Provider, PuB-EAA Provider, or Wallet Provider SHALL use one of the following methods for revocation of a PID, QEAA, PuB-EAA, or WUA: - Only issue short-lived attestations having a validity period of 24 hours or less, such that revocation will never be necessary, Use an Attestation Status List mechanism specified per VCR_11, or - Use an Attestation Revocation List mechanism specified per VCR_11. *Note: The 24-hour period originates from  ETSI EN 319 411-1 V1.4.1, requirement REV-6.2.4-03A. This requires that the process of revocation must take at most 24 hours. Consequently, revocation may make no sense if the attestation is valid for less than 24 hours, because it may reach the end of its validity period before it is revoked.* |
 | VCR_02 | For non-qualified EAAs, the relevant Rulebook SHALL specify whether that type of EAA must be revocable. If a non-qualified EAA type must be revocable, the relevant Rulebook SHALL determine which of the methods mentioned in VCR_01 must be implemented by the relevant EAA Providers for the revocation of such an EAA. |
 | VCR_03 | If a PID or attestation is revocable, the PID Provider of a given PID, or the Attestation Provider of a given attestation, SHALL be the only party in the EUDI Wallet ecosystem responsible for executing the revocation of that PID or attestation. Similarly, if a WUA is revocable, the Wallet Provider of a given WUA SHALL be the only party in the EUDI Wallet ecosystem responsible for executing the revocation of that WUA. *Note: A PID Provider, Attestation Provider or Wallet Provider MAY outsource the operation of the revocation process to a third party.* |
 | VCR_04 | A PID Provider, Attestation Provider or Wallet Provider that revoked a PID or attestation SHALL NOT reverse the revocation. |

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

@@ -2189,7 +2189,7 @@ Provider's requirements and therefore is fit to receive a PID or an attestation
 from the Provider.
 - Moreover, the WUA contains a WUA public key. During the issuance of a PID or
 an attestation (see [Section
-6.6.2.3](#6623-pid-provider-or-attestation-provider-validates-the-wallet-unit),
+6.6.2.3](#6623-pid-provider-or-attestation-provider-validates-the-wallet-unit)),
 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. Moreover, at
 that time, the Wallet Unit will send another public key to the PID Provider or
@@ -2685,12 +2685,12 @@ will be further discussed with Member States for ARF 2.0.
 ##### 6.6.3.5 Wallet Unit obtains User approval for presenting selected attributes
 
 **Note: In this document the term 'User approval' exclusively refers to a User's
-*decision to present an attribute to a Relying Party. Under no circumstances
-*should User approval to present data from their Wallet Unit be construed as
-*lawful grounds for the processing of personal data by the Relying Party or any
-*other entity. A Relying Party requesting or processing personal data from a
-*Wallet Unit must ensure that it has grounds for lawful processing of that data,
-*according to Article 6 of the GDPR.**
+decision to present an attribute to a Relying Party. Under no circumstances
+User approval to present data from their Wallet Unit should be construed as
+lawful grounds for the processing of personal data by the Relying Party or any
+other entity. A Relying Party requesting or processing personal data from a
+Wallet Unit must ensure that it has grounds for lawful processing of that data,
+according to Article 6 of the GDPR.**
 
 Before presenting any attribute to a Relying Party, the Wallet Unit requests the
 User for their approval. This is critical for ensuring that the User remains in
@@ -2717,7 +2717,7 @@ regarding User approval can be found in [Topic 6].
 
 Another prerequisite for effective User approval is that the Wallet Unit allows
 the selective disclosure of attributes. Selective disclosure implies mainly two
-thing. First, it enables a Relying Party to specify which of the attributes in
+things. First, it enables a Relying Party to specify which of the attributes in
 an attestation it wishes to receive (and which ones not). A Relying Party may
 have different purposes for the requested attributes. For example, an online
 liquor shop may need an age attestation to comply with its legal obligations,
@@ -3407,7 +3407,7 @@ policy enforcement can be found in [Section 6.6.3.4](#6634-wallet-unit-evaluates
 
 User privacy is a key aspect in the design and implementation of the EUDI Wallet
 ecosystem. Attributes are presented as electronic attestations using formats
-based on salted and hashed attributed. These attestations contain unique, fixed elements
+based on salted and hashed attributes. These attestations contain unique, fixed elements
 such as hash values, public keys, and signatures. Malicious Relying Parties could
 exploit these values to track Users by storing and comparing them across
 multiple transactions, identifying recurring patterns.  This privacy threat,
@@ -3438,7 +3438,7 @@ relying on salted-attribute hashes. However, the integration of ZKPs in the EUDI
 Wallet ecosystem is still under discussion and development due to the complexity
 of implementing ZKP solutions in secure hardware and the lack of support in
 currently available secure hardware (WSCDs). This topic will be further explored
-in the context of of the next major release od the ARF. As with Relying Party
+in the context of the next major release of the ARF. As with Relying Party
 linkability, organizational and enforcement measures can help deter Attestation
 Providers from colluding and tracking Users.  Additionally, many Attestation
 Providers are subject to regular audits, making it easier to detect collusion
@@ -3527,8 +3527,6 @@ approaches to address the issue positively.
 - Approach discussions with a **mindset of collaboration and problem-solving**.
 - Be **open to different perspectives**, as contributors may have different
 viewpoints, experiences, and expertise levels.
-- Be **open to different perspectives**, as contributors may have different
-viewpoints, experiences, and expertise levels.
 - Contribute to a **positive and welcoming community atmosphere**.
 
 #### 8.2.2 Managing Issues and Pull Requests

docs/discussion-topics/c-wallet-unit-attestation.md

@@ -647,7 +647,7 @@ See chapter 4 above. In addition, discussions of the WUA in the main part of the
 
 | Reference       | Description    |
 |-----------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| [WebAuthN]      | Web Authentication: An API for accessing Public Key Credentials Level 2 W3C Recommendation, 8 April 2021, https://www.w3.org/TR/webauthn-2/ |
+| [WebAuthn]      | Web Authentication: An API for accessing Public Key Credentials Level 2 W3C Recommendation, 8 April 2021, https://www.w3.org/TR/webauthn-2/ |
 | [ARF_DevPlan]   | Architecture and Reference Framework Development plan 2025, European Commission, v1.0. |
 | [Topic A]       | Topic A - Privacy Risks and Mitigations |
 | [RiskRegister]  | Annex 1 to the Commission Implementing Regulation laying down rules for the application of Regulation (EU) No 910/2014 of the European Parliament and of the Council as regards the certification of the European Digital Identity Wallets, European Commission, October 2024, draft |