Merge pull request #123 from italia/0.5.0

0.5.0

.github/workflows/ci-html.yml

@@ -15,8 +15,24 @@ on:
 
 # A workflow run is made up of one or more jobs that can run sequentially or in parallel
 jobs:
+
+  pre_job:
+    runs-on: ubuntu-latest
+    outputs:
+      should_skip: ${{ steps.skip_check.outputs.should_skip }}
+    steps:
+      - id: skip_check
+        uses: fkirc/[email protected]
+        with:
+          skip_after_successful_duplicate: 'true'
+          same_content_newer: 'true'
+
   # This workflow contains a single job called "build"
-  build:
+  main_job:
+
+    needs: pre_job
+    if: needs.pre_job.outputs.should_skip != 'true'
+
     # The type of runner that the job will run on
     runs-on: ubuntu-latest
 

.gitignore

@@ -16,4 +16,17 @@ env
 build
 env-preview
 .venv
-.vscode
+.vscode
+*.py
+*.cfg
+*.tmpl
+*.exe
+*.csh
+*.fish
+*.ps1
+*.9
+v_env/bin/python3
+v_env/bin/python
+v_env/bin/pip3
+v_env/bin/pip
+v_env/bin/activate

docs/common/common_definitions.rst

@@ -45,7 +45,6 @@
 .. _JWE: https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-encryption
 .. _JWK: https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-key
 .. _JWS: https://datatracker.ietf.org/doc/html/draft-ietf-jose-json-web-signature
-.. _OAuth-DPoP: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop-10
 .. _EIDAS-ARF: https://github.com/eu-digital-identity-wallet/architecture-and-reference-framework
 .. _OpenID4VCI: https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html
 .. _SD-JWT: https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-02.html
@@ -54,7 +53,7 @@
 .. _SD-JWT-VC: https://www.ietf.org/id/draft-terbu-sd-jwt-vc-02.html
 .. _PresentationExch: https://identity.foundation/presentation-exchange/spec/v2.0.0
 .. _JARM: https://openid.net/specs/oauth-v2-jarm-final.html
-.. _DPOP: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-dpop
+.. _RFC 9449: 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

docs/common/standards.rst

@@ -10,12 +10,12 @@ Technical References
     * - `OIDC-FED`_
       - OpenID Connect Federation 1.0
     * - `OPENID4VCI`_
-      - T. Lodderstedt, K. Yasuda, T. Looker, "OpenID for Verifiable Credential Issuance", February 2023.
+      - T\. Lodderstedt, K. Yasuda, T. Looker, "OpenID for Verifiable Credential Issuance", February 2023.
     * - `SD-JWT-VC`_
-      - O. Terbu, D.Fett, "SD-JWT-based Verifiable Credentials (SD-JWT VC)".
+      - O\. Terbu, D.Fett, "SD-JWT-based Verifiable Credentials (SD-JWT VC)".
     * - `EIDAS-ARF`_
       - EUDI Wallet - Architecture and Reference Framework
-    * - `OpenID4VP`_
+    * - `OPENID4VP`_
       - OpenID for Verifiable Presentations - draft 19 
     * - `PresentationExch`_
       - Presentation Exchange 2.0 for Presentation Definition
@@ -53,7 +53,7 @@ Technical References
       - Lodderstedt, T., Campbell, B., "JWT Secured Authorization Response Mode for OAuth 2.0 (JARM)", November 2022.
     * - :rfc:`6749`
       - The OAuth 2.0 Authorization Framework
-    * - `DPOP`
-      - 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`
+    * - :rfc:`9449`
+      - 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"

docs/en/conf.py

@@ -2,7 +2,7 @@
 # -*- coding: utf-8 -*-
 
 # -- PROJECT Variables ----------------------------------------------------
-settings_project_name = "Italian eIDAS Wallet Technical Specifications"
+settings_project_name = "The Italian EUDI Wallet implementation profile"
 settings_copyright_copyleft = 'Dipartimento per la Trasformazione Digitale'
 settings_editor_name = 'Dipartimento per la Trasformazione Digitale'
 settings_doc_version = 'version: latest'

docs/en/contribute.rst

@@ -14,3 +14,45 @@ Below are several methods available for contributing to this project:
 - **GitHub issues**. By opening an issue, you can seek clarification, propose enhancements, or report editorial typos. If you are working on an issue, we encourage you to open a draft pull request and link it.
 - **Pull requests**. Pull requests represent active contributions to the project, typically, but not always following issue-based discussions. Once a pull request is initiated, it facilitates discussion and review of the proposed changes before they are merged into the main branch (`versione-corrente`).
 - **Developers Italia Slack channel**. Slack is a messaging application designed for businesses, connecting people to the information they need. *Developers Italia* is an open community based on contributions and participation from public administrations, developers, technicians, students, and citizens. *Developers Italia* has initiated a Slack channel that [everyone can join for free](https://slack.developers.italia.it/), where you can learn about all their activities and partake in discussions.
+
+
+Acknowledgements
+----------------
+
+We would like to thank the following individuals for their comments, 
+concerns, ideas, contributions, some of which substantial, to this 
+implementation profile and to the initial set of implementations.
+
+- Alen Horvat
+- Amir Sharif
+- Andrea Prosseda
+- Emanuele De Cupis
+- Emiliano Vernini
+- Francesco Grauso
+- Francesco Marino
+- Francesco Ventola
+- Giada Sciarretta
+- Giuseppe De Marco
+- Kristina Yasuda
+- Leif Johansson
+- Lorenzo Cerini
+- Marta Sciunnach
+- Michele Silletti
+- Nicola Saitto
+- Paul Bastien
+- Pasquale De Rose
+- Peter Altmann
+- Riccardo Iaconelli
+- Roland Hedberg
+- Salvatore Laiso
+- Salvatore Manfredi
+- Stefano Alifuoco
+- Takahiko Kawasaki
+- Torsten Lodderstedt
+- Vladimir Duzhinov
+
+If anyone has been forgotten, please accept our apologies with the 
+request to propose the modification of this page via a [Pull Request](https://github.com/italia/eudi-wallet-it-docs) 
+with a brief description of the contribution offered, during which 
+event or channel, and during which period. We will then have the opportunity 
+to apologize again and make amends as soon as possible, including you in the list.

docs/en/defined-terms.rst

@@ -51,6 +51,8 @@ Below are the description of acronyms and definitions which are useful for furth
      - An architectural component that enables IT Wallet system participants to establish trust, in terms of reliability and compliance of all participants with the regulatory framework governing the digital identity system.
    * - Level of Assurance
      - The degree of confidence in the vetting process used to establish the identity of the User and the degree of confidence that the User who presents the credential is the same User to whom the credential was issued.
+   * - Holder Key Binding
+     - Ability of the Holder to prove legitimate possession of the private part, related to the public part attested by a Trusted Third Party.
 
 Acronyms
 --------

docs/en/index.rst

@@ -1,33 +1,33 @@
 .. include:: ../common/common_definitions.rst
 
-=============================================
-Italian EUDI Wallet Technical Specifications
-=============================================
+==============================================
+The Italian EUDI Wallet implementation profile
+==============================================
 
 Introduction
 ------------
 
-Across Europe, 21 digital identities (eIDs) currently exist in 16 different Member States.
-In its integration effort, the European Council called for the eIDAS Regulation on electronic identification and trust services for electronic transactions in the internal market to be updated by implementing a new tool: the European Digital Identity Wallet.
-The European Digital Identity Wallet (EUDI Wallet or EUDIW) project was created to overcome the differences, both in technological and user experience terms, that exist across national experiences towards a uniform digital identity solution so as to enable cross-border access to digital services. 
+The European Council requested the update of the 
+eIDAS Regulation on electronic identification and trust services by 
+implementing a new tool: the `European Digital Identity Wallet <https://commission.europa.eu/strategy-and-policy/priorities-2019-2024/europe-fit-digital-age/european-digital-identity_en>`_.
 
 Italy responded to the input received from the European community by creating the National digital identity Wallet solution, called IT Wallet, to be fully interoperable with all the other solutions made available by other European Member States and in full compliance to the European regulation.
-The current Italian scenario counts 3 coexisting digital identity tools that are partially overlapping, sometimes competing, and based on different technologies. This points to a highly fragmented system which yields difficulties for users and service providers and is ultimately unsustainable.
-Therefore, the IT Wallet proposes to rationalise the digital identity ecosystem in Italy in order to simplify the experience of citizens, public administrations, and businesses in accessing digital services.
+
+The current Italian scenario counts 3 coexisting digital identity tools that are partially overlapping, sometimes competing, and based on different technologies. This points to a highly fragmented system which yields difficulties for users and service providers. Therefore, the IT Wallet proposes to rationalise the digital identity ecosystem in Italy in order to simplify the experience of citizens, public administrations, and businesses in accessing digital services.
 
 To achieve these objectives and enhance the already active and eIDAS-notified digital identity schemes, the IT Wallet project entails a technological and governance evolution that envisages the progressive migration of the current threefold digital identification solution towards IT Wallet.
 
 The purpose of the following technical rules is to define the technical architecture and reference framework to be used as a guideline by all the parties involved in the development of the IT Wallet project.
 
-In this documentation you can find the technical specification for implementing the components that compose the Wallet ecosystem:
+This documentation defines the national implementation profile of EUDI Wallet, containing the technical details about components of the Wallet ecosystem, as listed below:
 
  - Entities of the ecosystem according to `EIDAS-ARF`_.
  - Infrastructure of trust attesting realiability and eligibility of the participants.
  - PID and EAAs data schemes and attribute sets.
  - PID/EAA in MDL CBOR format.
  - PID/EAA in `SD-JWT`_ format.
  - Wallet Solution general architecture.
- - Wallet Instance Attestation data model in `JWS`_ format.
+ - Wallet Instance Attestation.
  - Issuance of PID/EAA according to `OpenID4VCI`_.
  - Presentation of PID/EAA according to `OpenID4VP`_.
  - Presentation of pseudonyms according to `SIOPv2`_.

docs/en/pid-eaa-data-model.rst

@@ -7,8 +7,7 @@ PID/(Q)EAA Data Model
 +++++++++++++++++++++
 
 The Person Identification Data (PID) is issued by the PID Provider following national laws and allows a natural person to be authenitcated and identified. 
-
-The User attributes carried in the Italian PID are:
+The User attributes carried within the Italian PID are the ones listed below:
 
     - Current Family Name
     - Current First Name
@@ -23,7 +22,7 @@ The (Q)EAAs are issued by (Q)EAA Issuers to a Wallet Instance and MUST be provid
 
 The (Q)EAAs are extended according to the `OpenID Identity Assurance Profile [OIDC.IDA] <https://openid.net/specs/openid-connect-4-identity-assurance-1_0-13.html>`_, that allows the recipients to know the Authentic Sources where the data comes from. 
 
-The PID/(Q)EAA data format and the mechanism through which a digital credential is issued to the Wallet Instance and presented to an RP is described in the following sections. 
+The PID/(Q)EAA data format and the mechanism through which a digital credential is issued to the Wallet Instance and presented to a Relying Party are described in the following sections. 
 
 SD-JWT
 ======
@@ -91,7 +90,7 @@ The following claims MUST be in the JWT payload and MUST NOT be included in the
       - URL string representing the PID/(Q)EAA Issuer unique identifier.
       - `[RFC7519, Section 4.1.1] <https://www.iana.org/go/rfc7519>`_.
     * - **sub**
-      - Thumbprint of the JWK in the ``cnf`` parameter
+      - Thumbprint of the JWK in the ``cnf`` parameter.
       - `[RFC7519, Section 4.1.2] <https://www.iana.org/go/rfc7519>`_.
     * - **jti**
       - Unique Token ID identifier of this JWT. It SHOULD be a String in *uuid4* format.
@@ -103,10 +102,10 @@ The following claims MUST be in the JWT payload and MUST NOT be included in the
       - UNIX Timestamp with the expiry time of the JWT, coded as NumericDate as indicated in :rfc:`7519`.
       - `[RFC7519, Section 4.1.4] <https://www.iana.org/go/rfc7519>`_.
     * - **status**
-      - HTTPS URL where the credential validity status is available
+      - HTTPS URL where the credential validity status is available.
       - `[SD-JWT-VC. Section 4.2.2.2] <https://vcstuff.github.io/draft-terbu-sd-jwt-vc/draft-terbu-sd-jwt-vc.html#section-4.2.2.2>`_.
     * - **cnf**
-      - JSON object containing the proof-of-possession key materials. By including a **cnf** (confirmation) claim in a JWT, the issuer of the JWT declares that the presenter is in control of the private key related to the public one defined in the **cnf** parameter. The recipient MUST cryptographically verify that the presenter is in control of that key. 
+      - JSON object containing the proof-of-possession key materials. By including a **cnf** (confirmation) claim in a JWT, the issuer of the JWT declares that the Holder is in control of the private key related to the public one defined in the **cnf** parameter. The recipient MUST cryptographically verify that the Holder is in control of that key. 
       - `[RFC7800, Section 3.1] <https://www.iana.org/go/rfc7800>`_.
     * - **type**
       - Credential type as a string, MUST be set in accordance to the type obtained from the PID/(Q)EAA Issuer metadata. For example, in the case of the PID, it MUST be set to ``PersonIdentificationData``.
@@ -122,7 +121,7 @@ The following claims MUST be in the JWT payload and MUST NOT be included in the
 PID/(Q)EAA Verification field 
 -----------------------------
 
-The ``verification`` claim contains the information regarding the trust framework used by the PID/(Q)EAA Issuer to provide the User claims.  Some of these additional claims MAY be selectively disclosed, these are listed in the following tables that specify whether a claim is selectively disclosable (SD) or not (NSD).
+The ``verification`` claim contains the information regarding the trust framework used by the PID/(Q)EAA Issuer to provide the User attributes (claims).  Some of these additional claims MAY be selectively disclosed, these are listed in the following tables that specify whether a claim is selectively disclosable (SD) or not (NSD).
 
 The ``verification`` claim is a JSON structure with all the following mandatory sub-claims.
 
@@ -183,13 +182,13 @@ The ``claims`` parameter contains the User attributes with the following mandato
       - **Description**
       - **Reference**
     * - **given_name**
-      - [SD]. Current First Name
+      - [SD]. Current First Name.
       - `[OpenID Connect Core 1.0, Section 5.1] <http://openid.net/specs/openid-connect-core-1_0.html>`_
     * - **family_name**
-      - [SD]. Current Family Name
+      - [SD]. Current Family Name.
       - `[OpenID Connect Core 1.0, Section 5.1] <http://openid.net/specs/openid-connect-core-1_0.html>`_
     * - **birthdate**
-      - [SD]. Date of Birth
+      - [SD]. Date of Birth.
       - `[OpenID Connect Core 1.0, Section 5.1] <http://openid.net/specs/openid-connect-core-1_0.html>`_
     * - **place_of_birth**
       - [SD]. Place of Birth. JSON Object with the following subclaims: