diff --git a/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md b/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md index 1d033612..44f9dd2f 100644 --- a/docs/annexes/annex-2/annex-2.02-high-level-requirements-by-topic.md +++ b/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. | diff --git a/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md b/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md index c14fb0f2..fc336316 100644 --- a/docs/annexes/annex-2/annex-2.03-high-level-requirements-by-category.md +++ b/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.| | diff --git a/docs/annexes/annex-5/annex-5.02-design-guide-data-sharing-scenarios.md b/docs/annexes/annex-5/annex-5.02-design-guide-data-sharing-scenarios.md index da021165..63028aca 100644 --- a/docs/annexes/annex-5/annex-5.02-design-guide-data-sharing-scenarios.md +++ b/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. diff --git a/docs/architecture-and-reference-framework-main.md b/docs/architecture-and-reference-framework-main.md index 104a16eb..7170286c 100644 --- a/docs/architecture-and-reference-framework-main.md +++ b/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 diff --git a/docs/discussion-topics/f-digital-credential-api.md b/docs/discussion-topics/f-digital-credential-api.md index cd4fa257..c69f7802 100644 --- a/docs/discussion-topics/f-digital-credential-api.md +++ b/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. diff --git a/docs/discussion-topics/r-authentication-of-user-to-device.md b/docs/discussion-topics/r-authentication-of-user-to-device.md index a05adaed..1aefb78c 100644 --- a/docs/discussion-topics/r-authentication-of-user-to-device.md +++ b/docs/discussion-topics/r-authentication-of-user-to-device.md @@ -232,7 +232,7 @@ The existing HLRs were listed in section 3.2 above. The tables below contain the | WIAM_14a | A WSCA/WSCD managing the critical assets of a PID, such as private or secret cryptographic SHALL authenticate the User before performing any cryptographic operation involving any of these assets. _Note to WIAM_14a - WIAM_14c: 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_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: 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 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 WSCD. See also ISSU_XX._ | -| WIAM_14d | A Wallet Instance SHALL use a local key store provided by the User device to manage any cryptographic assets that are not considered to be critical assets. _Notes: - An example of such cryptographic assets are private and secret keys of attestations. - As mentioned in WIAM_14a and WIAM_14c, the private and secret keys of PIDs and WUAs are critical assets and therefore are stored in a WSCA/WSCD._ | +| WIAM_14d | A Wallet Instance SHALL use a local keystore provided by the User device to manage any cryptographic assets that are not considered to be critical assets. _Notes: - An example of such cryptographic assets are private and secret keys of attestations. - As mentioned in WIAM_14a and WIAM_14c, 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 | The Wallet Unit 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. | diff --git a/docs/media/Figure_2_High-Level_Architecture.xml b/docs/media/Figure_2_High-Level_Architecture.xml index a00793b8..cc6be847 100644 --- a/docs/media/Figure_2_High-Level_Architecture.xml +++ b/docs/media/Figure_2_High-Level_Architecture.xml @@ -208,7 +208,7 @@ - + diff --git a/hltr/high-level-requirements.csv b/hltr/high-level-requirements.csv index b62eb487..1766df14 100644 --- a/hltr/high-level-requirements.csv +++ b/hltr/high-level-requirements.csv @@ -126,7 +126,7 @@ AS-AP-10-011;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - AS-AP-10-012;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;A - Generic HLRs;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;Actor-Specific Requirements;Attestation & PID Providers;Topic 10 - Issuing a PID or attestation to a Wallet Unit;10;Issuing a PID or attestation to a Wallet Unit;B - HLRs for PID issuance;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.; @@ -506,7 +506,7 @@ AS-WP-40-016;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Inst AS-WP-40-017;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;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;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;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;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;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;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;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;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;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;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;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;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;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;Actor-Specific Requirements;Wallet Providers;Topic 40 - Wallet Instance installation and Wallet Unit activation and management;40;Wallet Instance installation and Wallet Unit activation and management;C. HLRs for Wallet Unit management;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.;