Deploy to GitHub pages

refs/pull/233/merge/en/_sources/defined-terms.rst.txt

@@ -38,7 +38,7 @@ Below are the description of acronyms and definitions which are useful for furth
    * - Wallet Attestation
      - Verifiable Attestation, issued by the Wallet Provider, that proves the security compliace of the Wallet Instance.
    * - Wallet Secure Cryptographic Device
-     - Hardware-backed secure environment for creating, storing, and/or managing cryptographic keys and data. Examples include Secure Elements (SE), Trusted Execution Environments (TEEs), and Strongbox.
+     - Hardware-backed secure environment for creating, storing, and/or managing cryptographic keys and data. A WSCD MAY implement an association proof in different ways. This largely depends on the implementation of the WSCD for example: remote HSM, external smart card, internal UICC, internal native cryptographic hardware, such as the iOS Secure Enclave or the Android Hardware Backed Keystore or StrongBox
    * - Credential Status Attestation
      - Verifiable Attestation proving that a related Digital Credential is not revoked.
    * - Device Integrity Service

refs/pull/233/merge/en/_sources/wallet-attestation.rst.txt

@@ -16,7 +16,6 @@ The following requirements for the Wallet Attestation are met:
 - The Wallet Attestation MUST give all the relevant information to attests the **integrity** and **security** of the device where the Wallet Instance is installed.
 - The Wallet Attestation MUST be issued and signed by an accredited and reliable Wallet Provider, thereby providing integrity and authenticity to the attestation.
 - The Wallet Provider MUST ensure the integrity, authenticity, and genuineness of the Wallet Instance, preventing any attempts at manipulation or falsification by unauthorized third parties.
-- The private keys MUST be generated and securely stored in the WSCD. It MAY be internal, external, or hybrid depending on the AAL required.
 - The Wallet Attestation MUST have a mechanism in place for revoking the Wallet Instance, allowing the Wallet Provider to terminate service for a specific instance at any time.
 - The Wallet Attestation MUST be securely bound to the Wallet Instance ephemeral public key.
 - The Wallet Attestation MAY be usable multiple times during its validity period, allowing for repeated authentication and authorization without the need to request new attestations with each interaction.
@@ -25,6 +24,14 @@ 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:
+
+  - **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.
+
+.. 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.
 
 Static Component View
 ---------------------
@@ -123,6 +130,12 @@ Wallet Instance initialization and registration
 .. note::
   It is not necessary to send the Wallet Hardware public key because it is already included in the ``key_attestation``.
 
+.. warning::
+  During the registration phase of the Wallet Instance with the Wallet Provider it is also necessary to associate it with a specific user
+  uniquely identifiable by the Wallet Provider. This association is at the discretion of the Wallet PRovider and will not be addressed
+  within these guidelines as each Wallet Provider may or may not have a user identification system already implemented.
+
+
 **Steps 10-12**: The Wallet Provider validates the ``challenge`` and ``key_attestation`` signature, therefore:
 
   1. It MUST verify that the ``challenge`` was generated by Wallet Provider and has not already been used.
@@ -490,4 +503,4 @@ The body of the Wallet Attestation JWT MUST contain:
 .. _Play Integrity API: https://developer.android.com/google/play/integrity?hl=it
 .. _DeviceCheck: https://developer.apple.com/documentation/devicecheck
 .. _OAuth 2.0 Nonce Endpoint: https://datatracker.ietf.org/doc/draft-demarco-oauth-nonce-endpoint/
-
+.. _ARF: https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework

refs/pull/233/merge/en/defined-terms.html

@@ -1101,7 +1101,7 @@ <h1>Defined Terms<a class="headerlink" href="#defined-terms" title="Permalink to
 <td><p>Verifiable Attestation, issued by the Wallet Provider, that proves the security compliace of the Wallet Instance.</p></td>
 </tr>
 <tr class="row-odd"><td><p>Wallet Secure Cryptographic Device</p></td>
-<td><p>Hardware-backed secure environment for creating, storing, and/or managing cryptographic keys and data. Examples include Secure Elements (SE), Trusted Execution Environments (TEEs), and Strongbox.</p></td>
+<td><p>Hardware-backed secure environment for creating, storing, and/or managing cryptographic keys and data. A WSCD MAY implement an association proof in different ways. This largely depends on the implementation of the WSCD for example: remote HSM, external smart card, internal UICC, internal native cryptographic hardware, such as the iOS Secure Enclave or the Android Hardware Backed Keystore or StrongBox</p></td>
 </tr>
 <tr class="row-even"><td><p>Credential Status Attestation</p></td>
 <td><p>Verifiable Attestation proving that a related Digital Credential is not revoked.</p></td>

refs/pull/233/merge/en/wallet-attestation.html

@@ -1071,16 +1071,26 @@ <h2>Requirements<a class="headerlink" href="#requirements" title="Permalink to t
 <li><p>The Wallet Attestation MUST give all the relevant information to attests the <strong>integrity</strong> and <strong>security</strong> of the device where the Wallet Instance is installed.</p></li>
 <li><p>The Wallet Attestation MUST be issued and signed by an accredited and reliable Wallet Provider, thereby providing integrity and authenticity to the attestation.</p></li>
 <li><p>The Wallet Provider MUST ensure the integrity, authenticity, and genuineness of the Wallet Instance, preventing any attempts at manipulation or falsification by unauthorized third parties.</p></li>
-<li><p>The private keys MUST be generated and securely stored in the WSCD. It MAY be internal, external, or hybrid depending on the AAL required.</p></li>
 <li><p>The Wallet Attestation MUST have a mechanism in place for revoking the Wallet Instance, allowing the Wallet Provider to terminate service for a specific instance at any time.</p></li>
 <li><p>The Wallet Attestation MUST be securely bound to the Wallet Instance ephemeral public key.</p></li>
 <li><p>The Wallet Attestation MAY be usable multiple times during its validity period, allowing for repeated authentication and authorization without the need to request new attestations with each interaction.</p></li>
 <li><p>The Wallet Attestation MUST be short-lived and MUST have an expiration date time, after which SHOULD no longer be considered valid.</p></li>
 <li><p>The Wallet Attestation MUST NOT be issued by the Wallet Provider if the authenticity, integrity, and genuineness are not guaranteed. In this case, the Wallet Instance MUST be revoked.</p></li>
 <li><p>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).</p></li>
 <li><p>The Wallet Attestation MUST NOT contain any information that can be used to directly reference the User.</p></li>
-<li><p>The Wallet Instances MUST secure a Wallet Attestation as a prerequisite for transitioning to the Operational state, as defined by <a href="#id5"><span class="problematic" id="id6">`ARF`_</span></a>.</p></li>
+<li><p>The Wallet Instances MUST secure a Wallet Attestation as a prerequisite for transitioning to the Operational state, as defined by <a class="reference external" href="https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework">ARF</a>.</p></li>
+<li><p>The private keys MUST be generated and stored in the WSCD following different approaches:</p>
+<ul>
+<li><p><strong>Internal WSCD</strong>: 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.</p></li>
+<li><p><strong>External WSCD</strong>: 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.</p></li>
+<li><p><strong>Hybrid WSCD</strong>: 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.</p></li>
 </ul>
+</li>
+</ul>
+<div class="admonition warning">
+<p class="admonition-title">Warning</p>
+<p>The implementation profile specification, that will be given below, MUST support only the <strong>Internal WSCD</strong>. Future versions of this specification MAY include other approaches depending on the <cite>AAL</cite> required.</p>
+</div>
 </section>
 <section id="static-component-view">
 <h2>Static Component View<a class="headerlink" href="#static-component-view" title="Permalink to this heading">¶</a></h2>
@@ -1166,6 +1176,12 @@ <h3>Wallet Instance initialization and registration<a class="headerlink" href="#
 <p class="admonition-title">Note</p>
 <p>It is not necessary to send the Wallet Hardware public key because it is already included in the <code class="docutils literal notranslate"><span class="pre">key_attestation</span></code>.</p>
 </div>
+<div class="admonition warning">
+<p class="admonition-title">Warning</p>
+<p>During the registration phase of the Wallet Instance with the Wallet Provider it is also necessary to associate it with a specific user
+uniquely identifiable by the Wallet Provider. This association is at the discretion of the Wallet PRovider and will not be addressed
+within these guidelines as each Wallet Provider may or may not have a user identification system already implemented.</p>
+</div>
 <p><strong>Steps 10-12</strong>: The Wallet Provider validates the <code class="docutils literal notranslate"><span class="pre">challenge</span></code> and <code class="docutils literal notranslate"><span class="pre">key_attestation</span></code> signature, therefore:</p>
 <blockquote>
 <div><ol class="arabic simple">