Orthography fixes 2025-11-24

docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md

@@ -244,7 +244,7 @@ for issuance), an underscore and a numerator, e.g. ISSU_10.
 | ISSU_11b | In case one or more of the verifications in ISSU_06 - ISSU_11 fail, the Wallet Unit SHALL immediately delete the PID or attestation it received. The Wallet Instance SHALL notify the User about the fact that issuance of the PID or attestation was not successful, including the reason for this failure. |
 | ISSU_12 | A PID Provider or Attestation Provider SHALL offer its PIDs or attestations in all formats required in the PID Rulebook or the applicable Attestation Rulebook, see [[Topic 12](./annex-2.02-high-level-requirements-by-topic.md#a239-topic-12---attestation-rulebooks)]. *Note: Examples include the mdoc format specified in [ISO/IEC 18013-5] and the SD-JWT VC-format specified in [SD-JWT VC].* |
 | ISSU_12a | A Wallet Provider SHALL ensure that, when a User instructs their Wallet Unit to request a PID or attestation from a PID Provider or Attestation Provider, the Wallet Unit requests that PID or attestation in all formats offered by the PID Provider or Attestation Provider. *Note: Examples include the mdoc format specified in [ISO/IEC 18013-5] and the SD-JWT VC-format specified in [SD-JWT VC].* |
-| ISSU_12b | During issuance of a PID or a device-bound attestation, the WSCA/WSCD or a key store SHALL generate a new key pair for a new PID or attestation, on request of the PID Provider or Attestation Provider via the Wallet Instance. *Note: See also WUA_05. In case of synchronous issuing in a remote HSM architecture, re-use of an existing key pair for the new PID or attestation may be acceptable and it may not be necessary to generate a new key pair for each new PID or attestation.* |
+| ISSU_12b | During issuance of a PID or a device-bound attestation, the WSCA/WSCD or a keystore SHALL generate a new key pair for a new PID or attestation, on request of the PID Provider or Attestation Provider via the Wallet Instance. *Note: See also WUA_05. In case of synchronous issuing in a remote HSM architecture, re-use of an existing key pair for the new PID or attestation may be acceptable and it may not be necessary to generate a new key pair for each new PID or attestation.* |
 | ISSU_12c | The expiration date of a PID SHALL be no later than the expiration date of the WUA presented as part of the PID issuance process. *Note: This requirement is an implication of WURevocation_18 in [Topic 38](./annex-2.02-high-level-requirements-by-topic.md#a2322-topic-38---wallet-unit-revocation). If the PID would be valid for longer than the WUA, the PID Provider would not be able to use the revocation information in the WUA to verify the revocation status of the Wallet Unit.* |
 | ISSU_12d | If an Attestation Provider supports revocation chaining for its attestations per WURevocation_19 in [Topic 38](./annex-2.02-high-level-requirements-by-topic.md#a2322-topic-38---wallet-unit-revocation), the expiration date of an attestation SHALL be no later than the expiration date of the WUA presented as part of the attestation issuance process. *Note: See note in ISSU_12c.* |
 
@@ -885,7 +885,7 @@ for issuance), an underscore and a numerator, e.g. ISSU_10.
 | WIAM_14 | A WSCA/WSCD managing the critical assets of a PID, such as private or secret cryptographic keys, SHALL authenticate the User before performing any cryptographic operation involving any of these assets. *Note: a) [CIR 2024/2981], Annex IV, section 2 (3) states "As a prerequisite to the certification under national certification schemes, the WSCD shall be assessed against the requirements of assurance level high as set out in Implementing Regulation (EU) 2015/1502". Therefore, a WSCA/WSCD by legal definition complies with requirements of LoA High. b) Note to WIAM_14 - WIAM_14b: Many actions of the Wallet Unit, such as processing a Relying Party presentation request and presenting an attestation, require multiple cryptographic operations, for example ephemeral key generation followed by key agreement and presentation signing and encryption. These requirements does not imply that a separate User authentication is necessary before each of these operations. Rather, a successful User authentication will be valid for all cryptographic operations necessary for a Wallet Unit action. It is up to the Wallet Provider to determine what constitutes a 'Wallet Unit action', finding a balance between security (more User authentications) and User convenience (fewer User authentications). During certification of the Wallet Solution, it will be verified that the solution provides an adequate level of security.* |
 | WIAM_14a | A WSCA/WSCD managing the critical assets of a WUA SHALL authenticate the User before performing any cryptographic operation involving any of these keys.  *Note: Since the WUA authenticates the Wallet Unit towards the PID Provider during PID issuance, WUAs must be managed at LoA High, and consequently WUA keys must be managed in the WSCA/WSCD.* |
 | WIAM_14b |  	A WSCA/WSCD managing the cryptographic assets of an attestation having a level of security High SHALL authenticate the User before performing any cryptographic operation involving any of these keys.  *Note: a) The term 'Level of Assurance', as used in the European Digital Identity Regulation and in Implementing Regulation (EU) 2015/1502, is only applicable to electronic identity means, which in the context of the EUDI Wallet means only the PID. For that reason, this requirement uses the term 'level of security'. b) During issuance of an attestation, the Attestation Provider in its Credential Issuer metadata indicates the level of security it requires for the key storage and user authentication for this type of attestation; see [OpenID4VCI] section 12.2.4 and Appendix D.2.* |
-| WIAM_14c | A Wallet Unit SHALL use a key store to manage any cryptographic assets that are not considered to be critical assets. *Note: a) The ARF uses the term 'key store' to refer to a hardware-backed repository and service in which non-critical cryptographic assets are generated, stored, and used exclusively inside a dedicated hardware security boundary. b) Examples of non-critical cryptographic assets are private and secret keys of attestations having a level of security lower than High. c) As mentioned in WIAM_14 and WIAM_14b, the private and secret keys of PIDs and WUAs are critical assets and therefore are stored in a WSCA/WSCD.* |
+| WIAM_14c | A Wallet Unit SHALL use a keystore to manage any cryptographic assets that are not considered to be critical assets. *Note: a) The ARF uses the term 'keystore' to refer to a hardware-backed repository and service in which non-critical cryptographic assets are generated, stored, and used exclusively inside a dedicated hardware security boundary. b) Examples of non-critical cryptographic assets are private and secret keys of attestations having a level of security lower than High. c) As mentioned in WIAM_14 and WIAM_14b, the private and secret keys of PIDs and WUAs are critical assets and therefore are stored in a WSCA/WSCD.* |
 | WIAM_15 | Before performing any operation, a Wallet Instance SHALL securely authenticate the User using a multi-factor authentication mechanism provided by the User device.  *Note: One of the authentication factors is the possession of the User device.* |
 | WIAM_15a | For the purpose of WIAM_15, the Wallet Instance SHALL enforce the activation of an OS-level User authentication mechanism with adequate security policies.  *Note: ‘Adequate’ here means adequate for any operation excluding the issuance or presentation of PIDs, WUAs, and potentially other attestations at level of security High. This includes but is not limited to generating pseudonyms, accessing the transaction log (dashboard), data export and migration, requesting the erasure of personal data by a Relying Party, and reporting a Relying Party to a DPA.* |
 | WIAM_15b | The Wallet Instance SHALL enable the User to optionally use a Wallet Instance-specific PIN for User authentication, in addition to the User authentication mechanism provided by the User device. |

docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md

@@ -248,7 +248,7 @@ as statements of fact.
 |AS-WP-40-017 | WIAM_14 | A WSCA/WSCD managing the critical assets of a PID, such as private or secret cryptographic keys, SHALL authenticate the User before performing any cryptographic operation involving any of these assets.| a) [CIR 2024/2981], Annex IV, section 2 (3) states "As a prerequisite to the certification under national certification schemes, the WSCD shall be assessed against the requirements of assurance level high as set out in Implementing Regulation (EU) 2015/1502". Therefore, a WSCA/WSCD by legal definition complies with requirements of LoA High. b) Note to WIAM_14 - WIAM_14b: Many actions of the Wallet Unit, such as processing a Relying Party presentation request and presenting an attestation, require multiple cryptographic operations, for example ephemeral key generation followed by key agreement and presentation signing and encryption. These requirements does not imply that a separate User authentication is necessary before each of these operations. Rather, a successful User authentication will be valid for all cryptographic operations necessary for a Wallet Unit action. It is up to the Wallet Provider to determine what constitutes a 'Wallet Unit action', finding a balance between security (more User authentications) and User convenience (fewer User authentications). During certification of the Wallet Solution, it will be verified that the solution provides an adequate level of security. |
 |AS-WP-40-018 | WIAM_14a | A WSCA/WSCD managing the critical assets of a WUA SHALL authenticate the User before performing any cryptographic operation involving any of these keys. | Since the WUA authenticates the Wallet Unit towards the PID Provider during PID issuance, WUAs must be managed at LoA High, and consequently WUA keys must be managed in the WSCA/WSCD. |
 |AS-WP-40-019 | WIAM_14b |  	A WSCA/WSCD managing the cryptographic assets of an attestation having a level of security High SHALL authenticate the User before performing any cryptographic operation involving any of these keys. | a) The term 'Level of Assurance', as used in the European Digital Identity Regulation and in Implementing Regulation (EU) 2015/1502, is only applicable to electronic identity means, which in the context of the EUDI Wallet means only the PID. For that reason, this requirement uses the term 'level of security'. b) During issuance of an attestation, the Attestation Provider in its Credential Issuer metadata indicates the level of security it requires for the key storage and user authentication for this type of attestation; see [OpenID4VCI] section 12.2.4 and Appendix D.2. |
-|AS-WP-40-020 | WIAM_14c | A Wallet Unit SHALL use a key store to manage any cryptographic assets that are not considered to be critical assets.| a) The ARF uses the term 'key store' to refer to a hardware-backed repository and service in which non-critical cryptographic assets are generated, stored, and used exclusively inside a dedicated hardware security boundary. b) Examples of non-critical cryptographic assets are private and secret keys of attestations having a level of security lower than High. c) As mentioned in WIAM_14 and WIAM_14b, the private and secret keys of PIDs and WUAs are critical assets and therefore are stored in a WSCA/WSCD. |
+|AS-WP-40-020 | WIAM_14c | A Wallet Unit SHALL use a keystore to manage any cryptographic assets that are not considered to be critical assets.| a) The ARF uses the term 'keystore' to refer to a hardware-backed repository and service in which non-critical cryptographic assets are generated, stored, and used exclusively inside a dedicated hardware security boundary. b) Examples of non-critical cryptographic assets are private and secret keys of attestations having a level of security lower than High. c) As mentioned in WIAM_14 and WIAM_14b, the private and secret keys of PIDs and WUAs are critical assets and therefore are stored in a WSCA/WSCD. |
 |AS-WP-40-021 | WIAM_15 | Before performing any operation, a Wallet Instance SHALL securely authenticate the User using a multi-factor authentication mechanism provided by the User device. | One of the authentication factors is the possession of the User device. |
 |AS-WP-40-022 | WIAM_15a | For the purpose of WIAM_15, the Wallet Instance SHALL enforce the activation of an OS-level User authentication mechanism with adequate security policies. | ‘Adequate’ here means adequate for any operation excluding the issuance or presentation of PIDs, WUAs, and potentially other attestations at level of security High. This includes but is not limited to generating pseudonyms, accessing the transaction log (dashboard), data export and migration, requesting the erasure of personal data by a Relying Party, and reporting a Relying Party to a DPA. |
 |AS-WP-40-023 | WIAM_15b | The Wallet Instance SHALL enable the User to optionally use a Wallet Instance-specific PIN for User authentication, in addition to the User authentication mechanism provided by the User device.|  |
@@ -420,7 +420,7 @@ as statements of fact.
 |AS-AP-10-012 | ISSU_11b | In case one or more of the verifications in ISSU_06 - ISSU_11 fail, the Wallet Unit SHALL immediately delete the PID or attestation it received. The Wallet Instance SHALL notify the User about the fact that issuance of the PID or attestation was not successful, including the reason for this failure.|  |
 |AS-AP-10-013 | ISSU_12 | A PID Provider or Attestation Provider SHALL offer its PIDs or attestations in all formats required in the PID Rulebook or the applicable Attestation Rulebook, see [[Topic 12](./annex-2.02-high-level-requirements-by-topic.md#a239-topic-12---attestation-rulebooks)].| Examples include the mdoc format specified in [ISO/IEC 18013-5] and the SD-JWT VC-format specified in [SD-JWT VC]. |
 |AS-AP-10-014 | ISSU_12a | A Wallet Provider SHALL ensure that, when a User instructs their Wallet Unit to request a PID or attestation from a PID Provider or Attestation Provider, the Wallet Unit requests that PID or attestation in all formats offered by the PID Provider or Attestation Provider.| Examples include the mdoc format specified in [ISO/IEC 18013-5] and the SD-JWT VC-format specified in [SD-JWT VC]. |
-|AS-AP-10-015 | ISSU_12b | During issuance of a PID or a device-bound attestation, the WSCA/WSCD or a key store SHALL generate a new key pair for a new PID or attestation, on request of the PID Provider or Attestation Provider via the Wallet Instance.| See also WUA_05. In case of synchronous issuing in a remote HSM architecture, re-use of an existing key pair for the new PID or attestation may be acceptable and it may not be necessary to generate a new key pair for each new PID or attestation. |
+|AS-AP-10-015 | ISSU_12b | During issuance of a PID or a device-bound attestation, the WSCA/WSCD or a keystore SHALL generate a new key pair for a new PID or attestation, on request of the PID Provider or Attestation Provider via the Wallet Instance.| See also WUA_05. In case of synchronous issuing in a remote HSM architecture, re-use of an existing key pair for the new PID or attestation may be acceptable and it may not be necessary to generate a new key pair for each new PID or attestation. |
 |AS-AP-10-016 | ISSU_12c | The expiration date of a PID SHALL be no later than the expiration date of the WUA presented as part of the PID issuance process.| This requirement is an implication of WURevocation_18 in [Topic 38](./annex-2.02-high-level-requirements-by-topic.md#a2322-topic-38---wallet-unit-revocation). If the PID would be valid for longer than the WUA, the PID Provider would not be able to use the revocation information in the WUA to verify the revocation status of the Wallet Unit. |
 |AS-AP-10-017 | ISSU_12d | If an Attestation Provider supports revocation chaining for its attestations per WURevocation_19 in [Topic 38](./annex-2.02-high-level-requirements-by-topic.md#a2322-topic-38---wallet-unit-revocation), the expiration date of an attestation SHALL be no later than the expiration date of the WUA presented as part of the attestation issuance process.| See note in ISSU_12c. |
 |AS-AP-10-018 | ISSU_13 | A Wallet Provider SHALL ensure that at least one PID Provider is willing to issue a PID complying with [PID Rulebook] to Users of the Wallet Units it provides.|  |

docs/annexes/annex-5/annex-5.02-design-guide-data-sharing-scenarios.md

@@ -51,7 +51,7 @@ the EUDI Wallet User is physically close to a Relying Party, the user does not
 necessarily have internet connectivity and the data presentation occurs using
 proximity protocols (NFC, Bluetooth, QR- Code, etc.). The key differentiator in
 the two proximity flows, is that in the supervised flow, the EUDI Wallet
-presents data (e.g. a mobile driving license) to, or under the supervision of, a
+presents data (e.g. a mobile driving licence) to, or under the supervision of, a
 human acting as a Relying Party (who may operate a device of their own). In the
 unsupervised flow, the EUDI Wallet presents verifiable attributes to a machine
 without human supervision.

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

@@ -1082,7 +1082,7 @@ particular,
     Units, and if so, which one.
     - For a PID Provider, QEAA Provider, PuB-EAA Provider, or non-qualified EAA
     Provider, the Registrar registers the attestation type(s) this entity wants
-    to issue to Wallet Units, for example, diplomas, driving licenses, or vehicle
+    to issue to Wallet Units, for example, diplomas, driving licences, or vehicle
     registration cards.
 - Registered entities receive an access certificate from an Access Certificate
 Authority, as described in [Section 3.18](#318-access-certificate-authorities).
@@ -1301,7 +1301,7 @@ which is an instance of a Wallet Solution and belongs to and is controlled by a
 User. This component implements the core business logic and interfaces as
 depicted in Figure 2. It directly interacts with the WSCA (which is interacting
 with the WSCD, see bullets hereafter) to securely manage critical assets and
-execute cryptographic functions. It interfaces with one or more key stores for
+execute cryptographic functions. It interfaces with one or more keystores for
 the management of non-critical cryptographic assets.
 
 - **Wallet Secure Cryptographic Device (WSCD)**: A tamper-resistant device that

docs/discussion-topics/f-digital-credential-api.md

@@ -533,7 +533,7 @@ any vendor, protocol, or format.
 ### A. What is the W3C Digital Credentials API?
 
 It's a Web API that lets wallets present and relying parties request and
-(optionally) issue digital credentials (e.g., ID cards, driving licenses,
+(optionally) issue digital credentials (e.g., ID cards, driving licences,
 diplomas) via the browser (user agent). It's protocol- and format-agnostic and
 builds on Credential Management Level 1.