diff --git a/refs/pull/242/merge/en/.doctrees/environment.pickle b/refs/pull/242/merge/en/.doctrees/environment.pickle index cd05c3366..a75337e9e 100644 Binary files a/refs/pull/242/merge/en/.doctrees/environment.pickle and b/refs/pull/242/merge/en/.doctrees/environment.pickle differ diff --git a/refs/pull/242/merge/en/.doctrees/wallet-attestation.doctree b/refs/pull/242/merge/en/.doctrees/wallet-attestation.doctree index 4397ac809..383594e57 100644 Binary files a/refs/pull/242/merge/en/.doctrees/wallet-attestation.doctree and b/refs/pull/242/merge/en/.doctrees/wallet-attestation.doctree differ diff --git a/refs/pull/242/merge/en/.doctrees/wallet-solution.doctree b/refs/pull/242/merge/en/.doctrees/wallet-solution.doctree index 21ce1d7f3..b095846d5 100644 Binary files a/refs/pull/242/merge/en/.doctrees/wallet-solution.doctree and b/refs/pull/242/merge/en/.doctrees/wallet-solution.doctree differ diff --git a/refs/pull/242/merge/en/_sources/wallet-attestation.rst.txt b/refs/pull/242/merge/en/_sources/wallet-attestation.rst.txt index 9eaaf37ab..9692e0922 100644 --- a/refs/pull/242/merge/en/_sources/wallet-attestation.rst.txt +++ b/refs/pull/242/merge/en/_sources/wallet-attestation.rst.txt @@ -24,14 +24,17 @@ The following requirements for the Wallet Attestation are met: - Each Wallet Instance SHOULD be able to request multiple attestations with different ephemeral public keys associated to them. This requirement provides a privacy-preserving measure, as the public key MAY be used as a tracking tool during the presentation phase (see also the point listed below). - The Wallet Attestation MUST NOT contain any information that can be used to directly reference the User. - The Wallet Instances MUST secure a Wallet Attestation as a prerequisite for transitioning to the Operational state, as defined by `ARF`_. -- The private keys MUST be generated and stored in the WSCD following different approaches: +- Private keys MUST be generated and stored in the WSCD using at least one of the approaches listed below: - - **Internal WSCD**: The WSCD here is solely based on the native cryptographic hardware of the User device, for instance the (iOS) Secure Enclave or the (Android) Hardware Backed Keystore or Strongbox. - - **External WSCD**: The WSCD here is based on a remote Hardware Security Module (HSM) hosted by (or on behalf of) the Wallet Provider or is a chip external to the User device, e.g., a smart card based on GlobalPlatform, and supporting JavaCard. - - **Hybrid WSCD**: The WSCD here is based on a dedicated, internal chip integrated in the User device, e.g. an eUICC based on GlobalPlatform, and supporting JavaCard. + - **Local Internal WSCD**: in this approach, the WSCD relies entirely on the device's native cryptographic hardware, such as the Secure Enclave on iOS devices or the Hardware Backed Keystore or Strongbox on Android devices. + - **Local External WSCD**: the WSCD is an hardware external to the User's device, such as a smart card compliant with _GlobalPlatform_ and supporting _JavaCard_. + - **Remote WSCD**: Here, the WSCD utilizes a remote Hardware Security Module (HSM). + + - **Local Hybrid WSCD**: the WSCD involves a pluggable internal hardware component within the User's device, such as an _eUICC_ that adheres to _GlobalPlatform_ standards and supports _JavaCard_. + - **Remote Hybrid WSCD**: the WSCD involves a local component mixed with a remote service. .. warning:: - The implementation profile specification, that will be given below, MUST support only the **Internal WSCD**. Future versions of this specification MAY include other approaches depending on the `AAL` required. + At the current stage, the current implementation profile defined in this document supports only the **Local Internal WSCD**. Future versions of this specification MAY include other approaches depending on the required `AAL`. Static Component View --------------------- @@ -46,7 +49,7 @@ Dynamic Component View The Wallet Attestation acquisition flow can be divided into two main phases. The first phase involves device initialization and registration, which occurs only during the initial launch of the Wallet Instance (after installation). The second phase pertains to the actual acquisition of the Wallet Attestation. -Wallet Instance initialization and registration +Wallet Instance Initialization and Registration ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. figure:: ../../images/wallet_instance_initialization.svg @@ -280,7 +283,7 @@ encoded in ``application/x-www-form-urlencoded`` format: Content-Type: application/x-www-form-urlencoded grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer - &assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6ImtoakZWTE9nRjNHeG...redacted + &assertion=eyJhbGciOiJFUzI1NiIsImtpZCI6ImtoakZWTE9nRjNHeG... **Steps 13-17**: The Wallet Provider's backend assesses the Wallet Attestation Request and issues a Wallet Attestation, if the requirements described below are satisfied: @@ -509,17 +512,20 @@ A Wallet Instance SHOULD obtain a Wallet Attestation if it's in either `Installe States ~~~~~~~~~~~~~~~~~~ -+---------------+--------------------------------------------------------------------------------------------------------------------------------+ -| State | Description | -+===============+================================================================================================================================+ -| `Installed` | The Holder has installed the Wallet Solution on the device | -+---------------+--------------------------------------------------------------------------------------------------------------------------------+ -| `Operational` | The Wallet Instance has been verified and the Wallet Hardware Key has been registered; no valid PID is present in the storage. | -+---------------+--------------------------------------------------------------------------------------------------------------------------------+ -| `Valid` | A valid PID is present in the storage | -+---------------+--------------------------------------------------------------------------------------------------------------------------------+ -| `Deactivated` | The Wallet Instance has been revoked and its Wallet Hardware Key has been marked as not usable | -+---------------+--------------------------------------------------------------------------------------------------------------------------------+ +.. list-table:: + :widths: 20 60 + :header-rows: 1 + + * - **State** + - **Description** + * - `Installed` + - The User has installed the Wallet Solution on the device. + * - `Operational` + - The Wallet Instance has been verified and the Wallet Hardware Key has been registered; no valid PID is present in the storage. + * - `Valid` + - A valid PID is present in the storage. + * - `Deactivated` + - The Wallet Instance has been revoked and its Wallet Hardware Key has been marked as not usable. Transitions ~~~~~~~~~~~~~~~~~~ @@ -545,18 +551,15 @@ Transitions Revocations ~~~~~~~~~~~~~~~~~~ As mentioned in the *Wallet Instance initialization and registration* section above, a Wallet Instance is bound to a Wallet Hardware Key and it's uniquely identified by it. -The Wallet Instance shares its Wallet Hardware Key only with the Wallet Provider, thus the Wallet Provider is the only entity that can identify a Wallet Instance by its Wallet Hardware Key. +The Wallet Instance SHOULD send its public Wallet Hardware Key with the Wallet Provider, thus the Wallet Provider MUST identify a Wallet Instance by its Wallet Hardware Key. When a Wallet Instance is not usable anymore, the Wallet Provider MUST revoke it. The revocation process is a unilateral action taken by the Wallet Provider, and it MUST be performed when the Wallet Instance is in the `Operational` or `Valid` state. A Wallet Instance becomes unusable for several reasons, such as: the User requests the revocation, the Wallet Provider detects a security issue, or the Wallet Instance is no longer compliant with the Wallet Provider's security requirements. The details of the revocation mechanism used by the Wallet Provider as well as the data model for maintaining the Wallet Instance references is delegated to the Wallet Provider's implementation. -During the *Wallet Instance initialization and registration* phase the Wallet Provider MAY associate the Wallet Instance with a specific User. The User SHOULD be uniquely identified as well as with metadata regarding the device the Wallet Instance is running on, the metadata MAY include data related to the operative system and general technical capabilities of the device. -These information allow the User to request the Wallet revocation directly interacting with the Wallet Provider as well as enabling the Wallet Provider to revoke a specific Wallet Instance. - -The choice of which data need to be stored is left to the Wallet Provider. - +During the *Wallet Instance initialization and registration* phase the Wallet Provider MAY associate the Wallet Instance with a specific User, subject to obtaining the User's consent. The Wallet Provider MUST evaluate the operating system and general technical capabilities of the device to check compliance with the technical and security requirements and to produce the Wallet Instance metadata. +When the User consents to being linked with the Wallet Instance, they gain the ability to directly request Wallet revocation from the Wallet Provider, and it also allows the Wallet Provider to revoke the Wallet Instance associated with that User. diff --git a/refs/pull/242/merge/en/_sources/wallet-solution.rst.txt b/refs/pull/242/merge/en/_sources/wallet-solution.rst.txt index 5190bacfb..31fd4893c 100644 --- a/refs/pull/242/merge/en/_sources/wallet-solution.rst.txt +++ b/refs/pull/242/merge/en/_sources/wallet-solution.rst.txt @@ -46,7 +46,7 @@ Transition to Valid state ~~~~~~~~~~~~~~~~~~~~~~~~~ To transition from the Operational state to the Valid state, the Wallet Instance MUST obtain a valid Personal Identification (PID). Once a valid PID is acquired, the Wallet Instance becomes Valid. -In order to securely and unambiguously identify Users, the Wallet Instance requires a Level of Assurance (LoA) 3, which guarantees both the User's identity and the device security. The authentication method is chosen by the PID Provider from among the notified eID solutions at the national level. +To securely and unambiguously authenticate Users, the Wallet Instance necessitates a High Level of Assurance (LoA 3) for User authentication. The method to achieve this LoA is selected by the PID Provider based on the identity proofing method employed during the provisioning of the Digital Credential to the User. Furthermore, to store the acquired Digital Credential, the Wallet Instance MUST demonstrate to the Credential Issuer an adequate security compliance to maintain the Credential at the same LoA at which it was issued. Once the Wallet Instance is in the Operational state, Users can: diff --git a/refs/pull/242/merge/en/algorithms.html b/refs/pull/242/merge/en/algorithms.html index b07f3a0c0..2cc8c943a 100644 --- a/refs/pull/242/merge/en/algorithms.html +++ b/refs/pull/242/merge/en/algorithms.html @@ -642,7 +642,7 @@

{{ item.title }}

  • Requirements
  • Static Component View
  • Dynamic Component View