Deploy to GitHub pages

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

@@ -122,10 +122,10 @@ Below are the description of acronyms and definitions which are useful for furth
      - The application installed and configured on a Wallet User’s device or environment, which is part of a Wallet Unit, and that the Wallet User uses to interact with the Wallet Unit.
      -
    * - Wallet Unit
-     - Unique configuration of a wallet solution that includes wallet instances, wallet secure cryptographic applications, and wallet secure cryptographic devices provided by a wallet provider to an individual wallet user.
+     - Unique configuration of a Wallet Solution that includes Wallet instances, Wallet Secure Cryptographic Applications, and Wallet Secure Cryptographic Devices provided by a Wallet Provider to an individual Wallet User.
      -
    * - Wallet Unit Attestation
-     - Also known as Wallet Attestation or Wallet Instance Attestation, it is a Data object issued by a Wallet Provider that describes the components of the Wallet Unit. It allows authentication and validation of those components, and is cryptographically bound to Wallet Secure Cryptographic Devices.
+     - Also known as Wallet Attestation or Wallet Instance Attestation, it is a data object issued by a Wallet Provider that describes the components of the Wallet Unit. It allows authentication and validation of those components, and is cryptographically bound to Wallet Secure Cryptographic Devices.
      -
    * - Wallet Secure Cryptographic Device (WSCD)
      - 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

refs/pull/414/merge/en/_sources/remote-flow.rst.txt

@@ -460,7 +460,7 @@ by appending the ``KB-JWT`` at the end of the of the SD-JWT, as represented in t
 
 To validate the signature on the Key Binding JWT, the Verifier MUST use the key material included in the Issuer-Signed-JWT.
 The Key Binding JWT MUST specify which key material the Verifier needs to use to validate the Key Binding JWT signature,
-using JOSE header parameter ``kid``.
+using the ``cnf`` parameter contained in the Issuer-Signed-JWT.
 
 When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in the JWS header:
 
@@ -474,8 +474,6 @@ When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in
     - REQUIRED. MUST be ``kb+jwt``, which explicitly types the Key Binding JWT as recommended in Section 3.11 of [RFC8725].
   * - **alg**
     - REQUIRED. Signature Algorithm using one of the specified in the section Cryptographic Algorithms. 
-  * - **kid**
-    - REQUIRED. Unique identifier of the public key to be used to verify the signature.
 
 
 When an SD-JWT is presented, its KB-JWT MUST contain the following parameters in the JWS payload:

refs/pull/414/merge/en/_sources/ssi-introduction.rst.txt

@@ -5,7 +5,7 @@
 The Digital Identity Wallet Paradigm
 ++++++++++++++++++++++++++++++++++++
 
-The Digital Identity Wallet Paradigm refers to a new architecture in Identity and Access Management (IAM) that improves the privacy and grants complete control and ownership over the personal data by their owner, the Users.
+The Digital Identity Wallet paradigm refers to a new architecture in Identity and Access Management (IAM) that improves the privacy and grants complete control and ownership over the personal data by their owner, the users.
 Users possess their digital documents and determine to which actors they present these documents, with the ability to revoke the use of said documents, all while maintaining a history of their activities. 
 
 The main difference between this new approach and the traditional IAM infrastructure is that during the presentation phase there are no intermediaries between the Wallet and the Relying Party, while in the SAML2 or OIDC based infrastructure an Identity Provider is always involved, knowing which services a citizen is accessing to.
@@ -19,7 +19,7 @@ The main roles in an Wallet ecosystem are are listed as follow:
  - Holders: individuals who own a Wallet and have control over the digital credentials they can request, acquire, store, and present to verifiers;
  - Verifiable Data Registries: Authorities that publish certificates, attestations, metadata, and schemes needed for allowing the trust establishment between the parties.
 
-In this model, the credential Issuer (e.g., an educational institution) provides digital credentials to the User, who can store them in their digital Wallet.
+In this model, the credential issuer (e.g., an educational institution) provides digital credentials to the user, who can store them in their digital Wallet.
 The Wallet typically comes in the form of an application on the User's mobile phone.
 
 Other key elements that characterize an SSI system include:

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

@@ -5,13 +5,16 @@
 Wallet Attestation
 ++++++++++++++++++
 
-Wallet Attestation contains information regarding the security level of the device hosting the Wallet Instance. It primarily certifies the **authenticity**, **integrity**, **security**, **privacy**, and **trustworthiness** of a particular Wallet Instance. The Wallet Attestation MUST contain a Wallet Instance public key.
+Wallet Attestation contains information regarding the security level of the device hosting the Wallet Instance.
+It primarily certifies the **authenticity**, **integrity**, **security**, **privacy**, and **trustworthiness** of a particular Wallet Instance.
+
 
 Requirements
 ------------
 
 The requirements for the Wallet Attestation are defined below:
 
+- The Wallet Attestation MUST contain a Wallet Instance public key.
 - The Wallet Attestation MUST use the signed JSON Web Token (JWT) format;
 - The Wallet Attestation MUST provide all the relevant information to attest to the **integrity** and **security** of the device where the Wallet Instance is installed.
 - The Wallet Attestation MUST be signed by the Wallet Provider that has authority over and is the owner of the Wallet Solution, as specified by the overseeing registration authority. This ensures that the Wallet Attestation uniquely links the Wallet Provider to this particular Wallet Instance.
@@ -32,7 +35,7 @@ The requirements for the Wallet Attestation are defined below:
   - **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.
 
-- The Wallet Provider MUST offer a set of services, exclusively available to its Wallet Solution instances, for the verification and issuance of Wallet Attestations.
+- The Wallet Provider MUST offer a set of services, exclusively available to its Wallet Solution instances, for the issuance of Wallet Attestations.
 
 .. warning::
   At the current stage, the 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`.

refs/pull/414/merge/en/_sources/wallet-solution.rst.txt

@@ -5,35 +5,50 @@
 Wallet Solution
 -------------------
 
-The Wallet Solution is a comprehensive product offered by the Wallet Provider to cater to the needs of Users in managing their digital assets securely. It is issued by the Wallet Provider in the form of a mobile app and consists of services and web interfaces for the exchange of data between the Wallet Provider and its Wallet Instances to meet the requirements of the trust model and ensure full respect for the User's privacy, in accordance with national and EU legislation.
+The Wallet Solution is issued by the Wallet Provider in the form of a mobile app and services, such as web interfaces.
 
-The mobile app serves as the primary interface for Users, allowing them to access and interact with their digital Credentials conveniently. These Credentials are a set of data that can uniquely identify a natural or legal person, along with other Qualified and non-qualified Electronic Attestations of Attributes, also known as QEAAs and EAAs respectively, or (Q)EAAs for short[1]. Once a User installs the mobile app on their device, such an installation is referred to as a Wallet Instance for the User.
+The mobile app serves as the primary interface for Users,
+allowing them to hold their Digital Credentials and interact with other participants of the ecosystem,
+such as Credential Issuers and Relying Parties.
 
-By supporting the mobile app, the Wallet Provider plays a vital role in ensuring the security and reliability of the entire Wallet Solution, as it is responsible for issuing the Wallet Attestation, which is a cryptographic proof that allows the evaluation of the authenticity and integrity of the Wallet Instance.
+These Credentials are a set of data that can uniquely identify a natural or legal person,
+along with other Qualified and non-qualified Electronic Attestations of Attributes,
+also known as QEAAs and EAAs respectively, or (Q)EAAs for short[1]. 
 
-The Wallet Provider MUST offer a RESTful set of services for issuing the Wallet Attestations.
+Once a User installs the mobile app on their device, such an installation is referred to as a Wallet Instance for the User.
+
+By supporting the mobile app, the Wallet Provider enusers the security and reliability of the entire Wallet Solution,
+as it is responsible for issuing the Wallet Attestation,
+which is a cryptographic proof about the authenticity and integrity of the Wallet Instance.
 
 Requirements
 ^^^^^^^^^^^^
 
-This section lists the essential requirements that must be met by the Wallet Solution to ensure its functionality, security, and compliance with relevant standards and regulations.
+This section lists the requirements that are be met by Wallet Providers and Wallet Solutions.
 
- - **Trustworthiness within the Wallet ecosystem**: the Wallet Instance MUST establish trust and reliability within the Wallet ecosystem.
- - **Compliance with Provider specifications for obtaining PID and (Q)EAA**: the Wallet Instance MUST adhere to the specifications set by Providers for obtaining Personal Identification (PID) and (Q)EAAs.
- - **Support for Android and iOS operating systems**: the Wallet Instance MUST be compatible and functional on both Android and iOS operating systems and available on the Play Store and App Store, respectively.
- - **Verification of device ownership by the User**: the Wallet Instance MUST provide a mechanism to verify the User's actual possession and full control of their personal device.
+ - The Wallet Provider MUST offer a RESTful set of services for issuing the Wallet Attestations.
+ - The Wallet Instance MUST periodically reestablish trust with its Wallet Provider.
+ - The Wallet Instance MUST establish trust with other participants of the Wallet ecosystem, such as Credential Issers and Relying Parties.
+ - The Wallet Solutions MUST adhere to the specifications set by this document for obtaining Personal Identification (PID) and (Q)EAAs.
+ - The Wallet Instance MUST be compatible and functional on both Android and iOS operating systems and available on the Play Store and App Store, respectively.
+ - The Wallet Instance MUST provide a mechanism to verify the User's actual possession and full control of their personal device.
 
 Wallet Instance
 ^^^^^^^^^^^^^^^
-The Wallet Instance serves as a unique and secure device for authenticating the User within the Wallet ecosystem. It establishes a strong and reliable mechanism for the User to engage in various digital transactions in a secure and privacy-preserving manner.
+The Wallet Instance serves as a unique and secure device for authenticating the User within the Wallet ecosystem.
+It establishes a strong and reliable mechanism for the User to engage in various digital transactions in a secure and privacy-preserving manner.
 
-The Wallet Instance establishes trust within the Wallet ecosystem by consistently presenting a Wallet Attestation during interactions with other ecosystem actors such as PID Providers, (Q)EAA Providers, and Relying Parties. These verifiable attestations, provided by the Wallet Provider, serve to authenticate the Wallet Instance itself, ensuring its reliability when engaging with other ecosystem actors.
+The Wallet Instance allows other entities within the ecosystem to establish trust with it, by consistently
+presenting a Wallet Attestation during interactions with PID Providers,
+(Q)EAA Providers, and Relying Parties. These verifiable attestations, provided by the Wallet Provider,
+serve to authenticate the Wallet Instance itself, ensuring its reliability when engaging with other ecosystem actors.
 
 To guarantee the utmost security, these cryptographic keys MUST be securely stored within the WSCD, which MAY be internal (device's Trusted Execution Environment (TEE)[3]), external, or hybrid. This ensures that only the User can access them, thus preventing unauthorized usage or tampering. For more detailed information, please refer to the `Wallet Attestation section`_ and the `Trust Model section`_ of this document.
 
 Wallet Instance Lifecycle
 ^^^^^^^^^^^^^^^^^^^^^^^^^
-The Wallet Instance has three distinct states: Operational, Valid, and Deactivated. Each state represents a specific functional status and determines the actions that can be performed[2].
+The Wallet Instance has three distinct states: Operational, Valid, and Deactivated.
+Each state represents a specific functional status and determines the actions that can be performed[2].
 
 Initialization Process
 ~~~~~~~~~~~~~~~~~~~~~~

refs/pull/414/merge/en/algorithms.html

@@ -359,7 +359,7 @@ <h3 id="searchlabel">Quick search</h3>
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>
 

refs/pull/414/merge/en/authentic-sources.html

@@ -244,7 +244,7 @@ <h2>Security Patterns<a class="headerlink" href="#security-patterns" title="Link
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>
 

refs/pull/414/merge/en/backup-restore.html

@@ -258,7 +258,7 @@ <h2>External references<a class="headerlink" href="#external-references" title="
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>
 

refs/pull/414/merge/en/contribute.html

@@ -261,7 +261,7 @@ <h2>Acknowledgements<a class="headerlink" href="#acknowledgements" title="Link t
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>
 

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

@@ -305,11 +305,11 @@ <h1>Defined Terms<a class="headerlink" href="#defined-terms" title="Link to this
 <td></td>
 </tr>
 <tr class="row-odd"><td><p>Wallet Unit</p></td>
-<td><p>Unique configuration of a wallet solution that includes wallet instances, wallet secure cryptographic applications, and wallet secure cryptographic devices provided by a wallet provider to an individual wallet user.</p></td>
+<td><p>Unique configuration of a Wallet Solution that includes Wallet instances, Wallet Secure Cryptographic Applications, and Wallet Secure Cryptographic Devices provided by a Wallet Provider to an individual Wallet User.</p></td>
 <td></td>
 </tr>
 <tr class="row-even"><td><p>Wallet Unit Attestation</p></td>
-<td><p>Also known as Wallet Attestation or Wallet Instance Attestation, it is a Data object issued by a Wallet Provider that describes the components of the Wallet Unit. It allows authentication and validation of those components, and is cryptographically bound to Wallet Secure Cryptographic Devices.</p></td>
+<td><p>Also known as Wallet Attestation or Wallet Instance Attestation, it is a data object issued by a Wallet Provider that describes the components of the Wallet Unit. It allows authentication and validation of those components, and is cryptographically bound to Wallet Secure Cryptographic Devices.</p></td>
 <td></td>
 </tr>
 <tr class="row-odd"><td><p>Wallet Secure Cryptographic Device (WSCD)</p></td>
@@ -482,7 +482,7 @@ <h2>Acronyms<a class="headerlink" href="#acronyms" title="Link to this heading">
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>
 

refs/pull/414/merge/en/genindex.html

@@ -283,7 +283,7 @@ <h2 id="R">R</h2>
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>
 

refs/pull/414/merge/en/index.html

@@ -448,7 +448,7 @@ <h2>Index of content<a class="headerlink" href="#index-of-content" title="Link t
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>
 

refs/pull/414/merge/en/pid-eaa-data-model.html

@@ -1465,7 +1465,7 @@ <h3>MDOC-CBOR Examples<a class="headerlink" href="#mdoc-cbor-examples" title="Li
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>
 

refs/pull/414/merge/en/pid-eaa-entity-configuration.html

@@ -1012,7 +1012,7 @@ <h2>Example of a (Q)EAA Provider Entity Configuration<a class="headerlink" href=
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>
 

refs/pull/414/merge/en/pid-eaa-issuance.html

@@ -1520,7 +1520,7 @@ <h3>Notification Response<a class="headerlink" href="#notification-response" tit
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>
 

refs/pull/414/merge/en/proximity-flow.html

@@ -622,7 +622,7 @@ <h2>Session Termination<a class="headerlink" href="#session-termination" title="
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>
 

refs/pull/414/merge/en/pseudonyms.html

@@ -251,7 +251,7 @@ <h2>Implementation Considerations<a class="headerlink" href="#implementation-con
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>
 

refs/pull/414/merge/en/relying-party-entity-configuration.html

@@ -438,7 +438,7 @@ <h2>Example of a Relying Party Entity Configuration<a class="headerlink" href="#
 
 
     <div class="footer" role="contentinfo">
-      Last updated on 16/09/2024.
+      Last updated on 18/09/2024.
       Created using <a href="https://www.sphinx-doc.org/">Sphinx</a> 7.4.5.
     </div>