first draft of the content (#179)

Signed-off-by: Riccardo Iaconelli <[email protected]> Co-authored-by: Riccardo Iaconelli <[email protected]>
italia · Dec 23, 2023 · 85790dc · 85790dc
1 parent 5d8ba19
commit 85790dc
Show file tree

Hide file tree

Showing 6 changed files with 21 additions and 21 deletions.
diff --git a/docs/en/conf.py b/docs/en/conf.py
@@ -281,5 +281,5 @@ def setup(app):
 
 numfig = True
 
-# to turn smartquotes off and be able to use ’ 
+# to turn smartquotes off and be able to use  
 smartquotes = False
diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst
@@ -275,7 +275,7 @@ The corresponding SD-JWT verson for PID is given by
       "jwk": {
         "kty": "RSA",
         "use": "sig",
-        "n": "1Ta-sE …",
+        "n": "1Ta-sE ...",
         "e": "AQAB",
         "kid": "YhNFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs"
       }

diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst
@@ -13,13 +13,13 @@ The relevant entities and interfaces involved in the issuance flow are:
     - *Wallet Instance*: Instance of a Wallet Solution, installed on the User device. It provides interfaces for User interaction with the Wallet Provider, Relying Parties, PID, and (Q)EAA Providers.
     - *PID Provider*: The entity that issues the eIDAS Person Identification Data (PID). It is composed of:
 
-        - OpenID4VCI Component: based on the “OpenID for Verifiable Credential Issuance” specification  `[OIDC4VCI. Draft 13] <https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html>`_ to release PID credentials.
+        - OpenID4VCI Component: based on the "OpenID for Verifiable Credential Issuance" specification  `[OIDC4VCI. Draft 13] <https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html>`_ to release PID credentials.
         - National eID Relying Party (OpenID Connect or SAML2): It represents the component to authenticate the User with the national Digital Identity Providers.
         - National Identity Provider: It represents preexisting identity systems based on SAML2 or OpenID Connect, already in production in each Member State (for Italy SPID and CIE id authentication schemed notified eIDAS with *LoA* **High**, see `SPID/CIE OpenID Connect Specifications <https://italia.github.io/spid-cie-oidc-docs/en/>`_).
 
     - *(Q)EAA Provider*: It represents the Issuer of (Q)EAAs. It is composed of:
 
-      - OpenID4VCI Component: based on the “OpenID for Verifiable Credential Issuance” specification  `[OIDC4VCI. Draft 13] <https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html>`_ to release (Q)EAAs.
+      - OpenID4VCI Component: based on the "OpenID for Verifiable Credential Issuance" specification  `[OIDC4VCI. Draft 13] <https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html>`_ to release (Q)EAAs.
       - Relying Party: It represents the component to authenticate the User with the PID. The (Q)EAA Provider acts as a Verifier and it sends a presentation request to the Wallet Instance according to [`OpenID4VP`_]. The Wallet Instance MUST have a valid PID obtained prior to starting a transaction with the (Q)EAA Provider.
 
 
@@ -916,7 +916,7 @@ Below is a non-normative example of an Entity Configuration containing an `openi
           "keys": [{
             "kty": "RSA",
             "use": "sig",
-            "n": "1Ta-sE …",
+            "n": "1Ta-sE ...",
             "e": "AQAB",
             "kid": "FANFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs"
           }]

diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst
@@ -520,7 +520,7 @@ Below is a non-normative response example:
             "keys": [
                 {
                     "kty": "RSA",
-                    "n": "5s4qi …",
+                    "n": "5s4qi ...",
                     "e": "AQAB",
                     "kid": "2HnoFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs"
                 }
@@ -536,7 +536,7 @@ Below is a non-normative response example:
                         {
                             "kty": "RSA",
                             "use": "sig",
-                            "n": "1Ta-sE …",
+                            "n": "1Ta-sE ...",
                             "e": "AQAB",
                             "kid": "YhNFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs",
                             "x5c": [ "..." ]

diff --git a/docs/en/trust.rst b/docs/en/trust.rst
@@ -80,7 +80,7 @@ OpenID Federation facilitates the building of an infrastructure that is:
 - **Secure and Tamper-proof**, Entities' attestations of metadata and keys are cryptographically signed in the Trust Chain, comprised of attestations issued by multiple parties. These attestations, called statements, cannot be forged or tampered by an adversary;
 - **Privacy-preserving**, the infrastructure is public and exposes public data such as public keys and metadata of the participants. It does not require authentication of the consumers and therefore does not track who is assessing trust against whom;
 - **Guarantor of the non-repudiation of long-lived attestations**, historical keys endpoints and historical Trust Chains are saved for years according to data retention policies. This enables the certification of the validity of historical compliance, even in cases of revocation, expiration, or rotation of the keys used for signature verification;
-- **Dynamic and flexible**, any participants have the freedom to modify parts of their metadata autonomously, as these are published within their domains and verified through the Trust Chain. Simultaneously, the Trust Anchor or its Intermediate may publish a metadata policy to dynamically modify the metadata of all participants — such as disabling a vulnerable signature algorithm — and obtain certainty of propagation within a configured period of time within the federation;
+- **Dynamic and flexible**, any participants have the freedom to modify parts of their metadata autonomously, as these are published within their domains and verified through the Trust Chain. Simultaneously, the Trust Anchor or its Intermediate may publish a metadata policy to dynamically modify the metadata of all participants - such as disabling a vulnerable signature algorithm - and obtain certainty of propagation within a configured period of time within the federation;
 - **Developer friendly**, JWT and JSON formats have been adopted on the web for years. They are cost-effective in terms of storage and processing and have a wide range of solutions available, such as libraries and software development kits, which enable rapid implementation of the solution;
 - **Scalable**, the Trust Model can accommodate more than a single organization by using Intermediates and multiple Trust Anchors where needed.
 
@@ -107,7 +107,7 @@ In the table below is provided the map of the components that the ARF defines wi
 |                                                    |              | Entity         |
 |                                                    |              | Statements     |
 +----------------------------------------------------+--------------+----------------+
-|  Relying Parties’ registration and authentication  | |check-icon| |                |
+|  Relying Parties' registration and authentication  | |check-icon| |                |
 |                                                    |              | Trust Chains   |
 |                                                    |              |                |
 |                                                    |              | Federation     |
@@ -140,7 +140,7 @@ All the endpoints listed below are defined in the `OIDC-FED`_ specs.
 | federation metadata       | **GET** .well-known/openid-federation        |Metadata that an Entity         |  Intermediate   |
 |                           |                                              |publishes about itself,         |                 |
 |                           |                                              |verifiable with a trusted third |  Wallet Provider|
-|                           |                                              |party (Superior Entity). It’s   |                 |
+|                           |                                              |party (Superior Entity). It's   |                 |
 |                           |                                              |called Entity Configuration.    |  Relying Party  |
 |                           |                                              |                                |                 |
 |                           |                                              |                                |  Credential     |
@@ -153,7 +153,7 @@ All the endpoints listed below are defined in the `OIDC-FED`_ specs.
 | fetch endpoint            | **GET** /fetch?sub=https://rp.example.org    |                                |  Trust Anchor   |
 |                           |                                              |Returns a signed document (JWS) |                 |
 |                           |                                              |about a specific subject, its   |  Intermediate   |
-|                           |                                              |Subordinate. It’s called Entity |                 |
+|                           |                                              |Subordinate. It's called Entity |                 |
 |                           |                                              |Statement.                      |                 |
 +---------------------------+----------------------------------------------+--------------------------------+-----------------+
 | trust mark status         | **POST** /status?sub=...&trust_mark_id=...   |                                |  Trust Anchor   |
@@ -200,7 +200,7 @@ Below is a non-normative example of a Trust Anchor Entity Configuration, where e
             "keys": [
                 {
                     "kty": "RSA",
-                    "n": "3i5vV-_ …",
+                    "n": "3i5vV-_ ...",
                     "e": "AQAB",
                     "kid": "FifYx03bnosD8m6gYQIfNHNP9cM_Sam9Tc5nLloIIrc",
                     "x5c": [ <X.509 Root CA certificate> ]
@@ -571,7 +571,7 @@ Below is a non-normative example of a Trust Chain in its original format (JSON A
 
 .. note::
 
-    The entire Trust Chain is verifiable by only possessing the Trust Anchor’s public keys.
+    The entire Trust Chain is verifiable by only possessing the Trust Anchor's public keys.
 
 
 Offline Trust Attestation Mechanisms

diff --git a/docs/en/wallet-solution.rst b/docs/en/wallet-solution.rst
@@ -9,7 +9,7 @@ The Wallet Solution is a comprehensive product offered by the Wallet Provider to
 
 The Wallet Solution is issued by the Wallet Provider in the form of a mobile app, it also consists of services and web interfaces for the exchange of data between the Wallet Provider and its Wallet Instances for the requirements of the trust model and in total respect of the user's privacy, in accordance with national and EU legislation.
 
-The mobile app serves as the primary interface for Users, allowing them to access and interact with their digital assets conveniently. These digital assets, known as Attestations, include Personal Identification Data (PID¹), a set of data that can uniquely identify a natural or a 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¹. Once a User installs the mobile app on their device, it is referred to such an installation as a Wallet Instance for the User.
+The mobile app serves as the primary interface for Users, allowing them to access and interact with their digital assets conveniently. These digital assets, known as Attestations, include Personal Identification Data (PID[1]), a set of data that can uniquely identify a natural or a 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, it is referred to such an installation as a Wallet Instance for the User.
 
 By supporting the mobile app, the Wallet Provider plays a vital role in ensuring the security and reliability of the entire Wallet Solution, since it is responsible for issuing the Wallet Instance Attestation, that is a cryptographic proof that allow the evaluation of the authenticity and the integrity of the Wallet Instance.
 
@@ -28,11 +28,11 @@ The Wallet Instance serves as a unique and secure device for authenticating the
 
 The Wallet Instance establishes the trust within the Wallet ecosystem by consistently presenting a Wallet Instance 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, reference the public part of the asymmetric cryptographic key owned by the Wallet Instance. Their purpose is to authenticate the Wallet Instance itself, ensuring its realiability when engaging with other ecosystem actors.
 
-To guarantee the utmost security, these cryptographic keys are securely stored within the device's Trusted Execution Environment (TEE)³. This ensures that only the User is allowed to access them, thus preventing unauthorized usage or tampering. For more detailed information, please refer to the `Wallet Instance Attestation section`_ and the `Trust Model section`_ of this document.
+To guarantee the utmost security, these cryptographic keys are securely stored within the device's Trusted Execution Environment (TEE)[3]. This ensures that only the User is allowed to access them, thus preventing unauthorized usage or tampering. For more detailed information, please refer to the `Wallet Instance 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².
+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
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -48,8 +48,8 @@ In order to securely and unambiguously identify Users, the Wallet Instance adopt
 
 Once the Wallet Instance is in the Operational state, Users can:
 
- - Obtain, view, and manage (Q)EAAs from trusted (Q)EAA Providers¹;
- - Authenticate to Relying Parties¹;
+ - Obtain, view, and manage (Q)EAAs from trusted (Q)EAA Providers[1];
+ - Authenticate to Relying Parties[1];
  - Authorize the presentation of their digital credentials with Relying Parties.
 
 Please refer to the relative sections for further information about PID and (Q)EAAs issuance and presentation.
@@ -262,11 +262,11 @@ Please refer to the `Wallet Instance Attestation section`_.
 
 External references
 ^^^^^^^^^^^^^^^^^^^^
-¹ Definitions are inherited from the EUDI Wallet Architecture and Reference Framework, version 1.1.0 at the time of writing. Please refer to `this page <https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/9647a408f628569449af6b30a15fed82cd41129a/arf.md#2-definitions>`_ for extended definitions and details.
+.. [1] Definitions are inherited from the EUDI Wallet Architecture and Reference Framework, version 1.1.0 at the time of writing. Please refer to `this page <https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/9647a408f628569449af6b30a15fed82cd41129a/arf.md#2-definitions>`_ for extended definitions and details.
 
-² Wallet Instance states adhere to the EUDI Wallet Architecture and Reference Framework, as defined `here <https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/9647a408f628569449af6b30a15fed82cd41129a/arf.md#424-eudi-wallet-instance-lifecycle>`_.
+.. [2] Wallet Instance states adhere to the EUDI Wallet Architecture and Reference Framework, as defined `here <https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/9647a408f628569449af6b30a15fed82cd41129a/arf.md#424-eudi-wallet-instance-lifecycle>`_.
 
-³ Depending on the device operating system, TEE is defined by `Trusty`_ or `Secure Enclave`_ for Android and iOS devices, respectively.
+.. [3] Depending on the device operating system, TEE is defined by `Trusty`_ or `Secure Enclave`_ for Android and iOS devices, respectively.
 
 .. _Trust Model section: trust.html
 .. _Wallet Instance Attestation section: wallet-instance-attestation.html