Typo fixes 2025-11-24

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

@@ -500,7 +500,7 @@ online, over the internet.
 For more details and high-level requirements for this use case, please see
 [Topic 4](./annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md#a233-topic-4---mdl-rulebook).
 
-##### 2.6.4 Strong User Authentication for electronic payments
+#### 2.6.4 Strong User Authentication for electronic payments
 
 Users would like to be able to authenticate themselves and their electronic
 payments securely and conveniently using their Wallet Units, so that
@@ -1036,9 +1036,9 @@ PuB-EAA, or EAA) and publishes two complementary artefacts:
 1. A human-readable Attestation Rulebook; see [Section 5.4](#54-attestation-rulebooks-and-attestation-schemes),
 the authoritative documentation that explains what the attestation represents
 and how it works, detailing identifiers, semantics, encodings, constraints, and
-processing rules, trust model; and 2. A machine-readable attestation scheme that
-mirrors the Rulebook so software can build requests to Wallet Units and validate
-responses at runtime.
+processing rules, trust model; and
+2. A machine-readable attestation scheme that mirrors the Rulebook so software
+can build requests to Wallet Units and validate responses at runtime.
 
 Relying Parties use the Rulebook to decide whether and how to adopt an
 attestation and to prepare their systems, while their Relying Party Instances
@@ -2889,8 +2889,8 @@ fraudulently or as a result of an error.
 
 ##### 6.3.2.3 PID Provider or Attestation Provider receives an access certificate and a registration certificate
 
-When a PID Provider or Attestation Provider is registered by a Member State, a
-Access Certificate Authority (see [Section 3.18](#318-access-certificate-authorities)
+When a PID Provider or Attestation Provider is registered by a Member State, an
+Access Certificate Authority (see [Section 3.18](#318-access-certificate-authorities))
 issues one or more access certificates to the PID Provider or to the Attestation
 Provider. A PID Provider or an Attestation Provider needs such a certificate to
 authenticate itself towards a Wallet Unit when issuing a PID or an attestation
@@ -3300,7 +3300,7 @@ During the issuance of a PID or an attestation (see [Section 6.6.2.3](#6623-pid-
 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, and that this
 key is protected by the WSCA/WSCD described in the WUA. This authenticates the
-Wallet Unit als a valid Wallet Unit provided by a trusted Wallet Provider.
+Wallet Unit as a valid Wallet Unit provided by a trusted Wallet Provider.
 - Lastly, a WUA contains information allowing a PID Provider or an Attestation
 Provider to verify that the Wallet Provider did not revoke the Wallet Unit
 Attestation, and hence the Wallet Unit itself. The WUA and the revocation
@@ -3426,7 +3426,7 @@ need to be vigilant as well, just as with any website on the internet.
 means that the Wallet Provider is sure that the User is indeed the User that was
 associated with the Wallet Unit during activation. For this, the Wallet Provider
 uses the authentication methods established in the User's account during
-activation, see [Section 6.5.3](#653-wallet-unit-activation).A
+activation, see [Section 6.5.3](#653-wallet-unit-activation).
 1. When the Wallet Unit and the Wallet Provider set up a communication channel,
 the Wallet Unit authenticates the Wallet Provider, meaning that the Wallet Unit
 is sure that it is dealing with the genuine Wallet Provider. Similarly, the
@@ -3505,7 +3505,7 @@ implies the User must be able to authenticate towards the existing HSM from the
 new Wallet Unit, and be recognised as an existing User. For attestations bound
 to a keystore (rather than a WSCA/WSCD), the properties of the keystore
 determine if it's possible to export the attestation private keys to a location
-of the User's choosing. Most keystores will note allow this.
+of the User's choosing. Most keystores will not allow this.
 
 The fact that the Migration Object does not contain private keys means that PIDs
 and device-bound attestations cannot be backed up and restored from the object
@@ -3671,7 +3671,7 @@ authenticates the PID Provider or the Attestation Provider. To do so, the Wallet
 Unit verifies the access certificate presented to it by the PID Provider or
 Attestation Provider in its Issuer metadata according to [OpenID4VCI].
 Additionally, to verify the legal status of the Provider and the type(s) of
-attestation it issues), the Wallet Unit checks the registration information
+attestation it issues, the Wallet Unit checks the registration information
 contained in the registration certificate (if available in the Issuer metadata)
 or in the online service of the Registrar indicated in the access certificate.
 
@@ -4242,7 +4242,7 @@ User feels that the Relying Party is actually requesting more data than needed,
 that implies that the Relying Party is not trustworthy. The User should not
 approve the presentation of any data in that case.
 
-The Wallet Unit will present the all approved User attributes, and only these,
+The Wallet Unit will present the approved User attributes, and only these,
 to the Relying Party Instance.
 
 ##### 6.6.3.6 Relying Party Instance verifies the authenticity of the PID or attestation
@@ -4490,7 +4490,7 @@ belong to the same User. This can be done in different ways, including (but not
 necessarily limited to):
 
 - **Presentation-Based Binding**: A Relying Party may assume that attributes
-presented in a single presentation response are belonging to the same User.
+presented in a single presentation response belong to the same User.
 However, this means that the Relying Party trusts that the Wallet Unit is not
 hacked or fraudulent. In some high-security use cases, such trust may not be
 warranted.
@@ -4558,20 +4558,20 @@ PIDs and device-bound attestations.
 mechanism to implement cryptographic binding between attestations. However,
 [Topic 18](./annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md#a2311-topic-18---combined-presentations-of-attributes)
 specifies high-level requirements for a cryptographic binding between
-attestations scheme.  - This ARF assumes that each Wallet Unit (and therefore
-each WSCA/WSCD and keystore) contains attestations for only one User (see also
-[Section 3.2](#32-users-of-wallet-units)). Therefore, a proof of cryptographic
-binding between two attestations proves that these attestations belong to the
-same User. However, some additional actions must be done to use such a mechanism
-in practice:
+attestations scheme.
+- This ARF assumes that each Wallet Unit (and therefore each WSCA/WSCD and
+keystore) contains attestations for only one User (see also [Section 3.2](#32-users-of-wallet-units)).
+Therefore, a proof of cryptographic binding between two attestations proves
+that these attestations belong to the same User. However, some additional
+actions must be done to use such a mechanism in practice:
     - During attestation issuance, an Attestation Provider must request the
     Wallet Unit to bind the new attestation to an existing PID or attestation.
     For this, the Attestation Provider must verify that the existing PID or
     attestation refers to the same User to whom the new attestation refers. How
     the Attestation Provider does this is out of scope of the ARF. For example,
     the Attestation Provider could request the User name and birth date from a
     PID on the Wallet Unit, verify that this information matches a record in its
-    database, issue a attestation corresponding to the information in that
+    database, issue an attestation corresponding to the information in that
     record, and then request the Wallet Unit to bind the public key in that
     attestation to the public key in the PID.
     - A Relying Party that has verified a proof of cryptographic binding between

docs/discussion-topics/h-transaction-logs-kept-by-the-wallet.md

@@ -337,7 +337,7 @@ In any case, the existing HLRs are listed in the tables below, along with a prop
 | DASH_04  | For a signature **and seal** creation transaction executed through the Wallet Unit, the dashboard SHALL display to the User at least: a) the date and time of the transaction, b) the document or data signed (where possible), c) in the case of non-completed transactions, the reason for such non-completion. |      Keep with changes proposed in Topic N discussion (no further changes)     |
 | **DASH_04a**  | **For signing and sealing certificate issuance transactions executed through the Wallet Unit, the dashboard SHALL display to the User at least: a) the date and time of the transaction, b) the issued certificate or certificate identifier (where possible), c) in the case of non-completed transactions, the reason for such non-completion.** |      New requirement     |
 | **DASH_04b**  | **For PID or Attestation deletion transactions from the transaction log, the dashboard SHALL display to the User at least: a) the date and time of the deletion transaction, b) the type of deleted transaction, c) in the case of non-completed transactions, the reason for such non-completion.** |      New requirement     |
-| DASH_05  | For an issuance or re-issuance transaction executed through the Wallet Unit, the dashboard SHALL display to the User at least: a) the date and time of the transaction, b) the name, contact details, and unique identifier of the corresponding PID Provider or Attestation Provider, c) the attestation type requested, as well as the attestation type issued, d) the number of attestations requested and/or issued (i.e., the size of the batch in case of batch issuance). d) in the case of non-completed transactions, the reason for such non-completion. e) for a re-issuance transaction, whether it was triggered by the User or by the Wallet Unit without involvement of the User. |       Keep as-is       |
+| DASH_05  | For an issuance or re-issuance transaction executed through the Wallet Unit, the dashboard SHALL display to the User at least: a) the date and time of the transaction, b) the name, contact details, and unique identifier of the corresponding PID Provider or Attestation Provider, c) the attestation type requested, as well as the attestation type issued, d) the number of attestations requested and/or issued (i.e., the size of the batch in case of batch issuance), d) in the case of non-completed transactions, the reason for such non-completion, e) for a re-issuance transaction, whether it was triggered by the User or by the Wallet Unit without involvement of the User. |       Keep as-is       |
 | DASH_06 | The Wallet Provider SHALL ensure the confidentiality, integrity, and authenticity of all transactions included in the log. | Keep as-is |
 | DASH_06a | Via the dashboard, the Wallet Unit SHALL enable the User to delete any transaction in the log. ~~The Wallet Unit SHALL ensure that no other entity can delete transactions from the log, except possibly for the reason mentioned in DASH_02a.~~ **If the User decides to delete transactions from the log, the Wallet Unit SHALL notify the User via the dashboard before doing so (indicating potential consequence of hindering execution of data protection rights) and SHALL instruct the User how to export the transactions that are about to be deleted; see DASH_07. _Note: This requirement applies even in case the minimum retention period specified in applicable legislation (see DASH_02a) is not yet over._** | Keep with proposed changes |
 | **DASH_06b** | **The Wallet Unit SHALL ensure that no other entity (than the User) can delete transactions from the log, except possibly for the reason mentioned in DASH_02a.** | New requirement |

docs/discussion-topics/n-export-and-data-portability.md

@@ -290,7 +290,7 @@ The existing HLRs are listed in the tables below, along with a proposal to keep,
 | DASH_2c  | The Commission SHALL establish a technical specification for the common format of the log of transaction  |      New requirement        |
 | DASH_03  | For a presentation transaction executed through the Wallet Unit, the dashboard SHALL display to the User at least: a) the date and time of the transaction, b) the name, contact details, and unique identifier of the corresponding Relying Party, and the Member State in which that Relying Party is established, or relevant information from the WUA of the Requestor Wallet Unit (see Topic 30), c) the name, contact details, and unique identifier of the intermediary, if an intermediary is involved in the transaction, d) the attestation type(s) and the identifier(s) of the attribute(s) that were requested, as well as those that were presented, e) in the case of non-completed transactions, the reason for such non-completion. |       Keep as-is       |
 | DASH_04  | For a signature **and seal** creation transaction executed through the Wallet Unit, the dashboard SHALL display to the User at least: a) the date and time of the transaction, b) the document or data signed (where possible), c) in the case of non-completed transactions, the reason for such non-completion. |      Keep with proposed changes        |
-| DASH_05  | For an issuance or re-issuance transaction executed through the Wallet Unit, the dashboard SHALL display to the User at least: a) the date and time of the transaction, b) the name, contact details, and unique identifier of the corresponding PID Provider or Attestation Provider, c) the attestation type requested, as well as the attestation type issued, d) the number of attestations requested and/or issued (i.e., the size of the batch in case of batch issuance). d) in the case of non-completed transactions, the reason for such non-completion. e) for a re-issuance transaction, whether it was triggered by the User or by the Wallet Unit without involvement of the User. |       Keep as-is       |
+| DASH_05  | For an issuance or re-issuance transaction executed through the Wallet Unit, the dashboard SHALL display to the User at least: a) the date and time of the transaction, b) the name, contact details, and unique identifier of the corresponding PID Provider or Attestation Provider, c) the attestation type requested, as well as the attestation type issued, d) the number of attestations requested and/or issued (i.e., the size of the batch in case of batch issuance), d) in the case of non-completed transactions, the reason for such non-completion, e) for a re-issuance transaction, whether it was triggered by the User or by the Wallet Unit without involvement of the User. |       Keep as-is       |
 | DASH_07  | The dashboard SHALL allow the User to export the details of one or more transactions in the log to a file, while ensuring their confidentiality, authenticity and integrity. |       Keep as-is       |
 
 

docs/discussion-topics/x-relying-party-registration.md

@@ -682,7 +682,7 @@ In result, the following modification are therefore proposed:
 | RPACANot_01  |  The European Commission SHALL establish technical specifications for the common set of information to be notified about Access Certificate Authorities and Registrars of Registration Certificates. |   Keep with proposed changes   |
 | RPACANot_02  | The common set of information to be notified about an Access Certificate Authority and Registrars of Registration Certificates SHALL include: 1. Identification data: i) MS/Country of establishment, ii) Name as registered in an official record, iii) Where applicable: - A business registration number from an official record, - Identification data from that official record. 2. Access Certificate Authority or Registration Certificate Authority trust anchors, i.e., public keys and name as per point 1) ii), supporting the authentication of Relying Parties by Wallet Units. |   Keep with proposed changes  |
 | RPACANot_04 | Access Certificate Authority and Registration Certificate Authority 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 Access Certificate Authority and Registration Certificate Authority Trusted Lists which are signed or sealed by the Commission. *Note: The adopted version of the CIR for Relying Party registration will clarify how the Trusted List for Registrars of Registration Certificates are to be arranged, the certificates not being PKI/X.509 certificates as is the case with standard EU Trusted Lists. It is also to be clarified in the related technical specification if Access Certificate Authorities can sign other certificates than access certificates. * |  Keep with proposed changes  |
-| RPACANot_06 | If an Access Certificate Authority is suspended or cancelled (see requirement GenNot_05 above), that Access Certificate Authority SHALL immediately revoke all of its valid access certificates. *Note: When the access certificates of an Intermediary that has its RPACs issued by said suspended or cancelled Access Certificate Authority are revoked, the End-Relying Parties depending on said Intermediary, while having valid registration certificates from a Registrar will have no access to transact with EUDI Wallet Users until the End-Relying Parties a) transit to another Intermediary that has RPAC issued by an active Access Certification Authority or b)the original Access Certificate Authority can continue its operations and re-issue earlier revoked certificates for the original Intermediary.* |   New   |
+| RPACANot_06 | If an Access Certificate Authority is suspended or cancelled (see requirement GenNot_05 above), that Access Certificate Authority SHALL immediately revoke all of its valid access certificates. *Note: When the access certificates of an Intermediary that has its RPACs issued by said suspended or cancelled Access Certificate Authority are revoked, the End-Relying Parties depending on said Intermediary, while having valid registration certificates from a Registrar will have no access to transact with EUDI Wallet Users until the End-Relying Parties a) transit to another Intermediary that has RPAC issued by an active Access Certification Authority or b) the original Access Certificate Authority can continue its operations and re-issue earlier revoked certificates for the original Intermediary.* |   New   |
 | RPACANot_07 | If a Registrar of Relying Party Registration Certificates is suspended or cancelled (see requirement GenNot_05 above), that Registrar of Relying Party Registration Certificates SHALL immediately revoke all of its valid registration certificates.  |   New   |
 | TLPub_01 | The European Commission SHALL establish technical specifications for the system enabling the publication by the Commission of the information notified by the Member States regarding PID Providers, Wallet Providers, PuB-EAA Providers, Access Certificate Authorities and Registrars of Registration Certificates. |  Keep with proposed changes  |
 | TLPub_02 | The European Commission SHALL establish technical specifications for the set of information to be published about: PID Providers, Wallet Providers,PuB-EAA Providers, Access Certificate Authorities and Registrars of Registration Certificates based on the information notified by the Member States. *Note: The information to be published MAY be different from the information to be notified per requirements PPNot_01, WPNot_01, PuBPNot_01, and RPACANot_01 above, respectively.* |  Keep with proposed changes  |