Deploy to GitHub pages

wallet-attestation/en/_sources/defined-terms.rst.txt

@@ -43,10 +43,10 @@ Below are the description of acronyms and definitions which are useful for furth
      - Verifiable Attestation proving that a related Digital Credential is not revoked.
    * - Device Integrity Service
      - A service provided by device manufacturers that verifies the integrity and authenticity of the app instance (Wallet Instance), as well as certifying the secure storage of private keys generated by the device within its dedicated hardware. It's important to note that the terminology used to describe this service varies among manufacturers.
-   * - Wallet Hardware Keys
-     - During the app initialization, the Wallet Instance generates a pair of keys, one public and one private, which remain valid for the entire duration of the Wallet Instance's life. Functioning as a Master Key for the personal device, these Wallet Hardware Keys are confined to the OS domain and are not designed for signing arbitrary payloads. Their primary role is to provide a unique identification for each Wallet Instance.
-   * - Wallet Hardware Key Tag
-     - A unique identifier created by the operating system for the Wallet Hardware Keys, utilized to gain access to the private key stored in the hardware.
+   * - Cryptographic Hardware Keys
+     - During the app initialization, the Wallet Instance generates a pair of keys, one public and one private, which remain valid for the entire duration of the Wallet Instance's life. Functioning as a Master Key for the personal device, these Cryptographic Hardware Keys are confined to the OS domain and are not designed for signing arbitrary payloads. Their primary role is to provide a unique identification for each Wallet Instance.
+   * - Cryptographic Hardware Key Tag
+     - A unique identifier created by the operating system for the Cryptographic Hardware Keys, utilized to gain access to the private key stored in the hardware.
    * - Key Attestation
      - An attestation from the device's OEM that enhances your confidence in the keys used in your Wallet Instance being securely stored within the device's hardware-backed keystore.
    * - Qualified Electronic Attestation of Attributes (QEAA)

wallet-attestation/en/_sources/wallet-attestation.rst.txt

@@ -46,13 +46,13 @@ 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
    :name: Sequence Diagram for Wallet Instance Initialization
    :alt: The figure illustrates the sequence diagram for initializa a Wallet Instance, with the steps explained below.
-   :target: https://www.plantuml.com/plantuml/uml/TLFHRjD047o_hrYb3xHM-84ye288QLMWY1HuNjiRPnNdpjfR1yBNisUd8RRY1rkdlPdPcR5y7nL5sttjiDNWstrEuhPS4cn2q3pySMyQ0t313Nfr3WiD0hCVaMG66A6rWxj0mEmNrZKfF7fJzWLrA6mQ6A8-qe4BCfHI9Qn7M9FOv0H7ZN0J6s5VLKBahsxu9k5WHWLoB7RaouwQ5pldAWbj0y7NHsYRu6734XNO71aJbMqKDg1RIiPSYl3sdPqMq9KHNs_WjYSQu2u5vmDgJx7dnFYmfM87l86fGC2Mvu1SOrwJS-A34eG3IHAQcrsu-VouUdXPVLyklxfURXpG9581hwO_aGtx6EXB2BaYUs0plYV54XMTrT5jSgxtQdiMi2A5B2ksITrNb6NdK5rjzfo1dYIDWoTGtbEgO4HDwBw3qKL90zLpLMTLmvy2Fg2Klr48dkWOiyn2idIHeWQPmC4BLbbsaaMD2q1LYcfNjsSRSvXWthd4-MyyZTzt_AvFyn2vybH2VeJdvPUByjPMwJ3f_2hVx4yRdwxy9zPSeevQlWeOBnt0rjFDnU5NUtwwygdiClqE2nZznNPWPRFmbyfBcb6S5UFkxTNkwty0
+   :target: https://www.plantuml.com/plantuml/uml/ZLFHRjD047o_hrYb3xHM-84yeA8Iqgf04IdmlBOtpYhEdRMt3eIlPy-cQMoPmeCZQszcTcOklewAeks-TjXgyEq-9t5RBWas8MWUVhfNZG6uu0QzEeU51e7PrqWo0upGseixGy3iEzOrATnvK_O5TIXi6XYYtj612pAKKYMiHrYJf4aFHurm4HjXNrL2v2StV9PmCAC2EHOxycL7pOkTSvM4je7WwoEqJV2mOOaAR8wCYSes2XlGBILZBaLu_SRU5j2L4PzEuB8d6k0g1US3Qa-nvm_ZPal53dW3Vmi4R7aEo3NcDJadFfX6E90aeRdPXOiFTwlRnzMNvVAJw-N60KqY5V1a-ZtPi8-1leIGAx87DkDxKYnHqLaTtIRdUg-sPm4hqyooOflKVKLPzXmgrMRF2UX9qZXu0kKzfGf6r8JkEnWTb3HGFLLrKZNyZHmR3PLWi-K2Rb7A7oW4ztICMMPPMRfaKOEy38T7h6ndlmGrBW1LAQeTNPvCpU5bWIkNgCzfqlXj9zELR8uYLvvAo8_miFnurkZQUXx6dq_oBSn_nPY-ZczOSuawke59m7Zt0BR-PvrnUB4FznEtQOVfYrd0w4Et5rOs9x-eFASP9VqTtRNzjFlwDm00
 
 **Step 1:**: The User starts the Wallet Instance mobile app for the first time.
 
@@ -82,19 +82,19 @@ Wallet Instance initialization and registration
       "nonce": "d2JhY2NhbG91cmVqdWFuZGFt"
     }
 
-**Step 6**: The Wallet Instance, through the operating system, creates a pair of Wallet Hardware Keys and stores the corresponding Wallet Hardware Key Tag in local storage once the following requirements are met:
+**Step 6**: The Wallet Instance, through the operating system, creates a pair of Cryptographic Hardware Keys and stores the corresponding Cryptographic Hardware Key Tag in local storage once the following requirements are met:
 
-   1. It MUST ensure that Wallet Hardware Keys do not already exist, if they exist and the Wallet is in the initialization phase they MUST be deleted.
-   2. It MUST generate a pair of asymmetric Elliptic Curve keys (Wallet Hardware Keys) via a local WSCD.
-   3. It SHOULD obtain a unique identifier (Wallet Hardware Key Tag) for the generated Wallet Hardware Keys from the operating system. If the operating system permits specifying a tag during the creation of keys, then a random string for the Wallet Hardware Key Tag MUST be selected. This random value MUST be collision-resistant and unpredictable to ensure security. To achieve this, consider using a cryptographic hash function or a secure random number generator provided by the operating system or a reputable cryptographic library.
-   4. If the previous points are satisfied, It MUST store the Wallet Hardware Key Tag in a local storage.
+   1. It MUST ensure that Cryptographic Hardware Keys do not already exist, if they exist and the Wallet is in the initialization phase they MUST be deleted.
+   2. It MUST generate a pair of asymmetric Elliptic Curve keys (Cryptographic Hardware Keys) via a local WSCD.
+   3. It SHOULD obtain a unique identifier (Cryptographic Hardware Key Tag) for the generated Cryptographic Hardware Keys from the operating system. If the operating system permits specifying a tag during the creation of keys, then a random string for the Cryptographic Hardware Key Tag MUST be selected. This random value MUST be collision-resistant and unpredictable to ensure security. To achieve this, consider using a cryptographic hash function or a secure random number generator provided by the operating system or a reputable cryptographic library.
+   4. If the previous points are satisfied, It MUST store the Cryptographic Hardware Key Tag in a local storage.
 
 .. note::
 
     **WSCD:** The Wallet Instance MAY use a local WSCD for key generation on devices that support this feature. On Android devices, Strongbox is RECOMMENDED, Trusted Execution Environment (TEE) SHOULD be used only when Strongbox is unavailable. For iOS devices, Secure Elements (SE) SHOULD be used. Given that each OEM offers a distinct SDK for accessing the local WSCD, the discussion hereafter will address this topic in a general context.
 
 
-**Step 7**: The Wallet Instance uses the Device Integrity Service, providing a "challenge" and the Wallet Hardware Key Tag to acquire the Key Attestation.
+**Step 7**: The Wallet Instance uses the Device Integrity Service, providing a "challenge" and the Cryptographic Hardware Key Tag to acquire the Key Attestation.
 
 .. note::
 
@@ -106,9 +106,9 @@ Wallet Instance initialization and registration
 
 * Creates a Key Attestation that is linked with the provided "challenge" and the public key of the Wallet Hardware.
 * Incorporates information pertaining to the device's security.
-* Uses an OEM private key to sign the Key Attestation, therefore verifieable with the related OEM certificate, confirming that the Wallet Hardware Keys are securely managed by the operating system.
+* Uses an OEM private key to sign the Key Attestation, therefore verifieable with the related OEM certificate, confirming that the Cryptographic Hardware Keys are securely managed by the operating system.
 
-**Step 9**: The Wallet Instance sends the ``challenge`` with Key Attestation and Wallet Hardware Key Tag to the Wallet Provider Backend in order to register the Wallet Instance identified with the Wallet Hardware Key public key.
+**Step 9**: The Wallet Instance sends the ``challenge`` with Key Attestation and Cryptographic Hardware Key Tag to the Wallet Provider Backend in order to register the Wallet Instance identified with the Cryptographic Hardware Key public key.
 
 .. note::
 
@@ -141,7 +141,7 @@ Wallet Instance initialization and registration
   1. It MUST verify that the ``challenge`` was generated by Wallet Provider and has not already been used.
   2. It MUST validate the ``key_attestation`` as defined by the device manufacturers' guidelines.
   3. It MUST verify that the device in use has no security flaws and reflects the minimum security requirements defined by the Wallet Provider.
-  4. If these checks are passed, it MUST register the Wallet Instance, keeping the Wallet Hardware Key Tag and all useful information related to the device.
+  4. If these checks are passed, it MUST register the Wallet Instance, keeping the Cryptographic Hardware Key Tag and all useful information related to the device.
   5. It SHOULD associate the Wallet Instance with a specific User uniquely identified within the Wallet Provider's systems. This will be useful for the lifecycle of the Wallet Instance and for a future revocation.
 
 .. code-block:: http
@@ -167,13 +167,13 @@ This section describes the Wallet Attestation format and how the Wallet Provider
 .. figure:: ../../images/wallet_instance_acquisition.svg
    :name: Sequence Diagram for Wallet Attestation acquisition
    :alt: The figure illustrates the sequence diagram for issuing a Wallet Attestation, with the steps explained below.
-   :target: https://www.plantuml.com/plantuml/uml/VLHFJzjE4BtlfnZ1uGTHVfTAxG6f5OXIe5GL0bekID7O7knfd5rtT-oKVlhEEdySXsqFbbZspNjltixaD0XwQHUrmLQSRHSPULDnGV3id6Jkb_clKG3dtA0LOp0Nv-7WMo1_01YW3OhVGS318zOr2LnRPROvzIXi6XYZFbB7EIbAgFGiBt1FlkCD72N0OMWysxBqH3QfSEjTfqOzP9ZFoHPzQPRFZJ7HrVyVLFK4xkXdIq40mT8IN4CUXPq5gL2UhDTRzgIIC9ciUSz4jA17JIQnOUvGAFPWz5lJdbUKpu6VXx8hzCKIFS4DlOJ915X9E-GQivhCJkKbsUWXQbgWfgA57ckOqmiqo5u9Fp_UgB3nrgciwyX7xQbs1eTVhY-l7YxlBYw-cfM3_InKDMO5xbax9FX4nQPXj0MuJ90ji0HOa621WaQJwvNCsgJgH9EYHl8gijkITdE82UlN0uTkm5a2uGN5YTWhZUXry-EBWaQi9XLJBAcPhCoYsrc5eT9mCS3zrTcRj--EjdnJQDgivdpsOpa_JZ6bdqh9RjtjapvrjVxlB71fKLfFUlSUukbety8KbZtLR5kaxpSJBBVAAE44ohNqTipFGY0lx5up7fjOCkJ4cv8PRchKJhAlrtExdVebI_KtiYcaUvwENsdwP9F1mGEMA_2GkpgCH5JqmiDqRuTwcB1xiiK_d8_dRLY5U4olGbp6lT-Uk0riMHXh_ar5lmAT_bsODh0j8TMLODdZqjaCspAimFV8Y9AQ-Z4W_H1fQ5e-ZTHeLrEySttkQNNvEkBnHgOGYTNSEMkPETKSsaNz1m00
+   :target: https://www.plantuml.com/plantuml/uml/VLJ1Jjj04BtlLupWK8ZIIwNsWDGAH2bGgWe1BHSaQsmFzZJEhhixTff-VMTD4YV6pS4IoxvvyzxRcPm6GI_Dl3BOYBFDF2LlIiu9dfsJrFqnRse5SCOrMZ46Ct4U3du4yWU00PgW-2q473nYLP70jLLccr67mhg6NTHdQZaZHGaLdcK9z-HRNiDH0Xo6shCj2azaHplSUjUgK0yfPZEoULUQPZDZJ5JrzfDsFO4x-jrG442mj01NaqTXPq5Ab2VhzPOzQKkOJ5QyPo9QqA4casYOMnIA7en-Azhpah8PyBEMdVjbBQxmM9USmHNwV86Uu8QMOJ81LkuMkSAq8hD5S4asIecjBL1TqboF5Sne2JMoLzwlZpVQttZhXC2rvAE4gHg4ms_NbrSFbtSN5z_DYv1X9DerHWRkMOqIVA5yxHjj3YuLP0ii0UOacAEWqG2xJcObKlj4aQ92iZAosuAsuuX1wzS1UpVWB87mdE9W34eZUcL-zoAd7LOp5bCigPYi955jKc8eDLmCS7zrzkxzXwCDtnJg9gquItujPiVZJ7jUJ3bltUsJFdov-cyIkB0eZIUz-mZnT3HKCeL5bt-oAT9dJ0IBZG2KS0B5Ii5cwCz282_iNZCUcrZInyNhaWJNDIfdrDxhATxim8Ab_1_P5COzJtSVQ_faz-K73rYyrFIle48Z7-LT_txMDoFUpzizsNoFWTtfwnSZ7iSN8sxeu0SfxWPR5iQA_rBUBKIhV-Uc2MmBs6DEiEZWuqdrAzJlnSz8Z39OXH70-BECGyVRZoDZmjrCzzVga5ukNoSzMDDnn61VjyzQPaurXsPU_GC0
 
 **Step 1:**: The User initiates a new operation that necessitates the acquisition of a Wallet Attestation.
 
-**Steps 2-3:**: The Wallet Instance checks if a Wallet Hardware Key exists and generates an ephemeral asymmetric key pair. The Wallet Instance also:
+**Steps 2-3:**: The Wallet Instance checks if a Cryptographic Hardware Key exists and generates an ephemeral asymmetric key pair. The Wallet Instance also:
 
-  1. MUST ensure that Wallet Hardware Keys exist. If they do not exist, it is necessary to reinitialize the Wallet.
+  1. MUST ensure that Cryptographic Hardware Keys exist. If they do not exist, it is necessary to reinitialize the Wallet.
   2. MUST generates an ephemeral asymmetric key pair whose public key will be linked with the Wallet Attestation.
   3. MUST check if Wallet Provider is part of the federation and obtain its metadata.
 
@@ -216,7 +216,7 @@ Below a non-normative example of the ``client_data``.
 
 **Steps 8-10**: The Wallet Instance takes the following steps:
 
-  *  It produces an hardware_signature by signing the ``client_data_hash`` with the Wallet Hardware's private key, serving as a proof of possession for the Wallet Hardware Keys.
+  *  It produces an hardware_signature by signing the ``client_data_hash`` with the Wallet Hardware's private key, serving as a proof of possession for the Cryptographic Hardware Keys.
   *  It requests the Device Integrity Service to create an ``integrity_assertion`` linked to the ``client_data_hash``.
   *  It receives a signed ``integrity_assertion`` from the Device Integrity Service, authenticated by the OEM.
 
@@ -280,15 +280,15 @@ 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:
 
     1. It MUST check the Wallet Attestation Request contains all the defined parameters according to :ref:`Table of the Wallet Attestation Request parameters <table_wallet_attestation_request_claim>`.
     2. It MUST verify that the signature of the received Wallet Attestation Request is valid and associated with public ``jwk``.
     3. It MUST verify that the ``challenge`` was generated by  Wallet Provider and has not already been used.
     4. It MUST check that there is a Wallet Instance registered with that ``hardware_key_tag`` and that it is still valid.
-    5. It MUST reconstruct the ``client_data`` via the ``challenge`` and the ``jwk`` public key, to validate ``hardware_signature`` via the Wallet Hardware Key public key registered and associated with the Wallet Instance.
+    5. It MUST reconstruct the ``client_data`` via the ``challenge`` and the ``jwk`` public key, to validate ``hardware_signature`` via the Cryptographic Hardware Key public key registered and associated with the Wallet Instance.
     6. It MUST validate the ``integrity_assertion`` as defined by the device manufacturers' guidelines.
     7. It MUST verify that the device in use has no security flaws and reflects the minimum security requirements defined by the Wallet Provider.
     8. It MUST check that the URL in ``iss`` parameter is equal to the URL identifier of Wallet Provider.
@@ -407,13 +407,13 @@ The body of the Wallet Attestation Request JWT MUST contain:
       - Challenge data obtained from ``nonce`` endpoint
       -
     * - **hardware_signature**
-      - The signature of ``client_data`` obtained using Wallet Hardware Key base64 encoded.
+      - The signature of ``client_data`` obtained using Cryptographic Hardware Key base64 encoded.
       -
     * - **integrity_assertion**
       - The integrity assertion obtained from the **Device Integrity Service** with the holder binding of ``client_data``.
       -
     * - **hardware_key_tag**
-      - Unique identifier of the **Wallet Hardware Keys**
+      - Unique identifier of the **Cryptographic Hardware Keys**
       -
     * - **cnf**
       - JSON object, containing the public part of an asymmetric key pair owned by the Wallet Instance.

wallet-attestation/en/algorithms.html

@@ -642,7 +642,7 @@ <h2 class='tooltip__title'>{{ item.title }}</h2>
 <li class="toctree-l2"><a class="reference internal" href="wallet-attestation.html#requirements">Requirements</a></li>
 <li class="toctree-l2"><a class="reference internal" href="wallet-attestation.html#static-component-view">Static Component View</a></li>
 <li class="toctree-l2"><a class="reference internal" href="wallet-attestation.html#dynamic-component-view">Dynamic Component View</a><ul>
-<li class="toctree-l3"><a class="reference internal" href="wallet-attestation.html#wallet-instance-initialization-and-registration">Wallet Instance initialization and registration</a></li>
+<li class="toctree-l3"><a class="reference internal" href="wallet-attestation.html#wallet-instance-initialization-and-registration">Wallet Instance Initialization and Registration</a></li>
 <li class="toctree-l3"><a class="reference internal" href="wallet-attestation.html#wallet-attestation-issuance">Wallet Attestation Issuance</a></li>
 <li class="toctree-l3"><a class="reference internal" href="wallet-attestation.html#wallet-attestation-request">Wallet Attestation Request</a></li>
 <li class="toctree-l3"><a class="reference internal" href="wallet-attestation.html#table-wallet-attestation-claim">Wallet Attestation</a></li>
@@ -910,7 +910,7 @@ <h2 class='tooltip__title'>{{ item.title }}</h2>
 <li class="toctree-l2"><a class="reference internal" href="wallet-attestation.html#requirements">Requirements</a></li>
 <li class="toctree-l2"><a class="reference internal" href="wallet-attestation.html#static-component-view">Static Component View</a></li>
 <li class="toctree-l2"><a class="reference internal" href="wallet-attestation.html#dynamic-component-view">Dynamic Component View</a><ul>
-<li class="toctree-l3"><a class="reference internal" href="wallet-attestation.html#wallet-instance-initialization-and-registration">Wallet Instance initialization and registration</a></li>
+<li class="toctree-l3"><a class="reference internal" href="wallet-attestation.html#wallet-instance-initialization-and-registration">Wallet Instance Initialization and Registration</a></li>
 <li class="toctree-l3"><a class="reference internal" href="wallet-attestation.html#wallet-attestation-issuance">Wallet Attestation Issuance</a></li>
 <li class="toctree-l3"><a class="reference internal" href="wallet-attestation.html#wallet-attestation-request">Wallet Attestation Request</a></li>
 <li class="toctree-l3"><a class="reference internal" href="wallet-attestation.html#table-wallet-attestation-claim">Wallet Attestation</a></li>