Merge branch 'versione-corrente' into QEAA-issuance

italia · Jul 24, 2023 · cd718d1 · cd718d1
2 parents 985262c + 146977d
commit cd718d1
Show file tree

Hide file tree

Showing 10 changed files with 345 additions and 358 deletions.
diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml
@@ -67,11 +67,11 @@ jobs:
           echo '
           <html>
           <head>
-            <title>Italian eIDAS Wallet Technical Specifications</title>
+            <title>EUDI Wallet docs</title>
             <meta name="viewport" content="initial-scale=1.0">
           </head>
           <body>
-          <h1>Italian eIDAS Wallet Technical Specifications</h1>
+          <h1>EUDI Wallet docs</h1>
 
           <ul>
             <li><a href="it/">Italian version</a></li>

diff --git a/docs/common/common_definitions.rst b/docs/common/common_definitions.rst
@@ -57,5 +57,6 @@
 .. _DPOP: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
 .. _RFC 7519: https://www.rfc-editor.org/rfc/rfc7519
 .. _OAUTH2: https://www.rfc-editor.org/rfc/rfc6749
+.. _OPENID4VC-HAIP: https://vcstuff.github.io/oid4vc-haip-sd-jwt-vc/draft-oid4vc-haip-sd-jwt-vc.html
 
 
diff --git a/docs/common/standards.rst b/docs/common/standards.rst
@@ -54,4 +54,6 @@ Technical References
     * - :rfc:`6749`
       - The OAuth 2.0 Authorization Framework
     * - `DPOP`
-      - TBD
+      - D. Fett, B. Campbell, J. Bradley, T. Lodderstedt, M. Jones, D. Waite, "OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP)"
+    * - `OPENID4VC-HAIP`
+      - Lodderstedt, T., K. Yasuda, "OpenID4VC High Assurance Interoperability Profile with SD-JWT VC"
diff --git a/docs/en/defined-terms.rst b/docs/en/defined-terms.rst
@@ -2,6 +2,13 @@
 
 .. _defined-terms.rst:
 
+
+Normative Language and Conventions
+++++++++++++++++++++++++++++++++++
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
+
+
 Defined Terms
 +++++++++++++
 

diff --git a/docs/en/index.rst b/docs/en/index.rst
@@ -60,7 +60,7 @@ Index of content
 ----------------
 
 .. toctree:: 
-   :maxdepth: 2
+   :maxdepth: 3
 
    ssi-introduction.rst
    defined-terms.rst

diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst
@@ -50,6 +50,7 @@ The Disclosures are sent to the Holder together with the SD-JWT in the *Combined
 
 See `[draft-terbu-sd-jwt-vc-latest] <https://vcstuff.github.io/draft-terbu-sd-jwt-vc/draft-terbu-oauth-sd-jwt-vc.html>`_ and `[SD-JWT] <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-selective-disclosure-jwt-04>`__ for more details. 
 
+
 PID/(Q)EAA SD-JWT parameters
 ----------------------------
 
@@ -174,7 +175,6 @@ PID Claims field
 
 The ``claims`` parameter contains the User attributes with the following mandatory fields:
 
-
 .. list-table:: 
     :widths: 20 60 20
     :header-rows: 1

diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst
@@ -10,8 +10,8 @@ Relying Party Solution
 
 This section describes how a Relying Party may ask to a Wallet Instance the presentation of the PID and the (Q)EAAs, according the following specifications: 
 
-- `OpenID for Verifiable Presentations - draft 19 <OID4VP>`_.
-- `Draft: OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) <DPOP>`_.
+- `OpenID for Verifiable Presentations - draft 19 <https://openid.net/specs/openid-4-verifiable-presentations-1_0.html>`_.
+- `Draft: OAuth 2.0 Demonstrating Proof-of-Possession at the Application Layer (DPoP) <https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop>`_.
 
 
 In this section the following flows are described:
@@ -340,10 +340,10 @@ Here a non-normative example of ``presentation_definition``:
 
   {
     "presentation_definition": {
-      "id": "pid-sd-jwt:unique_id+given_name+family_name",
+      "id": "presentation definitions",
       "input_descriptors": [
         {
-          "id": "eu.europa.ec.eudiw.pid.it.1",
+          "id": "pid-sd-jwt:unique_id+given_name+family_name",
           "name": "Person Identification Data",
           "purpose": "User authentication",
           "format": "vc+sd-jwt",
@@ -384,8 +384,7 @@ After getting the User authorization and consent for the presentation of the cre
 .. note::
     **Why the response is encrypted?**
 
-    The response sent from the Wallet Instance to the Relying Party is encrypted
-    to prevent a technique called `SSL split attack <https://pdos.csail.mit.edu/papers/ssl-splitting-usenixsecurity03/>`_, that could be enabled by malicious app installed locally by Users,that intecepts the network traffic, or be present by-design in network environments where a next-generation firewalls or other security devices may reduce the privacy of the Users.
+    The response sent from the Wallet Instance to the Relying Party is encrypted to prevent a malicious agent from gaining access to the plaintext information transmitted within the verifier's network. This is only possible if the network environment of the verifier employs `TLS termination <https://www.f5.com/glossary/ssl-termination>`_. Such technique employs a termination proxy that acts as an intermediary between the client and the webserver and handles all TLS-related operations. In this manner, the proxy deciphers the transmission's content and either forwards it in plaintext or by negotiates an internal TLS session with the actual webserver's intended target. In the first scenario, any malicious actor within the network segment could intercept the transmitted data and obtain sensitive information, such as an unencrypted response, by sniffing the transmitted data.
 
 Below a non-normative example of the request:
 
@@ -410,14 +409,9 @@ Below is a non-normative example of the decrypted JSON ``response`` content:
         "id": "04a98be3-7fb0-4cf5-af9a-31579c8b0e7d",
         "descriptor_map": [
             {
-                "id": "eu.europa.ec.eudiw.pid.it.1:unique_id",
+                "id": "pid-sd-jwt:unique_id+given_name+family_name",
                 "path": "$.vp_token.verified_claims.claims._sd[0]",
                 "format": "vc+sd-jwt"
-            },
-            {
-                "id": "eu.europa.ec.eudiw.pid.it.1:given_name",
-                "path": "$.vp_token.verified_claims.claims._sd[1]",
-                "format": "vc+sd-jwt"
             }
         ]
     }

diff --git a/docs/en/trust.rst b/docs/en/trust.rst
@@ -254,7 +254,10 @@ Below is a non-normative example of a Trust Anchor Entity Configuration, where e
 Entity Configuration
 --------------------
 
-The Entity Configuration is the verifiable document that each Federation Entity must publish on its own behalf.
+The Entity Configuration is the verifiable document that each Federation Entity must publish on its own behalf in the web path **.well-known/openid-federation**.
+
+The Entity Configuration HTTP response MUST set the media type `application/entity-statement+jwt`.
+
 The Entity Configuration must be cryptographically signed. The public part of this key must be present in the
 Entity Configuration and within the Entity Statement issued by a immediate superior concerning the Federation Entity.