From 0e03ad0df03952844abd68050794e3c4a31a47a7 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Thu, 13 Jul 2023 19:01:16 +0200 Subject: [PATCH 01/39] feat: PID section generalized to EAA --- docs/en/index.rst | 2 +- ...{pid-issuance.rst => pid-eaa-issuance.rst} | 176 ++++++++++++------ images/High-Level-Flow-EUDIW-PID-Issuing.svg | 4 - .../High-Level-Flow-ITWallet-PID-Issuance.svg | 3 + ...High-Level-Flow-ITWallet-QEAA-Issuance.svg | 3 + images/Low-Level-Flow-EUDIW-PID-Issuing.svg | 1 - ...-Level-Flow-ITWallet-PID-QEAA-Issuance.svg | 1 + 7 files changed, 125 insertions(+), 65 deletions(-) rename docs/en/{pid-issuance.rst => pid-eaa-issuance.rst} (71%) delete mode 100644 images/High-Level-Flow-EUDIW-PID-Issuing.svg create mode 100644 images/High-Level-Flow-ITWallet-PID-Issuance.svg create mode 100644 images/High-Level-Flow-ITWallet-QEAA-Issuance.svg delete mode 100644 images/Low-Level-Flow-EUDIW-PID-Issuing.svg create mode 100644 images/Low-Level-Flow-ITWallet-PID-QEAA-Issuance.svg diff --git a/docs/en/index.rst b/docs/en/index.rst index ad326c8d7..8ff15fa6e 100644 --- a/docs/en/index.rst +++ b/docs/en/index.rst @@ -66,7 +66,7 @@ Index of content defined-terms.rst trust.rst pid-data-model.rst - pid-issuance.rst + pid-eaa-issuance.rst wallet-solution.rst wallet-instance-attestation.rst relying-party-solution.rst diff --git a/docs/en/pid-issuance.rst b/docs/en/pid-eaa-issuance.rst similarity index 71% rename from docs/en/pid-issuance.rst rename to docs/en/pid-eaa-issuance.rst index 3174acc25..15804e3ec 100644 --- a/docs/en/pid-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -1,10 +1,11 @@ .. include:: ../common/common_definitions.rst -.. _pid_issuance.rst: +.. _pid_eaa_issuance.rst: -PID Issuance -+++++++++++++ +PID/(Q)EAA Issuance ++++++++++++++++++++ +This section describes the issuance flow for the PID and (Q)EAAs that require an high security implementation profile. The relevant entities and interfaces involved in the issuance flow are: - *Wallet Provider*: It represents an organization (public or private) that is responsible for the release of an eIDAS-compliant EUDI Wallet Solution. It also issues thes Wallet Instance Attestation to its Wallet Instances by means of an Attestation Service. The Wallet Attestation certifies the genuinity and authenticity of the Wallet Instance and its compliance with a Trust Framework in compliance to the security and privacy requirements. @@ -15,46 +16,85 @@ The relevant entities and interfaces involved in the issuance flow are: - OpenID4VCI Component: based on the “OpenID for Verifiable Credential Issuance” specification `[OIDC4VCI. Draft 13] `_ to release PID credentials. - National eID Relying Party (OpenID Connect or SAML2): It represents the component to authenticate the End-User with the national Digital Identity Providers. - National IdP: 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 `_). + - *Credential Issuer*: 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] `_ to release (Q)EAAs. + - Relying Party: It represents the component to authenticate the End-User with the PID. -.. _fig_High-Level-Flow-EUDIW-PID-Issuing: -.. figure:: ../../images/High-Level-Flow-EUDIW-PID-Issuing.svg + +High-Level PID flow +------------------- + +The :numref:`fig_High-Level-Flow-ITWallet-PID-Issuance` shows a general architecture and highlights the main operations involved in the issuance of a PID. + +.. _fig_High-Level-Flow-ITWallet-PID-Issuance: +.. figure:: ../../images/High-Level-Flow-ITWallet-PID-Issuance.svg :figwidth: 100% :align: center PID Issuance - General architecture and high level flow -The :numref:`fig_High-Level-Flow-EUDIW-PID-Issuing` shows a general architecture and highlights the main operations involved in the issuance of a PID, in particular: +In the following the main operations are detailed: 0. **Wallet Instance Setup**: the first time the Wallet Instance is started a preliminary setup phase MUST be carried out. It consists of the release of a verifiable proof issued by the Attestation Service provided by the Wallet Provider that asserts the genuineness, the authenticity and the compliance with a trust framework of the Wallet Instance. The verifiable proof binds a public key corresponding to a local private key generated by the Wallet Instance. 1. **Obtaining the trusted PID Provider**: the Wallet Instance queries the Trust Anchor to fetch the trusted PID Provider. 2. **Obtaining of PID Provider metadata**: the Wallet Instance establishes the trust to the PID Provider according to the Trust Model, obtaining the Metadata that discloses the formats of the PID, the algorithms supported, and any other parameter required for interoperability needs. - 3. **PID request**: following the Authorization Code Flow in `[OIDC4VCI. Draft 13] `_ the Wallet Instance requests a PID to the PID Provider. A fresh key pairs is generated by the Wallet Instance, the public key is used by PID Provider for the key binding of the PID. + 3. **PID request**: following the Authorization Code Flow in `[OIDC4VCI. Draft 13] `_ the Wallet Instance requests a PID to the PID Provider. A fresh key pairs is generated by the Wallet Instance, the public key is used by PID Provider for the key binding of the PID. The PID Provider checks the Wallet Instance by means of the Wallet Attestation and the Trust Chain related to the Wallet Provider 4. **End-user authentication**: the PID Provider authenticates the End-User with LoA High, acting as an IAM Proxy to the National eID system. - 5. **PID issuance**: once the User authentication with LoA High happens, the User gives their consent, the PID Provider checks the Wallet Instance by means of the Wallet Attestation and the Trust Chain related to the Wallet Provider. Finally, the PID Provider releases a PID bound to the key material held by the requesting Wallet instance. + 5. **PID issuance**: once the User authentication with LoA High happens, the User gives their consent, and the PID Provider releases a PID bound to the key material held by the requesting Wallet instance. The Wallet Instance Setup phase is described in Section [...]. In the following Section the steps from 1 to 5 are further expanded into more technical detailed steps. +High-Level (Q)EAA flow +---------------------- + +The :numref:`fig_High-Level-Flow-ITWallet-QEAA-Issuance` shows a general architecture and highlights the main operations involved in the issuance of a (Q)EAA, under the main following assumptions: + + - the User has a valid PID stored in its own Wallet Instance; + - the (Q)EAA requires an high security implementation profile. + +.. _fig_High-Level-Flow-ITWallet-QEAA-Issuance: +.. figure:: ../../images/High-Level-Flow-ITWallet-QEAA-Issuance.svg + :figwidth: 70% + :align: center + + (Q)EAA Issuance - General architecture and high level flow + +In the following the main operations are detailed: + + 1. **Obtaining the trusted (Q)EAA Issuer**: the Wallet Instance queries the Trust Anchor to fetch the trusted (Q)EAA Issuer. + 2. **Obtaining of (Q)EAA Issuer metadata**: the Wallet Instance establishes the trust to the (Q)EAA Issuer according to the Trust Model, obtaining the Metadata that discloses the formats of the (Q)EAA, the algorithms supported, and any other parameter required for interoperability needs. + 3. **(Q)EAA request**: following the Authorization Code Flow in `[OIDC4VCI. Draft 13] `_ the Wallet Instance requests a (Q)EAA to the (Q)EAA Issuer. A fresh key pairs is generated by the Wallet Instance, the public key is used by (Q)EAA Issuer for the key binding of the (Q)EAA. The (Q)EAA Issuer checks the Wallet Instance by means of the Wallet Attestation and the Trust Chain related to the Wallet Provider + 4. **End-user authentication**: the (Q)EAA Issuer authenticates the End-User with the PID owned by the User, acting as a Wallet Verifier (Relying Party). + 5. **(Q)EAA issuance**: once the User authentication with a valid PID happens, the User gives their consent, and the (Q)EAA Issuer releases a (Q)EAA bound to the key material held by the requesting Wallet instance. + + + Detailed Flow ------------- -The PID Issuance phase is based on the **Authorization Code Flow** with **Pushed Authorization Requests** (PAR) [:rfc:`9126`] and **PKCE** (Proof Key for Code Exchange, :rfc:`7636`) as recommended in `[OIDC4VCI. Draft 13. Section 3.4] `_. A *Wallet Initiated Flow* is considered and the User receives the PID directly in response to the Credential Request (*Immediate Flow*). +The PID/(Q)EAA Issuance phase is based on the **Authorization Code Flow** with **Pushed Authorization Requests** (PAR) [:rfc:`9126`] and **PKCE** (Proof Key for Code Exchange, :rfc:`7636`) as recommended in `[OIDC4VCI. Draft 13. Section 3.4] `_. A *Wallet Initiated Flow* is considered and the User receives the PID/(Q)EAA directly in response to the Credential Request (*Immediate Flow*). + +.. warning:: + + All the non-normative examples are referred to the PID Provider issuance flow. -.. _fig_Low-Level-Flow-EUDIW-PID-Issuing: -.. figure:: ../../images/Low-Level-Flow-EUDIW-PID-Issuing.svg +.. _fig_Low-Level-Flow-ITWallet-PID-QEAA-Issuance: +.. figure:: ../../images/Low-Level-Flow-ITWallet-PID-QEAA-Issuance.svg :figwidth: 100% :align: center - :target: https://www.plantuml.com/plantuml/svg/bLHTJ-iu47tthnW1qb8frRuZBQ905wf5gwfRn6Fa9jDcrDJE-gEbzzVVSQm4ft1HB-AXySoSENEEntVMIUFyhXRIEwtyReL6Y8RFgA16AWSNhnRD1KWBNeYLVey7VrYmEyvgAgtm0YvVQ5Ev-zhZiFRUw4DVBeUnDrdNw62cc88giCqv25GbS1VnPUxSw3sL4GzM9pdpsUCmWGJ_7M1y2_u6zCf9Kd3KtW1d2WzZ3Xnku8XM2AEqGz1xD720oxVdsN8gOWL8gCawq6jO6cyTbf0s2dpROkuqlkK-XLPhCZjm5OB56Wj7Md7ri4fuxixDzNROEoEMSlRql7nQJAV_YXE9eAYms5h6bgvja682MGXwSAyszZVoeMoxIrLsyvEpi4CdI-baoXs26C3q3Kh7mFyyJ7cK4e5fqPhGn1mWpfbF5h30_psoBDS6RQELnTmT6yoWg0cLowdCslAygC88QeEdtpcpg3IdcOZKbqfhqGJQAM9o_DTLLAKJPU8SbxU3NeqWLPEorK3DLArFKaRGSzJy7iVIHadd3N9b2fpGX618wyHUrbIIEq9YXQ1uCtkXexwiT1GgzuOomFU6MFgSr2XUSYxnyWOcdbKrz2CswbrAR4bWHiBBjf9-kr0CXVRTqdZBtvAnk8gA27OWLm7E7YV_mJC_4-tqHPX9kMHkWZW3d71950WtA8EW8lRK3sVc9tTyWofuYV0urtFOul6NiSPeTd6jpN3JdDwY0gRUQE8PajLOSgHNBmwU0ALgRenKhhlYkkpserktizSX-5AImQ8pXk8eaKkgXYmAj3PloMTnXeYPN2R6pvLM1VO_ye_WbngkELO54LkP2YOJd9VrvpSbQi3_ZMRorWQlhcENQ4-I_xq3QP_UXiI5XpxwXHM93F5b71ZKL-ObhabHb9ZxxwJBOjOelVhTUtt_yZeL2zoGTNmgwphiVa9pRB3ceKeGf28Q0xTpHSVZglnfSA_ZJqZUXDxJPBB4s8xTHxUpRMHH-qSeYD4kYxVnLKlohDC6KtVlc9pVrJy1 + :target: https://www.plantuml.com/plantuml/svg/dPJVRnf74CVVzwyOEP5g9AoyMseK7DCOrQgewoYFf-LkW96FtUlkB8J-zPtH7iTYd8h6yeDzy_lpdTbFaMtWj6cDJUnTsYmm6DF9DwgfiuxXwcl4S0KsGZ9cuR_d3xz4Y1lnwjRUuHMyUwJLck_QXAUnTy7lXd1xQljcsnOPPavQS3Mg3-mCkWQaYddJTnxybfe-t-ALptns_-7wpz5qCe5PZAdt8YC_ExZv2EaM_88jETZx5E3eRXBSY7rt2tkCnWJd6S5lCS0Etdrxc3rFJHzeeQN8u9Vm759aRE2ig0wW6L2gtdoKchLtImeRu3L2n1Ph9kyqnNceITA7jE5VJhiOam2UVNbu_l8qdVvXNe63UetrIvG2bhNAUMAW28fAgwh3RoWChVO1rZKzbGZ44JR8jh5iop50uO1C4j2ofF_zyrIcQX2aELeIXjw7n6S-UO8d_3jXPBWE63ll8bQyxt0CTKlekA9c31fUrMiTnAtmzV-LTB7suXPofY7KneX1-oup5fz_VP_P7D1Cc2NSgkdz24gcD5wSC3rZTaRrT0N_Y-a5oIAjdEKKKCBBxCU6ipGgoTQsr13leT34K5xPWNW63TSziIe56WD-xoXWhCYDyX7e5TXRc2J16-YVN6UGgz2dI3CooMeaqFyEDBPbw46GW519JaL8XmFJDmMif9T4LEVyE-ArBhEIq3EAOZiom3QYMdywCyxk9t_1ev_0WpnUFoZYcWDheN06OC2k-pi6LGu7NhiB_OiBMw7J9KAud_ivlE3-XxOkUB-4fGzlN3kmVq47qdldIQOfplDPBODmYg5CLmgv2jRnuSnySxZHmybVV9Aw4Wq5h0yxGNcWt4l9nDOrnbYnVXxd6NBEOeybV-Mygt7uepeQtoIv5DjQKIeiVS8QtGFRdhzhcO7yTZv6Z54LkyvLiaY5_oKw5CKABGOfFX-jvtgKB7GpJrKQ8gi6b-GeSvOcDfR7sMjqSWtzKtVt-7Lgdd15aVKcsbQVdgBDcu2jPMp0aClPb84EbsNFr_CXuDRNsLQyIOEmnMI5kdrtHRMBjIp83c-XCj7pIJ6_hOLxP1-mLFgJz9WsxRy0 - PID Issuance - Detailed flow + PID/(Q)EAA Issuance - Detailed flow -**Steps 1-4:** The User has selected a PID Provider, and the Wallet Instance obtains the metadata for the selected PID Provider. +**Steps 1-4 (Discovery):** The User has selected a PID/(Q)EAA Issuer, and the Wallet Instance obtains the metadata for the selected PID/(Q)EAA Issuer. .. note:: - **Federation Check:** The Wallet Instance needs to check if the PID Provider is part of Federation and then it can consume its Metadata. A non-normative example of a response from the endpoint **.well-known/openid-federation** with the **Entity Configuration** and the **Metadata** of the PID Provider is represented within the section `Entity Configuration Credential Issuer`_. + **Federation Check:** The Wallet Instance needs to check if the PID/(Q)EAA Issuer is part of Federation and then it can consume its Metadata. A non-normative example of a response from the endpoint **.well-known/openid-federation** with the **Entity Configuration** and the **Metadata** of the PID/(Q)EAA Issuer is represented within the section `Entity Configuration Credential Issuer`_. -**Steps 5-6:** The Wallet Instance creates a PKCE code verifier that sends in a *pushed authorization request*, using the request parameter (see :rfc:`9126` Section 3) to the PID Provider authorization endpoint. The Wallet Instance signs the request using its private key. A OAuth2 client authentication method must be involved, since in this flow the pushed authorization endpoint is a protected endpoint. The client authentication should be based on the model defined in [:rfc:`7521`] using the Wallet Instance Attestation JWS inside the **client_assertion** parameter. The authorization_details [RAR :rfc:`9396`] parameter is extended to allow Wallet Instance to specify the types of the credentials when requesting authorization for the PID issuance. +**Steps 5-6 (PAR Request):** The Wallet Instance creates a PKCE code verifier that sends in a *pushed authorization request*, using the request parameter (see :rfc:`9126` Section 3) to the PID/(Q)EAA Issuer authorization endpoint. The Wallet Instance signs the request using its private key. A OAuth2 client authentication method must be involved, since in this flow the pushed authorization endpoint is a protected endpoint. The client authentication is based on the model defined in [:rfc:`7521`] using the Wallet Instance Attestation JWS inside the **client_assertion** parameter. The authorization_details [RAR :rfc:`9396`] parameter is extended to allow Wallet Instance to specify the types of the credentials when requesting authorization for the PID/(Q)EAA issuance. Below a non-normative example of the PAR. @@ -102,17 +142,16 @@ The JWS payload of the request object is represented below: } ], "redirect_uri":"eudiw://start.wallet.example.org", - "client_assertion_type":"urn:ietf:params:oauth:client-assertion-type:jwt-key-attestation", - -**Step 7:** The PID Provider creates a new request URI representing this new authorization request to be returned to the Wallet Instance. + "client_assertion_type":"urn:ietf:params:oauth:client-assertion-type:jwt-key-attestation", } .. note:: - **Federation Check:** PID Provider MUST check that the Wallet Provider is part of the federation and in addition it MUST verify the Wallet Instance Attestation validity by checking its signature and data. + **Federation Check:** The PID/(Q)EAA Issuer MUST check that the Wallet Provider is part of the federation and in addition it MUST verify the Wallet Instance Attestation validity by checking its signature and data. + -**Step 7:** The PID Provider creates a new request URI representing a new authorization request and returns it to the Wallet Instance. A non-normative example of the authorization request is represented below: +**Step 7 (PAR Response):** The PID/(Q)EAA Issuer creates a new request URI representing a new authorization request and returns it to the Wallet Instance. .. code-block:: http @@ -127,7 +166,7 @@ The JWS payload of the request object is represented below: -**Steps 8-9:** The Wallet Instance sends an authorization request to the PID Provider authorization endpoint. +**Steps 8-9 (Authorization Request):** The Wallet Instance sends an authorization request to the PID/(Q)EAA Issuer authorization endpoint. .. code-block:: http @@ -137,9 +176,10 @@ The JWS payload of the request object is represented below: .. note:: - **User Authentication and Consent:** The PID Provider performs the User authentication based on the requirements of eIDAS LoA High and asks the User consent for the PID issuance. + **User Authentication and Consent:** The PID Provider performs the User authentication based on the requirements of eIDAS LoA High by means of national notified eIDAS scheme and asks the User consent for the PID issuance. + The (Q)EAA Issuer performs the User authentication requesting a valid PID to the Wallet Instance. The (Q)EAA Issuer MUST use [`OpenID4VP`_] to dynamically request presentation of the PID. From a protocol perspective, the Credential Issuer then acts as a verifier and sends a presentation request to the Wallet Instance. The Wallet Instance MUST have these Credentials obtained prior to starting a transaction with the (Q)EAA Issuer. -**Steps 10-11:** The PID Provider sends an authorization code to the Wallet Instance. +**Steps 10-11 (Authorization Response):** The PID/(Q)EAA Issuer sends an authorization code to the Wallet Instance. .. note:: @@ -151,7 +191,7 @@ The JWS payload of the request object is represented below: Location: eudiw://start.wallet.example.org?code=SplxlOBeZQQYbYS6WxSbIA&state=fyZiOL9Lf2CeKuNT2JzxiLRDink0uPcd&iss=https%3A%2F%2Fpid-provider.example.org -**Step 14:** The Wallet Instance sends a token request to the PID Provider token endpoint using the authorization *code*, *code_verifier*, *DPoP proof* and *private_key_jwt*. +**Step 14 (Token Request):** The Wallet Instance sends a token request to the PID/(Q)EAA Issuer token endpoint using the authorization *code*, *code_verifier*, *DPoP proof* and *private_key_jwt*. .. code-block:: http @@ -175,7 +215,7 @@ The JWS payload of the request object is represented below: &client_assertion=eyJhbGciOiJIUzI1NiI -**Step 15:** The PID Provider validates the request and if it is successful, it issues an *access token* (bound to the DPoP key) and a fresh *c_nonce*. +**Step 15 (Token Response):** The PID/(Q)EAA Issuer validates the request and if it is successful, it issues an *access token* (bound to the DPoP key) and a fresh *c_nonce*. .. code-block:: http @@ -192,13 +232,13 @@ The JWS payload of the request object is represented below: } -**Steps 16-18:** The Wallet Instance creates a new key pair to which the new credential shall be bound. Then, it creates a proof of possession with the new key and the *c_nonce* obtained in **Step 15** and it creates a DPoP proof for the request to the PID credential issuance endpoint. +**Steps 16-18 (DPoP Proof):** The Wallet Instance creates a new key pair to which the new credential shall be bound. Then, it creates a proof of possession with the new key and the *c_nonce* obtained in **Step 15** and it creates a DPoP proof for the request to the PID/(Q)EAA credential issuance endpoint. -**Step 19:** The Wallet Instance sends a PID issuance request to the PID Provider credential endpoint. It contains the *access token*, the *DPoP proof*, the *credential type*, the *proof* (proof of possession of the key) and the *format*. +**Step 19 (Credential Request):** The Wallet Instance sends a PID/(Q)EAA issuance request to the PID/(Q)EAA credential endpoint. It contains the *access token*, the *DPoP proof*, the *credential type*, the *proof* (proof of possession of the key) and the *format*. .. note:: - **PID Credential Schema and Status registration:** The PID Provider MUST register all the issued PIDs for their later revocation, if needed. + **PID Credential Schema and Status registration:** The PID/(Q)EAA Issuer MUST register all the issued credentials for their later revocation, if needed. .. code-block:: http @@ -252,7 +292,7 @@ Where the decoded content of the JWT is represented below: -**Steps 20-22:** The PID Provider checks the *DPoP proof* and whether the *access token* is valid and suitable for the requested PID. It also checks the proof of possession for the key material the new credential shall be bound to. If all checks succeed, the PID Provider creates a new credential bound to the key material and sends it to the Wallet Instance. The Wallet Instance MUST perform the PID integrity and authenticity checks and if it is successful can proceed with secure storage of the PID credential. +**Steps 20-22 (Credential Response):** The PID/(Q)EAA Issuer checks the *DPoP proof* and whether the *access token* is valid and suitable for the requested PID/(Q)EAA. It also checks the proof of possession for the key material the new credential shall be bound to. If all checks succeed, the PID/(Q)EAA Issuer creates a new credential bound to the key material and sends it to the Wallet Instance. The Wallet Instance MUST perform the PID/(Q)EAA integrity and authenticity checks and if it is successful can proceed with secure storage of the credential. .. code-block:: http @@ -274,7 +314,7 @@ Pushed Authorization Request Endpoint Pushed Authorization Request (PAR) Request ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -The requests to the PID Provider authorization endpoint MUST be HTTP with method POST, with the following mandatory parameters in the HTTP request message body, encoded in ``application/x-www-form-urlencoded`` format. +The requests to the PID/(Q)EAA authorization endpoint MUST be HTTP with method POST, with the following mandatory parameters in the HTTP request message body, encoded in ``application/x-www-form-urlencoded`` format. .. _table_http_request_claim: .. list-table:: PAR http request parameters @@ -336,6 +376,21 @@ The JWT payload is given by the following parameters: * - **Claim** - **Description** - **Reference** + * - **iss** + - It MUST be set to the ``client_id``. + - :rfc:`9126` and :rfc:`7519`. + * - **aud** + - It MUST be set to the identifier of the PID/(Q)EAA Issuer. + - :rfc:`9126` and :rfc:`7519`. + * - **exp** + - UNIX Timestamp with the expiry time of the JWT, coded as NumericDate. + - :rfc:`9126` and :rfc:`7519`. + * - **iat** + - UNIX Timestamp with the time of JWT issuance, coded as NumericDate. + - :rfc:`9126` and :rfc:`7519`. + * - **jti** [FIXME] + - Unique identifier of the JWT. The value MUST be assigned in a UUID v4 string format according to [:rfc:`4122`]. + - :rfc:`9126` and :rfc:`7519`. * - **response_type** - It MUST be set as in the :ref:`Table of the HTTP parameters `. - See :ref:`Table of the HTTP parameters `. @@ -356,7 +411,7 @@ The JWT payload is given by the following parameters: - **type**: it MUST be set to ``openid_credential``, - **format**: it MUST be set to ``vc+sd-jwt``, - - **credential_definition**: JSON Object. It MUST have the **type** claim which MUST be set to ``eu.eudiw.pid.it`` + - **credential_definition**: JSON Object. It MUST have the **type** claim which MUST be set in accordance to the type of the requested PID/(Q)EAA that is obtained from the PID/(Q)EAA Issuer metadata. For example, in the case of the PID, it MUST be set to ``eu.eudiw.pid.it`` - See [RAR :rfc:`9396`] and `[OIDC4VCI. Draft 13] `_. * - **redirect_uri** - Redirection URI to which the response will be sent. It MUST be an universal or app link registered with the local operating system, so this latter will resolve it and pass the response to the Wallet Instance. @@ -372,7 +427,7 @@ The JWT payload is given by the following parameters: Pushed Authorization Request (PAR) Response ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -If the verification is successful, the PID Provider MUST provide the response with a *201 HTTP status code*. The following parameters are included as top-level members in the HTTP response message body, using the ``application/json`` media type as defined in [:rfc:`8259`]. +If the verification is successful, the PID/(Q)EAA Issuer MUST provide the response with a *201 HTTP status code*. The following parameters are included as top-level members in the HTTP response message body, using the ``application/json`` media type as defined in [:rfc:`8259`]. .. _table_http_response_claim: .. list-table:: @@ -393,7 +448,7 @@ If the verification is successful, the PID Provider MUST provide the response wi Authorization endpoint ---------------------- -The authorization endpoint is used to interact with the Credential Issuer and obtain an authorization grant. +The authorization endpoint is used to interact with the PID/(Q)EAA Issuer and obtain an authorization grant. The authorization server MUST first verify the identity of the resource owner (the User that own it's credentials) as defined in the :rfc:`6749`. @@ -422,9 +477,9 @@ The mandatory parameters in the HTTP authentication request are specified in the Authorization Response ^^^^^^^^^^^^^^^^^^^^^^^ -The authentication response is returned by the PID Provider authorization endpoint at the end of the authentication flow. +The authentication response is returned by the PID/(Q)EAA authorization endpoint at the end of the authentication flow. -If the authentication is successful the PID Provider redirects the User by adding the following query parameters as required to the *redirect_uri*. The redirect URI MUST be an universal or app link registered with the local operating system, so this latter is able to resolve its value and delegates the Wallet Instance for the processing. +If the authentication is successful the PID/(Q)EAA Issuer redirects the User by adding the following query parameters as required to the *redirect_uri*. The redirect URI MUST be an universal or app link registered with the local operating system, so this latter is able to resolve its value and delegates the Wallet Instance for the processing. .. list-table:: :widths: 20 60 20 @@ -434,13 +489,13 @@ If the authentication is successful the PID Provider redirects the User by addin - **Description** - **Reference** * - **code** - - Unique *Authorization Code* that the client submits to the Token Endpoint. + - Unique *Authorization Code* that the Wallet Instance submits to the Token Endpoint. - [:rfc:`6749#section-4.1.2`], `Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants `_ * - **state** - - The client MUST check the correspondence with the state value in the request object. It is defined as in the :ref:`Table of the JWT Request parameters `. + - The Wallet Instance MUST check the correspondence with the state value in the request object. It is defined as in the :ref:`Table of the JWT Request parameters `. - [:rfc:`6749#section-4.1.2`]. * - **iss** - - Unique identifier of the PID PRovider who created the Authentication Response. The Wallet Instance MUST validate this parameter. + - Unique identifier of the PID/(Q)EAA Issuer who created the Authentication Response. The Wallet Instance MUST validate this parameter. - `OAuth 2.0 Authorization Server Issuer Identifier in Authorization Response `_, `[RFC7519, Section 4.1.1] `_. @@ -455,7 +510,7 @@ defined in :rfc:`6749`. Token Request ^^^^^^^^^^^^^^^ -The request to the PID Provider Token endpoint MUST be an HTTP request with method POST, where its body message is encoded in ``application/x-www-form-urlencoded`` format. The Wallet Instance sends the Token endpoint request with *private_key_jwt* authentication and a *DPoP proof* containing the mandatory parameters, defined in the table below. +The request to the PID/(Q)EAA Token endpoint MUST be an HTTP request with method POST, where its body message is encoded in ``application/x-www-form-urlencoded`` format. The Wallet Instance sends the Token endpoint request with *private_key_jwt* authentication and a *DPoP proof* containing the mandatory parameters, defined in the table below. The Token endpoint MUST accept and validate the DPoP proof sent in the DPoP HTTP header. The Token endpoint MUST validate the DPoP proof based on the steps defined in Section 4.3 of the DPoP specifications `[DPoP-draft16] `_. Thus, this mitigates the misuse of leaked or stolen access tokens at the credential endpoint. If the DPoP proof is invalid, the Token endpoint returns an error response, according to Section 5.2 of [:rfc:`6749`] with ``invalid_dpop_proof`` as the value of the error parameter. @@ -488,12 +543,12 @@ The Token endpoint MUST accept and validate the DPoP proof sent in the DPoP HTTP * - **client_assertion** - JWT signed with the Wallet Instance private key containing the following parameters: - - **iss**: This MUST contain the client_id. - - **sub**: This MUST contain the iss. - - **aud**: URL of the PID Provider Token Endpoint. + - **iss**: This MUST contain the ``client_id``. + - **sub**: This MUST contain the ``iss``. + - **aud**: URL of the PID/(Q)EAA Token Endpoint. - **iat**: UNIX Timestamp with the time of the JWT issuance, coded as NumericDate as indicated in RFC 7519. - **exp**: UNIX Timestamp with the expiry time of the JWT, coded as NumericDate as indicated in RFC 7519. - - **jti**: Unique Identifier for this authentication request, generated by the client. E.g., uuid4 format. + - **jti**: Unique Identifier for this authentication request, generated by the Wallet Instance. E.g., uuid4 format. - `Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants `_. A **DPoP proof** is included in an HTTP request using the ``DPoP`` header parameter containing a DPoP JWS. @@ -554,7 +609,7 @@ Token endpoint response MUST contain the following mandatory claims. - **Description** - **Reference** * - **access_token** - - The *DPoP-bound Access Token*, in signed JWT format, allows accessing the Credential Endpoint for obtaining the PID. + - The *DPoP-bound Access Token*, in signed JWT format, allows accessing the PID/(Q)EAA Credential Endpoint for obtaining the credential. - :rfc:`6749`. * - **token_type** - Type of *Access Token* returned. It MUST be equal to ``DPoP``. @@ -572,7 +627,7 @@ Token endpoint response MUST contain the following mandatory claims. Access Token ^^^^^^^^^^^^ -A DPoP-bound Access Token is provided by the PID Provider Token endpoint as a result of a successful token request. The Access Token is encoded in JWT format, according to [:rfc:`7519`]. The Access Token MUST have at least the following mandatory claims and it MUST be bound to the public key that is provided by the DPoP proof. This binding can be accomplished based on the methodology defined in Section 6 of `[DPoP-draft16] `_. +A DPoP-bound Access Token is provided by the PID/(Q)EAA Token endpoint as a result of a successful token request. The Access Token is encoded in JWT format, according to [:rfc:`7519`]. The Access Token MUST have at least the following mandatory claims and it MUST be bound to the public key that is provided by the DPoP proof. This binding can be accomplished based on the methodology defined in Section 6 of `[DPoP-draft16] `_. .. list-table:: :widths: 20 60 20 @@ -582,13 +637,13 @@ A DPoP-bound Access Token is provided by the PID Provider Token endpoint as a re - **Description** - **Reference** * - **iss** - - It MUST be an HTTPS URL that uniquely identifies the PID Provider. The client MUST verify that this value matches the PID Provider where it has requested the credential. + - It MUST be an HTTPS URL that uniquely identifies the PID/(Q)EAA Issuer. The Wallet Instance MUST verify that this value matches the PID/(Q)EAA Issuer where it has requested the credential. - [:rfc:`9068`], `[RFC7519, Section 4.1.1] `_. * - **sub** - It identifies the subject of the JWT. It MUST be of type *pairwise*. - [:rfc:`9068`], [:rfc:`7519`] and [`OpenID.Core#SubjectIDTypes `_]. * - **client_id** - - It MUST contain a HTTPS URL that uniquely identifies the RP. + - MUST be set to the *jwk* value in the *cnf* parameter inside the Wallet Instance Attestation. - [:rfc:`9068`]. * - **aud** - It MUST match the value *client_id*. The RP MUST verify that this value matches its client ID. @@ -602,8 +657,8 @@ A DPoP-bound Access Token is provided by the PID Provider Token endpoint as a re * - **jti** - It MUST be a String in *uuid4* format. Unique Token ID identifier that the RP MAY use to prevent reuse by rejecting the Token ID if already processed. - [:rfc:`9068`], [:rfc:`7519`]. - * - **nonce** - - It MUST be a random string of at least 32 alphanumeric characters. The value type of this claim MUST be a string, where the value is a **c_nonce** provided by the PID Provider. + * - **nonce** [FIXME] + - It MUST be a random string of at least 32 alphanumeric characters. The value type of this claim MUST be a string, where the value is a **c_nonce** provided by the PID/(Q)EAA Issuer. - [`OpenID.Core#AuthRequest `_]. * - **jkt** - JWK SHA-256 Thumbprint Confirmation Method. The value of the jkt member MUST be the base64url encoding (as defined in [RFC7515]) of the JWK SHA-256 Thumbprint of the DPoP public key (in JWK format) to which the access token is bound. @@ -619,9 +674,12 @@ The Credential Endpoint issues a Credential as approved by the End-User upon pre Credential Request ^^^^^^^^^^^^^^^^^^^ -The Wallet Instance may request a PID to the PID Provider Credential endpoint with a HTTP POST request encoded in *application/json* format, where the following parameters in the message body MUST be present. +A Wallet Instance makes a PID/(Q)EAA Request to the PID/(Q)EAA Credential endpoint by sending the following mandatory parameters in the entity-body of an HTTP POST request using the `application/json` media type. +The Credential endpoint MUST accept and validate the *DPoP proof* sent in the DPoP field of the Header based on the steps defined in Section 4.3 of [DPoP-draft16]. The *DPoP proof* in addition to the values that are defined in the Token Endpoint section MUST contain the following claim: + + - **ath**: hash of the Access Token. The value MUST be the result of a base64url encoding (as defined in Section 2 of :rfc:`7515`) the SHA-256 hash of the ASCII encoding of the associated Access Token's value. -The Credential endpoint MUST accept and validate the DPoP proof sent in the DPoP HTTP header based on the steps defined in Section 4.3 of `[DPoP-draft16] `_. If the DPoP proof is invalid, the Credential endpoint returns an error response per Section 5.2 of [:rfc:`6749`] with `invalid_dpop_proof` as the value of the error parameter. +If the *DPoP proof* is invalid, the Credential endpoint returns an error response per Section 5.2 of [:rfc:`6749`] with `invalid_dpop_proof` as the value of the error parameter. .. warning:: The Wallet Instance MUST create a **new DPoP proof** for the Credential request and MUST NOT use the previously created proof for the Token Endpoint. @@ -635,7 +693,7 @@ The Credential endpoint MUST accept and validate the DPoP proof sent in the DPoP - **Description** - **Reference** * - **credential_definition** - - JSON object containing the detailed description of the credential type. It MUST have at least the **type** sub claims which is a JSON array containing the type values the Wallet shall request in the subsequent Credential Request. It MUST be `eu.eudiw.pid.it`. + - JSON object containing the detailed description of the credential type. It MUST have at least the **type** sub claims which is a JSON array containing the type values the Wallet shall request in the subsequent Credential Request. It MUST be set in accordance to the type of the requested PID/(Q)EAA that is obtained from the PID/(Q)EAA Issuer metadata. For example, in the case of the PID, it MUST be set to `eu.eudiw.pid.it`. - `[OIDC4VCI. Draft 13] `_. * - **format** - Format of the Credential to be issued. This MUST be `vc+sd-jwt`. @@ -649,7 +707,7 @@ The Credential endpoint MUST accept and validate the DPoP proof sent in the DPoP .. note:: - If the **format** value is `mso_mdoc`, the credential request MUST contain the doctype claim which is a JSON string identifying the PID type according to `EIDAS-ARF`_ . See Appendix E.2. of `[OIDC4VCI. Draft 13] `_ for more details. + If the **format** value is `mso_mdoc`, the credential request MUST contain the doctype claim which is a JSON string identifying the credential type according to `EIDAS-ARF`_ . See Appendix E.2. of `[OIDC4VCI. Draft 13] `_ for more details. The JWT proof type MUST contain the following parameters for the JOSE header and the JWT body: @@ -668,7 +726,7 @@ The JWT proof type MUST contain the following parameters for the JOSE header and - MUST be `openid4vci-proof+jwt`. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. * - **kid** - - It MUST contain the identifier of the key material the PID shall be bound to. + - It MUST contain the identifier of the key material the PID/(Q)EAA shall be bound to. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7515`], [:rfc:`7517`]. .. list-table:: @@ -682,13 +740,13 @@ The JWT proof type MUST contain the following parameters for the JOSE header and - The value of this claim MUST be the **client_id** of the Wallet Instance. - `[OIDC4VCI. Draft 13] `_, `[RFC7519, Section 4.1.1] `_. * - **aud** - - The value of this claim MUST be the identifier URL of the PID Provider. + - The value of this claim MUST be the identifier URL of the PID/(Q)EAA Issuer. - `[OIDC4VCI. Draft 13] `_. * - **iat** - UNIX Timestamp with the time of JWT issuance, coded as NumericDate as indicated in :rfc:`7519`. - `[OIDC4VCI. Draft 13] `_, [:rfc:`7519`. Section 4.1.6]. * - **nonce** - - The value type of this claim MUST be a string, where the value is a **c_nonce** provided by the PID Provider in the Token response. + - The value type of this claim MUST be a string, where the value is a **c_nonce** provided by the PID/(Q)EAA Issuer in the Token response. - `[OIDC4VCI. Draft 13] `_. @@ -765,7 +823,7 @@ Below a non-normative example of an Entity Configuration containing an `openid_c "pushed_authorization_request_endpoint": "https://pid-provider.example.org/connect/par", "dpop_signing_alg_values_supported": ["RS256", "RS512", "ES256", "ES512"], "credential_endpoint": "https://pid-provider.example.org/credential", - "credentials_supported": { + "credentials_supported": [{ "eu.eudiw.pid.it": { "format": "vc+sd-jwt", "cryptographic_binding_methods_supported": ["jwk"], @@ -869,7 +927,7 @@ Below a non-normative example of an Entity Configuration containing an `openid_c } } } - } + }] }, "federation_entity": { diff --git a/images/High-Level-Flow-EUDIW-PID-Issuing.svg b/images/High-Level-Flow-EUDIW-PID-Issuing.svg deleted file mode 100644 index 470e7c733..000000000 --- a/images/High-Level-Flow-EUDIW-PID-Issuing.svg +++ /dev/null @@ -1,4 +0,0 @@ - - - -
PID Provider
PID Provider
Wallet Solution
Wallet Solution
Wallet Instance
Wallet Instance
OIDC VCI Component
OIDC VCI Component
Issues PID
Issues PID
National eID Component
 (e.g. OIDC, SAML)
National eID Component...
Wallet Provider
Wallet Provider
Attestation Service
Attestation Service
Issues
Wallet Verifiable Attestation
Issues...
Authenticates the User
Authenticates the User
Requests PID
Requests PID
Develop and Maintains
Develop and Maintains
Federation API Services
Federation API Services
Federation API Services
Federation API Serv...
National IdP
National IdP
0
0
3
3
4
4
5
5
Trust Anchor - Accreditation Body
Trust Anchor - Accreditation Body
Federation API Services
Federation API Services
Requests for PID Provider identifier
Requests for PID Provider identifier
1
1
2
2
Requests for PID Provider Metadata
Requests for PID Provider MetadataText is not SVG - cannot display \ No newline at end of file diff --git a/images/High-Level-Flow-ITWallet-PID-Issuance.svg b/images/High-Level-Flow-ITWallet-PID-Issuance.svg new file mode 100644 index 000000000..112223018 --- /dev/null +++ b/images/High-Level-Flow-ITWallet-PID-Issuance.svg @@ -0,0 +1,3 @@ + + +
PID Provider
PID Provider
Wallet Solution
Wallet Solution
Wallet Instance
Wallet Instance
VCI Component (OIDC4VCI)
VCI Component (OIDC4VCI...
Issues PID
Issues PID
National eID Component
 (e.g. OIDC, SAML)
National eID Component...
Wallet Provider
Wallet Provider
Attestation Service
Attestation Service
Issues
Wallet Verifiable Attestation
Issues...
Authenticates the User
Authenticates the User
Requests PID
Requests PID
Develop and Maintains
Develop and Maintains
Federation API Services
Federation API Services
Federation API Services
Federation API Serv...
National IdP
National IdP
0
0
3
3
4
4
5
5
Trust Anchor - Accreditation Body
Trust Anchor - Accreditation Body
Federation API Services
Federation API Services
Requests for PID Provider identifier
Requests for PID Provider identifier
1
1
2
2
Requests for PID Provider Metadata
Requests for PID Provider MetadataViewer does not support full SVG 1.1 \ No newline at end of file diff --git a/images/High-Level-Flow-ITWallet-QEAA-Issuance.svg b/images/High-Level-Flow-ITWallet-QEAA-Issuance.svg new file mode 100644 index 000000000..add0821b9 --- /dev/null +++ b/images/High-Level-Flow-ITWallet-QEAA-Issuance.svg @@ -0,0 +1,3 @@ + + +
(Q)EAA Issuer
(Q)EAA Issuer
Wallet Solution
Wallet Solution
Wallet Instance
Wallet Instance
VCI Component (OIDC4VCI)
VCI Component (OIDC4VCI...
Issues (Q)EAA
Issues (Q)EAA
Requests (Q)EAA
Requests (Q)EAA
Federation API Services
Federation API Services
Trust Anchor - Accreditation Body
Trust Anchor - Accreditation Body
Federation API Services
Federation API Services
Requests for Issuer identifier
Requests for Issuer identifier
1
1
2
2
Register
Register
User Authentication with PID
User Authentication with PID
Requests for Issuer Metadata
Requests for Issuer Metadata
RP Component (OIDC4VP)
RP Component (OIDC4VP)
5
5
3
3
4
4Viewer does not support full SVG 1.1 \ No newline at end of file diff --git a/images/Low-Level-Flow-EUDIW-PID-Issuing.svg b/images/Low-Level-Flow-EUDIW-PID-Issuing.svg deleted file mode 100644 index 34bfe6965..000000000 --- a/images/Low-Level-Flow-EUDIW-PID-Issuing.svg +++ /dev/null @@ -1 +0,0 @@ -User's smartphoneUserUserBrowserBrowserWallet InstanceWallet InstanceWallet ProviderWallet ProviderPID ProviderPID Provider1obtain your PID2yesobtain a list of Trusted PID Provider3confirm the selection of PID Provider4okWallet Instance checks that the PID Provider is part of the Federation and obtain its metadata5create PKCE code verifier6PAR Request (response_type, client_id, code_challenge, code_challenge_method, request, client_assertion_type, client_assertion=$WalletInstanceAttestation$)PID Provider checks that the Wallet Provider is part of the FederationPID Provider checks that the signature of the Wallet Attestation and its validity7PAR Response (request_uri, expires_in)8Authorization Request (client_id, request_uri)9Authorization Request (client_id, request_uri)user authentication with eIDAS High and consent10Authorization Response (code, state)11Authorization Response (code, state)12generate DPoP key13generate DPoP proof for PID Provider token endpoint14Token Request with DPoP proof (client_id, grant_type, code, code_verifier, client_assertion_type, client_assertion, redirect_uri)15Token Response (access_token, token_type, expires_in, c_nonce, c_nonce_expires_in)16generate fresh key for credential17create proof of possession (c_nonce)18create DPoP proof for PID Provider credential endpoint19Credential Request with DPoP access_token and DPoP proof (credential_definition, format, proof)Register all the credential-relatedinformation for verification/revocation20Credential Response (format, credential, c_nonce, c_nonce_expires_in)21PID validity and status check22store credential \ No newline at end of file diff --git a/images/Low-Level-Flow-ITWallet-PID-QEAA-Issuance.svg b/images/Low-Level-Flow-ITWallet-PID-QEAA-Issuance.svg new file mode 100644 index 000000000..243d8e23f --- /dev/null +++ b/images/Low-Level-Flow-ITWallet-PID-QEAA-Issuance.svg @@ -0,0 +1 @@ +User's smartphoneUserUserBrowserBrowserWallet InstanceWallet InstanceWallet ProviderWallet ProviderPID/(Q)EAA IssuerPID/(Q)EAA Issuer1obtain your PID/(Q)EAA2yesobtain a list of Trusted PID/(Q)EAA Issuer3confirm the selection of PID/(Q)EAA Issuer4okWallet Instance checks that the PID/(Q)EAA Issuer is part of the Federation and obtains its metadata5create PKCE code verifier6PAR Request (response_type, client_id, code_challenge, code_challenge_method, request, client_assertion_type, client_assertion=$WalletInstanceAttestation$)PID/(Q)EAA Issuer checks that the Wallet Provider is part of the FederationPID/(Q)EAA Issuer checks that the signature of the Wallet Attestation and its validity7PAR Response (request_uri, expires_in)8Authorization Request (client_id, request_uri)9Authorization Request (client_id, request_uri)alt[(Q)EAA issuance]User authentication with PID and consent[PID issuance]User authentication with eIDAS LoA High and consent10Authorization Response (code, state)11Authorization Response (code, state)12generate DPoP key13generate DPoP proof for PID/(Q)EAA Issuer token endpoint14Token Request with DPoP proof (client_id, grant_type, code, code_verifier, client_assertion_type, client_assertion, redirect_uri)15Token Response (access_token, token_type, expires_in, c_nonce, c_nonce_expires_in)16generate fresh key for credential17create proof of possession (c_nonce)18create DPoP proof for PID/(Q)EAA Issuer credential endpoint19Credential Request with DPoP access_token and DPoP proof (credential_definition, format, proof)Register all the credential-relatedinformation for verification/revocation20Credential Response (format, credential, c_nonce, c_nonce_expires_in)21PID/(Q)EAA validity and status check22store credential \ No newline at end of file From 4728b0416df57ac749031f4836d744d71f4dbe56 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Fri, 14 Jul 2023 10:27:46 +0200 Subject: [PATCH 02/39] fix: according to PR#69 --- docs/en/pid-data-model.rst | 43 +++++++++++++------------------------- 1 file changed, 14 insertions(+), 29 deletions(-) diff --git a/docs/en/pid-data-model.rst b/docs/en/pid-data-model.rst index cc59a0a78..a8d9a4c81 100644 --- a/docs/en/pid-data-model.rst +++ b/docs/en/pid-data-model.rst @@ -48,7 +48,8 @@ The Disclosures are sent to the Holder together with the SD-JWT in the *Combined See `[draft-terbu-sd-jwt-vc-latest] `_ and `[SD-JWT] `__ for more details. - +SD-JWT parameters +----------------- The JOSE header contains the following mandatory parameters: @@ -105,7 +106,7 @@ The following claims MUST be in the JWT payload and MUST NOT be included in the - 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. - `[RFC7800, Section 3.1] `_. * - **type** - - Credential type as a string, MUST be set to ``eu.eudiw.pid.it``. + - Credential type as a string, MUST be set to ``PersonIdentificationData``. - `[draft-terbu-sd-jwt-vc-latest. Section 4.2.2.2] `__. * - **verified_claims** - JSON object containing the following sub-elements: @@ -114,7 +115,11 @@ The following claims MUST be in the JWT payload and MUST NOT be included in the - **claims**. - `[OIDC.IDA. Section 5] `_. -The ``verification`` claim contain the information as sub claims regarding the identity proofing evidence during the issuing phase of the PID. The ``claims`` parameter contains the user attributes claims. Some of these additional claims MAY be included in the Disclosures and MAY be selectively disclosed and they are given in the following tables that also specify whether a claim is selectively disclosable (SD) or not (NSD). + +Verification field +------------------ + +The ``verification`` claim contain the information as sub claims regarding the identity proofing evidence during the issuing phase of the PID. Some of these additional claims MAY be included in the Disclosures and MAY be selectively disclosed and they are given in the following tables that also 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. @@ -162,7 +167,11 @@ The ``record`` MUST have at least the following sub parameters: .. warning:: Note that the sub-claims of the **evidence** parameter are not selectively disclosable separately, thus, for example, the User cannot give only the *record type* without disclosure the *record source* (organization name, identifier and country that hendles the User identity proofing). -Finally, the ``claims`` parameter contains the following mandatory claims: +Claims field +------------ + +The ``claims`` parameter contains the user attributes claims with the following mandatory fields: + .. list-table:: :widths: 20 60 20 @@ -364,31 +373,7 @@ The combined format for the PID issuance is given by .. code-block:: - eyJhbGciOiAiRVMyNTYifQ.eyJpc3MiOiAiaHR0cHM6Ly9waWRwcm92aWRlci5pdCIsI - CJpYXQiOiAxNjgzMDAwMDAwLCAiZXhwIjogMTg4MzAwMDAwMCwgInZlcmlmaWVkX2NsY - WltcyI6IHsidmVyaWZpY2F0aW9uIjogeyJfc2QiOiBbIk9HbTdyeVhndDVYemxldnAtS - HUtVVRrMGEtVHhBYVBBb2JxdjFwSVdNZnciXSwgInRydXN0X2ZyYW1ld29yayI6ICJla - WRhcyIsICJhc3N1cmFuY2VfbGV2ZWwiOiAiaGlnaCJ9LCAiY2xhaW1zIjogeyJfc2QiO - iBbIjhKam96QmZvdk1OdlEzSGZsbVBXeTRPMTlHcHhzNjFGV0hqWmViVTU4OUUiLCAiQ - m9NR2t0VzFyYmlrbnR3OEZ6eF9CZUw0WWJBbmRyNkFIc2RncGF0RkNpZyIsICJDRkxHe - mVudEdOUkZuZ25MVlZRVmNvQUZpMDVyNlJKVVgtcmRiTGRFZmV3IiwgIkpVX3NUYUhDb - mdTMzJYLTBhakhyZDEtSENMQ2twVDVZcWdjZlFtZTE2OHciLCAiVlFJLVMxbVQxS3hmc - TJvOEo5aW83eE1NWDJNSXhhRzlNOVBlSlZxck1jQSIsICJ6VmRnaGNtQ2xNVldsVWdHc - 0dwU2tDUGtFSFo0dTlvV2oxU2xJQmxDYzFvIl19fSwgIl9zZF9hbGciOiAic2hhLTI1N - iJ9.gsvYGCpWbnx8Dkd5ofKq-MtZplFFV49uY42Yf9S3rZe_SPTjg_AWdpm4bvSOhNbe - P0aMzFGtftSk3-3sufXBdw~WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImV2aWRlb - mNlIiwgW3sidHlwZSI6ICJlbGVjdHJvbmljX3JlY29yZCIsICJyZWNvcmQiOiB7InR5c - GUiOiAiZWlkYXMuaXQuY2llIiwgInNvdXJjZSI6IHsib3JnYW5pemF0aW9uX25hbWUiO - iAiTWluaXN0ZXJvIGRlbGwnSW50ZXJubyIsICJvcmdhbml6YXRpb25faWQiOiAibV9pd - CIsICJjb3VudHJ5X2NvZGUiOiAiSVQifX19XV0~WyJlbHVWNU9nM2dTTklJOEVZbnN4Q - V9BIiwgInVuaXF1ZV9pZCIsICJ4eHh4eHh4eC14eHh4LXh4eHgteHh4eC14eHh4eHh4e - Hh4eHgiXQ~WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImdpdmVuX25hbWUiLCAiTW - FyaW8iXQ~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImZhbWlseV9uYW1lIiwgIlJ - vc3NpIl0~WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImJpcnRoZGF0ZSIsICIxOTg - wLTAxLTEwIl0~WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBsYWNlX29mX2JpcnR - oIiwgeyJjb3VudHJ5IjogIklUIiwgImxvY2FsaXR5IjogIlJvbWUifV0~WyJQYzMzSk0 - yTGNoY1VfbEhnZ3ZfdWZRIiwgInRheF9pZF9jb2RlIiwgIlRJTklULVhYWFhYWFhYWFh - YWFhYWFgiXQ + eyJ0eXAiOiJ2YytzZC1qd3QiLCJhbGciOiJSUzUxMiIsImtpZCI6ImQxMjZhNmE4NTZmNzcyNDU2MDQ4NGZhOWRjNTlkMTk1IiwidHJ1c3RfY2hhaW4iOlsiTkVoUmRFUnBZbmxIWTNNNVdsZFdUV1oyYVVobSAuLi4iLCJleUpoYkdjaU9pSlNVekkxTmlJc0ltdHBaQ0k2IC4uLiIsIklrSllkbVp5Ykc1b1FVMTFTRkl3TjJGcVZXMUIgLi4uIl19.eyJpc3MiOiJodHRwczovL3BpZHByb3ZpZGVyLmV4YW1wbGUub3JnIiwic3ViIjoiTnpiTHNYaDh1RENjZDdub1dYRlpBZkhreFpzUkdDOVhzLi4uIiwianRpIjoidXJuOnV1aWQ6NmM1YzBhNDktYjU4OS00MzFkLWJhZTctMjE5MTIyYTllYzJjIiwiaWF0IjoxNTQxNDkzNzI0LCJleHAiOjE1NDE0OTM3MjQsInN0YXR1cyI6Imh0dHBzOi8vcGlkcHJvdmlkZXIuZXhhbXBsZS5vcmcvc3RhdHVzIiwiY25mIjp7Imp3ayI6eyJrdHkiOiJSU0EiLCJ1c2UiOiJzaWciLCJuIjoiMVRhLXNFIOKApiIsImUiOiJBUUFCIiwia2lkIjoiWWhORlMzWW5DOXRqaUNhaXZoV0xWVUozQXh3R0d6Xzk4dVJGYXFNRUVzIn19LCJ0eXBlIjoiUGVyc29uSWRlbnRpZmljYXRpb25EYXRhIiwidmVyaWZpZWRfY2xhaW1zIjp7InZlcmlmaWNhdGlvbiI6eyJfc2QiOlsiT0dtN3J5WGd0NVh6bGV2cC1IdS1VVGswYS1UeEFhUEFvYnF2MXBJV01mdyJdLCJ0cnVzdF9mcmFtZXdvcmsiOiJlaWRhcyIsImFzc3VyYW5jZV9sZXZlbCI6ImhpZ2gifSwiY2xhaW1zIjp7Il9zZCI6WyI4SmpvekJmb3ZNTnZRM0hmbG1QV3k0TzE5R3B4czYxRldIalplYlU1ODlFIiwiQm9NR2t0VzFyYmlrbnR3OEZ6eF9CZUw0WWJBbmRyNkFIc2RncGF0RkNpZyIsIkNGTEd6ZW50R05SRm5nbkxWVlFWY29BRmkwNXI2UkpVWC1yZGJMZEVmZXciLCJKVV9zVGFIQ25nUzMyWC0wYWpIcmQxLUhDTENrcFQ1WXFnY2ZRbWUxNjh3IiwiVlFJLVMxbVQxS3hmcTJvOEo5aW83eE1NWDJNSXhhRzlNOVBlSlZxck1jQSIsInpWZGdoY21DbE1WV2xVZ0dzR3BTa0NQa0VIWjR1OW9XajFTbElCbENjMW8iXX19LCJfc2RfYWxnIjoic2hhLTI1NiJ9.WzEiFaOjnobQisjTQ92JtKEXRN-2Sgvjklpu4IdC_cT2T6Tm8Z6sqbVy6n94AAEv-HFSv5JoSt6YjPDnGzOxN_W_131rILU8YaiNt8w31nRGIvHjJIC0w-hHIcG1LmvJshSMcT3RHeApRCmsO7xkHWmUsjt37dOzEagEti5i47hnZAbu7vWXsvUlBNNN8v7tJBLspO2Q0vnWhEDX1hQ7IH1b8oKh-_aQrhwVm9Bcs9CG8o6N9iqubCSpFI6Gty4ZZgHEb95knETVhw8IL10Z9P_Hr9twXZQaCCC8xrNh4afwR9TiDQzTr92m7luyvDfmzVgHCponI7VBhqmRqZVYQyDhq6EJbtRtIsYenla5NSKBjV8Etdlec94vJAHZNzue9aNUQeXae55V5m5O9wLoWhgV2vl4xV5C-N5s5Uzs08GAxo-CUaNOD3BQE9vfrT47IBCm4hUCnvDise_aWNCeKOQABV1J9_tV9lWZsECVuUuWWwELHCUXgdyiA3QtUtXz From de1d68cb1e0c5e125164a251b89d6e39e913ecad Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Fri, 14 Jul 2023 13:58:42 +0200 Subject: [PATCH 03/39] feat: SD-JWT data model generalized to (Q)EAA --- docs/en/index.rst | 2 +- ...-data-model.rst => pid-eaa-data-model.rst} | 203 ++++++++++++++++-- 2 files changed, 182 insertions(+), 23 deletions(-) rename docs/en/{pid-data-model.rst => pid-eaa-data-model.rst} (64%) diff --git a/docs/en/index.rst b/docs/en/index.rst index 8ff15fa6e..100c7d1ac 100644 --- a/docs/en/index.rst +++ b/docs/en/index.rst @@ -65,7 +65,7 @@ Index of content ssi-introduction.rst defined-terms.rst trust.rst - pid-data-model.rst + pid-eaa-data-model.rst pid-eaa-issuance.rst wallet-solution.rst wallet-instance-attestation.rst diff --git a/docs/en/pid-data-model.rst b/docs/en/pid-eaa-data-model.rst similarity index 64% rename from docs/en/pid-data-model.rst rename to docs/en/pid-eaa-data-model.rst index a8d9a4c81..3571de09a 100644 --- a/docs/en/pid-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -1,10 +1,10 @@ .. include:: ../common/common_definitions.rst -.. _pid_data_model.rst: +.. _pid_eaa_data_model.rst: -PID Data Model -++++++++++++++ +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. @@ -19,14 +19,16 @@ The User attributes carried in the Italian PID are: The italian PID is extended according to the `OpenID Identity Assurance Profile [OIDC.IDA] `_, that enables the binding of the PID to a national trust framework, giving all the evidence of the identity proofing procedures underlying the PID issuing in both remote and proximity flows. -The PID data format and the mechanism through which it is issued into the Wallet Instance and presented to a RP will be detailed in the next sections. +The (Q)EAAs are issued by the (Q)EAA Issuers to a Wallet Instance and MUST be provided in SD-JWT-VC or mDOC CBOR data format. They MAY contain any (qualified) attributes, entitlement or any elettronic attestation. - +The italian (Q)EAAs are extended according to the `OpenID Identity Assurance Profile [OIDC.IDA] `_, that allows the recipients to know the Authentic Sources where the data are taken. + +The PID/(Q)EAA data format and the mechanism through which it is issued into the Wallet Instance and presented to a RP will be detailed in the next sections. SD-JWT ====== -The PID is given as a Verifiable Credential with JSON payload based on the `Selective Disclosure JWT format `_ as specified in `[draft-terbu-sd-jwt-vc-latest] `__. +The PID/(Q)EAA is given as a Verifiable Credential with JSON payload based on the `Selective Disclosure JWT format `_ as specified in `[draft-terbu-sd-jwt-vc-latest] `__. An SD-JWT is a JWT that MUST be signed using the Issuer's private key. The SD-JWT payload of the MUST contain the **_sd_alg** claim described in `[SD-JWT]. Section 5.1.2. `_ and other claims specified in this section, some of them may be selectively disclosable claims. @@ -48,8 +50,8 @@ The Disclosures are sent to the Holder together with the SD-JWT in the *Combined See `[draft-terbu-sd-jwt-vc-latest] `_ and `[SD-JWT] `__ for more details. -SD-JWT parameters ------------------ +PID/(Q)EAA SD-JWT parameters +---------------------------- The JOSE header contains the following mandatory parameters: @@ -85,7 +87,7 @@ The following claims MUST be in the JWT payload and MUST NOT be included in the - **Description** - **Reference** * - **iss** - - The PID Provider identifier as URL string (the issuer of this JWT) + - The PID/(Q)EAA Issuer identifier as URL string (the issuer of this JWT) - `[RFC7519, Section 4.1.1] `_. * - **sub** - Thumbprint of the JWK in the ``cnf`` parameter @@ -106,7 +108,7 @@ The following claims MUST be in the JWT payload and MUST NOT be included in the - 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. - `[RFC7800, Section 3.1] `_. * - **type** - - Credential type as a string, MUST be set to ``PersonIdentificationData``. + - 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``. - `[draft-terbu-sd-jwt-vc-latest. Section 4.2.2.2] `__. * - **verified_claims** - JSON object containing the following sub-elements: @@ -116,8 +118,8 @@ The following claims MUST be in the JWT payload and MUST NOT be included in the - `[OIDC.IDA. Section 5] `_. -Verification field ------------------- +PID/(Q)EAA Verification field +----------------------------- The ``verification`` claim contain the information as sub claims regarding the identity proofing evidence during the issuing phase of the PID. Some of these additional claims MAY be included in the Disclosures and MAY be selectively disclosed and they are given in the following tables that also specify whether a claim is selectively disclosable (SD) or not (NSD). @@ -131,13 +133,13 @@ The ``verification`` claim is a JSON structure with all the following mandatory - **Description** - **Reference** * - **trust_framework** - - [NSD]. MUST be set to eidas + - [NSD]. For PID credential it MUST be set to ``eidas``. For (Q)EAA it MUST be set to ``eidas2``. - `[OID.IDA. Section 5.1] `_ * - **assurance_level** - - [NSD]. MUST be set to high + - [NSD]. MUST be set according to the LoA. For PID credential it MUST be set o ``high``. - `[OID.IDA. Section 5.1] `_ * - **evidence** - - [SD]. JSON Array. Each element is the electronic evidence of the user identification during the PID issuing phase. It MUST contain at least the following claims: + - [SD]. JSON Array. Each element is the electronic evidence of the user identification during the PID issuing phase or, in case of (Q)EAA, it represents the evidence of the Authentic Sources that ensure the authenticity of the data conveyed by the (Q)EAA. It MUST contain at least the following claims: - **type**: MUST be set to ``electronic_record`` - **record**: JSON object (see the table below) @@ -154,21 +156,21 @@ The ``record`` MUST have at least the following sub parameters: - **Description** - **Reference** * - **type** - - identification of the national eID framework used by the User. For example ``eidas.it.cie`` means that the CIE id identification scheme is used by the User. + - Identification of the trust framework used for obtaining the verified claims. For example, in case of PID, ``eidas.it.cie`` means that the CIE id identification scheme is used by the User. - `[OID.IDA. Section 5.1.1.2] `_ * - **source** - JSON Object cointaining the follwoing mandatory claims: - - **organization_name**: Name of the Organization handling the eID used by the User - - **organization_id**: Identification code for the Organization. It MUST be set to the *IPA Code* of the Organization + - **organization_name**: Name of the Organization. In case of PID, it is the Organization handling the eID used by the User. For the (Q)EAA it is the Authentic Source. + - **organization_id**: Identification code for the Organization. For public Organization, it MUST be set to the *IPA Code*. - **country_code**: String representing country in `[ISO3166-1] Alpha-2 (e.g., IT) or [ISO3166-3] syntax `_. - `[OID.IDA. Section 5.1.1.2] `_ .. warning:: Note that the sub-claims of the **evidence** parameter are not selectively disclosable separately, thus, for example, the User cannot give only the *record type* without disclosure the *record source* (organization name, identifier and country that hendles the User identity proofing). -Claims field ------------- +PID Claims field +---------------- The ``claims`` parameter contains the user attributes claims with the following mandatory fields: @@ -204,8 +206,8 @@ The ``claims`` parameter contains the user attributes claims with the following -Non-normative examples ----------------------- +PID Non-normative examples +-------------------------- In the following, we provide a non-normative example of PID VC in JSON. @@ -375,7 +377,164 @@ The combined format for the PID issuance is given by eyJ0eXAiOiJ2YytzZC1qd3QiLCJhbGciOiJSUzUxMiIsImtpZCI6ImQxMjZhNmE4NTZmNzcyNDU2MDQ4NGZhOWRjNTlkMTk1IiwidHJ1c3RfY2hhaW4iOlsiTkVoUmRFUnBZbmxIWTNNNVdsZFdUV1oyYVVobSAuLi4iLCJleUpoYkdjaU9pSlNVekkxTmlJc0ltdHBaQ0k2IC4uLiIsIklrSllkbVp5Ykc1b1FVMTFTRkl3TjJGcVZXMUIgLi4uIl19.eyJpc3MiOiJodHRwczovL3BpZHByb3ZpZGVyLmV4YW1wbGUub3JnIiwic3ViIjoiTnpiTHNYaDh1RENjZDdub1dYRlpBZkhreFpzUkdDOVhzLi4uIiwianRpIjoidXJuOnV1aWQ6NmM1YzBhNDktYjU4OS00MzFkLWJhZTctMjE5MTIyYTllYzJjIiwiaWF0IjoxNTQxNDkzNzI0LCJleHAiOjE1NDE0OTM3MjQsInN0YXR1cyI6Imh0dHBzOi8vcGlkcHJvdmlkZXIuZXhhbXBsZS5vcmcvc3RhdHVzIiwiY25mIjp7Imp3ayI6eyJrdHkiOiJSU0EiLCJ1c2UiOiJzaWciLCJuIjoiMVRhLXNFIOKApiIsImUiOiJBUUFCIiwia2lkIjoiWWhORlMzWW5DOXRqaUNhaXZoV0xWVUozQXh3R0d6Xzk4dVJGYXFNRUVzIn19LCJ0eXBlIjoiUGVyc29uSWRlbnRpZmljYXRpb25EYXRhIiwidmVyaWZpZWRfY2xhaW1zIjp7InZlcmlmaWNhdGlvbiI6eyJfc2QiOlsiT0dtN3J5WGd0NVh6bGV2cC1IdS1VVGswYS1UeEFhUEFvYnF2MXBJV01mdyJdLCJ0cnVzdF9mcmFtZXdvcmsiOiJlaWRhcyIsImFzc3VyYW5jZV9sZXZlbCI6ImhpZ2gifSwiY2xhaW1zIjp7Il9zZCI6WyI4SmpvekJmb3ZNTnZRM0hmbG1QV3k0TzE5R3B4czYxRldIalplYlU1ODlFIiwiQm9NR2t0VzFyYmlrbnR3OEZ6eF9CZUw0WWJBbmRyNkFIc2RncGF0RkNpZyIsIkNGTEd6ZW50R05SRm5nbkxWVlFWY29BRmkwNXI2UkpVWC1yZGJMZEVmZXciLCJKVV9zVGFIQ25nUzMyWC0wYWpIcmQxLUhDTENrcFQ1WXFnY2ZRbWUxNjh3IiwiVlFJLVMxbVQxS3hmcTJvOEo5aW83eE1NWDJNSXhhRzlNOVBlSlZxck1jQSIsInpWZGdoY21DbE1WV2xVZ0dzR3BTa0NQa0VIWjR1OW9XajFTbElCbENjMW8iXX19LCJfc2RfYWxnIjoic2hhLTI1NiJ9.WzEiFaOjnobQisjTQ92JtKEXRN-2Sgvjklpu4IdC_cT2T6Tm8Z6sqbVy6n94AAEv-HFSv5JoSt6YjPDnGzOxN_W_131rILU8YaiNt8w31nRGIvHjJIC0w-hHIcG1LmvJshSMcT3RHeApRCmsO7xkHWmUsjt37dOzEagEti5i47hnZAbu7vWXsvUlBNNN8v7tJBLspO2Q0vnWhEDX1hQ7IH1b8oKh-_aQrhwVm9Bcs9CG8o6N9iqubCSpFI6Gty4ZZgHEb95knETVhw8IL10Z9P_Hr9twXZQaCCC8xrNh4afwR9TiDQzTr92m7luyvDfmzVgHCponI7VBhqmRqZVYQyDhq6EJbtRtIsYenla5NSKBjV8Etdlec94vJAHZNzue9aNUQeXae55V5m5O9wLoWhgV2vl4xV5C-N5s5Uzs08GAxo-CUaNOD3BQE9vfrT47IBCm4hUCnvDise_aWNCeKOQABV1J9_tV9lWZsECVuUuWWwELHCUXgdyiA3QtUtXz +(Q)EAA Non-normative examples +----------------------------- + +In the following, we provide a non-normative example of (Q)EAA VC in JSON. + +.. code-block:: JSON + + { + "verified_claims": { + "verification": { + "trust_framework": "eidas2", + "assurance_level": "high", + "evidence": [ + { + "type": "electronic_record", + "record": { + "type": "eidas.it.pdnd", + "source": { + "organization_name": "Ragioneria Generale dello Stato", + "organization_id": "QLHCFC", + "country_code": "IT" + } + } + } + ] + }, + "claims": { + "given_name": "Mario", + "family_name": "Rossi", + "birthdate": "1980-01-10", + "place_of_birth": { + "country": "IT", + "locality": "Rome" + }, + "tax_id_code": "TINIT-XXXXXXXXXXXXXXXX" + } + } + } + +The corresponding SD-JWT verson for PID is given by + +.. code-block:: JSON + + { + "typ":"vc+sd-jwt", + "alg":"RS512", + "kid":"dB67gL7ck3TFiIAf7N6_7SHvqk0MDYMEQcoGGlkUAAw", + "trust_chain" : [ + "NEhRdERpYnlHY3M5WldWTWZ2aUhm ...", + "eyJhbGciOiJSUzI1NiIsImtpZCI6 ...", + "IkJYdmZybG5oQU11SFIwN2FqVW1B ..." + ] + } +.. code-block:: JSON + + { + "iss": "https://issuer.example.org", + "sub": "NzbLsXh8uDCcd7noWXFZAfHkxZsRGC9Xs...", + "jti": "urn:uuid:6c5c0a49-b589-431d-bae7-219122a9ec2c", + "iat": 1541493724, + "exp": 1541493724, + "status": "https://issuer.example.org/status", + "cnf": { + "jwk": { + "kty": "RSA", + "use": "sig", + "n": "1Ta-sE …", + "e": "AQAB", + "kid": "YhNFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs" + } + }, + "type": "HealthInsuranceData", + "verified_claims": { + "verification": { + "_sd": [ + "OGm7ryXgt5Xzlevp-Hu-UTk0a-TxAaPAobqv1pIWMfw" + ], + "trust_framework": "eidas2", + "assurance_level": "high" + }, + "claims": { + "_sd": [ + "BoMGktW1rbikntw8Fzx_BeL4YbAndr6AHsdgpatFCig", + "CFLGzentGNRFngnLVVQVcoAFi05r6RJUX-rdbLdEfew", + "JU_sTaHCngS32X-0ajHrd1-HCLCkpT5YqgcfQme168w", + "VQI-S1mT1Kxfq2o8J9io7xMMX2MIxaG9M9PeJVqrMcA", + "zVdghcmClMVWlUgGsGpSkCPkEHZ4u9oWj1SlIBlCc1o" + ] + } + }, + "_sd_alg": "sha-256" + } + +In the following the disclosure list is given + +Claim **evidence**: + +- SHA-256 Hash: ``OGm7ryXgt5Xzlevp-Hu-UTk0a-TxAaPAobqv1pIWMfw`` +- Disclosure: + ``WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImV2aWRlbmNlIiwgW3sidHlw`` + ``ZSI6ICJlbGVjdHJvbmljX3JlY29yZCIsICJyZWNvcmQiOiB7InR5cGUiOiAi`` + ``ZWlkYXMuaXQuY2llIiwgInNvdXJjZSI6IHsib3JnYW5pemF0aW9uX25hbWUi`` + ``OiAiTWluaXN0ZXJvIGRlbGwnSW50ZXJubyIsICJvcmdhbml6YXRpb25faWQi`` + ``OiAibV9pdCIsICJjb3VudHJ5X2NvZGUiOiAiSVQifX19XV0`` +- Contents: ``["2GLC42sKQveCfGfryNRN9w", "evidence", [{"type":`` + ``"electronic_record", "record": {"type": "eidas.it.cie",`` + ``"source": {"organization_name": "Ministero dell'Interno",`` + ``"organization_id": "m_it", "country_code": "IT"}}}]]`` + +Claim **given_name**: + +- SHA-256 Hash: ``zVdghcmClMVWlUgGsGpSkCPkEHZ4u9oWj1SlIBlCc1o`` +- Disclosure: + ``WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImdpdmVuX25hbWUiLCAiTWFy`` + ``aW8iXQ`` +- Contents: ``["6Ij7tM-a5iVPGboS5tmvVA", "given_name", "Mario"]`` + +Claim **family_name**: + +- SHA-256 Hash: ``VQI-S1mT1Kxfq2o8J9io7xMMX2MIxaG9M9PeJVqrMcA`` +- Disclosure: + ``WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImZhbWlseV9uYW1lIiwgIlJv`` + ``c3NpIl0`` +- Contents: ``["eI8ZWm9QnKPpNPeNenHdhQ", "family_name", "Rossi"]`` + +Claim **birthdate**: + +- SHA-256 Hash: ``CFLGzentGNRFngnLVVQVcoAFi05r6RJUX-rdbLdEfew`` +- Disclosure: + ``WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImJpcnRoZGF0ZSIsICIxOTgw`` + ``LTAxLTEwIl0`` +- Contents: ``["Qg_O64zqAxe412a108iroA", "birthdate", "1980-01-10"]`` + +Claim **place_of_birth**: + +- SHA-256 Hash: ``JU_sTaHCngS32X-0ajHrd1-HCLCkpT5YqgcfQme168w`` +- Disclosure: + ``WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBsYWNlX29mX2JpcnRoIiwg`` + ``eyJjb3VudHJ5IjogIklUIiwgImxvY2FsaXR5IjogIlJvbWUifV0`` +- Contents: + ``["AJx-095VPrpTtN4QMOqROA", "place_of_birth", {"country":`` + ``"IT", "locality": "Rome"}]`` + +Claim **tax_id_code**: + +- SHA-256 Hash: ``8JjozBfovMNvQ3HflmPWy4O19Gpxs61FWHjZebU589E`` +- Disclosure: + ``WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgInRheF9pZF9jb2RlIiwgIlRJ`` + ``TklULVhYWFhYWFhYWFhYWFhYWFgiXQ`` +- Contents: ``["Pc33JM2LchcU_lHggv_ufQ", "tax_id_code",`` + ``"TINIT-XXXXXXXXXXXXXXXX"]`` + +The combined format for the PID issuance is given by + +.. code-block:: + + eyJ0eXAiOiJ2YytzZC1qd3QiLCJhbGciOiJSUzUxMiIsImtpZCI6ImQxMjZhNmE4NTZmNzcyNDU2MDQ4NGZhOWRjNTlkMTk1IiwidHJ1c3RfY2hhaW4iOlsiTkVoUmRFUnBZbmxIWTNNNVdsZFdUV1oyYVVobSAuLi4iLCJleUpoYkdjaU9pSlNVekkxTmlJc0ltdHBaQ0k2IC4uLiIsIklrSllkbVp5Ykc1b1FVMTFTRkl3TjJGcVZXMUIgLi4uIl19.eyJpc3MiOiJodHRwczovL3BpZHByb3ZpZGVyLmV4YW1wbGUub3JnIiwic3ViIjoiTnpiTHNYaDh1RENjZDdub1dYRlpBZkhreFpzUkdDOVhzLi4uIiwianRpIjoidXJuOnV1aWQ6NmM1YzBhNDktYjU4OS00MzFkLWJhZTctMjE5MTIyYTllYzJjIiwiaWF0IjoxNTQxNDkzNzI0LCJleHAiOjE1NDE0OTM3MjQsInN0YXR1cyI6Imh0dHBzOi8vcGlkcHJvdmlkZXIuZXhhbXBsZS5vcmcvc3RhdHVzIiwiY25mIjp7Imp3ayI6eyJrdHkiOiJSU0EiLCJ1c2UiOiJzaWciLCJuIjoiMVRhLXNFIOKApiIsImUiOiJBUUFCIiwia2lkIjoiWWhORlMzWW5DOXRqaUNhaXZoV0xWVUozQXh3R0d6Xzk4dVJGYXFNRUVzIn19LCJ0eXBlIjoiUGVyc29uSWRlbnRpZmljYXRpb25EYXRhIiwidmVyaWZpZWRfY2xhaW1zIjp7InZlcmlmaWNhdGlvbiI6eyJfc2QiOlsiT0dtN3J5WGd0NVh6bGV2cC1IdS1VVGswYS1UeEFhUEFvYnF2MXBJV01mdyJdLCJ0cnVzdF9mcmFtZXdvcmsiOiJlaWRhcyIsImFzc3VyYW5jZV9sZXZlbCI6ImhpZ2gifSwiY2xhaW1zIjp7Il9zZCI6WyI4SmpvekJmb3ZNTnZRM0hmbG1QV3k0TzE5R3B4czYxRldIalplYlU1ODlFIiwiQm9NR2t0VzFyYmlrbnR3OEZ6eF9CZUw0WWJBbmRyNkFIc2RncGF0RkNpZyIsIkNGTEd6ZW50R05SRm5nbkxWVlFWY29BRmkwNXI2UkpVWC1yZGJMZEVmZXciLCJKVV9zVGFIQ25nUzMyWC0wYWpIcmQxLUhDTENrcFQ1WXFnY2ZRbWUxNjh3IiwiVlFJLVMxbVQxS3hmcTJvOEo5aW83eE1NWDJNSXhhRzlNOVBlSlZxck1jQSIsInpWZGdoY21DbE1WV2xVZ0dzR3BTa0NQa0VIWjR1OW9XajFTbElCbENjMW8iXX19LCJfc2RfYWxnIjoic2hhLTI1NiJ9.WzEiFaOjnobQisjTQ92JtKEXRN-2Sgvjklpu4IdC_cT2T6Tm8Z6sqbVy6n94AAEv-HFSv5JoSt6YjPDnGzOxN_W_131rILU8YaiNt8w31nRGIvHjJIC0w-hHIcG1LmvJshSMcT3RHeApRCmsO7xkHWmUsjt37dOzEagEti5i47hnZAbu7vWXsvUlBNNN8v7tJBLspO2Q0vnWhEDX1hQ7IH1b8oKh-_aQrhwVm9Bcs9CG8o6N9iqubCSpFI6Gty4ZZgHEb95knETVhw8IL10Z9P_Hr9twXZQaCCC8xrNh4afwR9TiDQzTr92m7luyvDfmzVgHCponI7VBhqmRqZVYQyDhq6EJbtRtIsYenla5NSKBjV8Etdlec94vJAHZNzue9aNUQeXae55V5m5O9wLoWhgV2vl4xV5C-N5s5Uzs08GAxo-CUaNOD3BQE9vfrT47IBCm4hUCnvDise_aWNCeKOQABV1J9_tV9lWZsECVuUuWWwELHCUXgdyiA3QtUtXz MDOC-CBOR ========= From b55c10cd14810d1a2fe719afb132f07cad5091e0 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Fri, 14 Jul 2023 15:15:43 +0200 Subject: [PATCH 04/39] fix: non-normative example of (Q)EAA SD-JWT-VC --- docs/en/pid-eaa-data-model.rst | 62 ++++++++++++++++------------------ 1 file changed, 30 insertions(+), 32 deletions(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index 3571de09a..2733b5188 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -453,18 +453,18 @@ The corresponding SD-JWT verson for PID is given by "verified_claims": { "verification": { "_sd": [ - "OGm7ryXgt5Xzlevp-Hu-UTk0a-TxAaPAobqv1pIWMfw" + "2jIR18gfeASHYGB27s7sS3S_iQ4xxFIxCRyiohrBfns" ], "trust_framework": "eidas2", "assurance_level": "high" }, "claims": { "_sd": [ - "BoMGktW1rbikntw8Fzx_BeL4YbAndr6AHsdgpatFCig", - "CFLGzentGNRFngnLVVQVcoAFi05r6RJUX-rdbLdEfew", - "JU_sTaHCngS32X-0ajHrd1-HCLCkpT5YqgcfQme168w", - "VQI-S1mT1Kxfq2o8J9io7xMMX2MIxaG9M9PeJVqrMcA", - "zVdghcmClMVWlUgGsGpSkCPkEHZ4u9oWj1SlIBlCc1o" + "1iztq7bov64xTYbDkWFc44_VjWe029hZqXeUIloqUN4", + "ENNo31jfzFp8Y2DW0R-fIMeWwe7ELGvGoHMwMBpu14E", + "FV2CDNWuTqTgOHaftvVaumBF0OlmnyxMswyf4uIxrhY", + "dZWjq7mJSSX-XTI_HWuE8B2x6IdM5lE-doD_yBpKJao", + "gHYi19frbD_i4BoaWENOjc3lCnMj4pbGNQcsBj_QM4Q" ] } }, @@ -475,66 +475,64 @@ In the following the disclosure list is given Claim **evidence**: -- SHA-256 Hash: ``OGm7ryXgt5Xzlevp-Hu-UTk0a-TxAaPAobqv1pIWMfw`` +- SHA-256 Hash: ``2jIR18gfeASHYGB27s7sS3S_iQ4xxFIxCRyiohrBfns`` - Disclosure: ``WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImV2aWRlbmNlIiwgW3sidHlw`` ``ZSI6ICJlbGVjdHJvbmljX3JlY29yZCIsICJyZWNvcmQiOiB7InR5cGUiOiAi`` - ``ZWlkYXMuaXQuY2llIiwgInNvdXJjZSI6IHsib3JnYW5pemF0aW9uX25hbWUi`` - ``OiAiTWluaXN0ZXJvIGRlbGwnSW50ZXJubyIsICJvcmdhbml6YXRpb25faWQi`` - ``OiAibV9pdCIsICJjb3VudHJ5X2NvZGUiOiAiSVQifX19XV0`` + ``ZWlkYXMuaXQucGRuZCIsICJzb3VyY2UiOiB7Im9yZ2FuaXphdGlvbl9uYW1l`` + ``IjogIlJhZ2lvbmVyaWEgR2VuZXJhbGUgZGVsbG8gU3RhdG8iLCAib3JnYW5p`` + ``emF0aW9uX2lkIjogIlFMSENGQyIsICJjb3VudHJ5X2NvZGUiOiAiSVQifX19`` + ``XV0`` - Contents: ``["2GLC42sKQveCfGfryNRN9w", "evidence", [{"type":`` - ``"electronic_record", "record": {"type": "eidas.it.cie",`` - ``"source": {"organization_name": "Ministero dell'Interno",`` - ``"organization_id": "m_it", "country_code": "IT"}}}]]`` + ``"electronic_record", "record": {"type": "eidas.it.pdnd",`` + ``"source": {"organization_name": "Ragioneria Generale dello Stato",`` + ``"organization_id": "QLHCFC", "country_code":"IT"}}}]]`` Claim **given_name**: -- SHA-256 Hash: ``zVdghcmClMVWlUgGsGpSkCPkEHZ4u9oWj1SlIBlCc1o`` +- SHA-256 Hash: ``gHYi19frbD_i4BoaWENOjc3lCnMj4pbGNQcsBj_QM4Q`` - Disclosure: - ``WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImdpdmVuX25hbWUiLCAiTWFy`` - ``aW8iXQ`` -- Contents: ``["6Ij7tM-a5iVPGboS5tmvVA", "given_name", "Mario"]`` + ``WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiTWFyaW8iXQ`` +- Contents: ``["eluV5Og3gSNII8EYnsxA_A", "given_name", "Mario"]`` Claim **family_name**: -- SHA-256 Hash: ``VQI-S1mT1Kxfq2o8J9io7xMMX2MIxaG9M9PeJVqrMcA`` +- SHA-256 Hash: ``dZWjq7mJSSX-XTI_HWuE8B2x6IdM5lE-doD_yBpKJao`` - Disclosure: - ``WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImZhbWlseV9uYW1lIiwgIlJv`` - ``c3NpIl0`` -- Contents: ``["eI8ZWm9QnKPpNPeNenHdhQ", "family_name", "Rossi"]`` + ``WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlJvc3NpIl0`` +- Contents: ``["6Ij7tM-a5iVPGboS5tmvVA", "family_name", "Rossi"]`` Claim **birthdate**: -- SHA-256 Hash: ``CFLGzentGNRFngnLVVQVcoAFi05r6RJUX-rdbLdEfew`` +- SHA-256 Hash: ``FV2CDNWuTqTgOHaftvVaumBF0OlmnyxMswyf4uIxrhY`` - Disclosure: - ``WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgImJpcnRoZGF0ZSIsICIxOTgw`` - ``LTAxLTEwIl0`` -- Contents: ``["Qg_O64zqAxe412a108iroA", "birthdate", "1980-01-10"]`` + ``WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImJpcnRoZGF0ZSIsICIxOTgwLTAxLTEwIl0`` +- Contents: ``["eI8ZWm9QnKPpNPeNenHdhQ", "birthdate", "1980-01-10"]`` Claim **place_of_birth**: -- SHA-256 Hash: ``JU_sTaHCngS32X-0ajHrd1-HCLCkpT5YqgcfQme168w`` +- SHA-256 Hash: ``1iztq7bov64xTYbDkWFc44_VjWe029hZqXeUIloqUN4`` - Disclosure: - ``WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInBsYWNlX29mX2JpcnRoIiwg`` + ``WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBsYWNlX29mX2JpcnRoIiwg`` ``eyJjb3VudHJ5IjogIklUIiwgImxvY2FsaXR5IjogIlJvbWUifV0`` - Contents: - ``["AJx-095VPrpTtN4QMOqROA", "place_of_birth", {"country":`` + ``["Qg_O64zqAxe412a108iroA", "place_of_birth", {"country":`` ``"IT", "locality": "Rome"}]`` Claim **tax_id_code**: -- SHA-256 Hash: ``8JjozBfovMNvQ3HflmPWy4O19Gpxs61FWHjZebU589E`` +- SHA-256 Hash: ``ENNo31jfzFp8Y2DW0R-fIMeWwe7ELGvGoHMwMBpu14E`` - Disclosure: - ``WyJQYzMzSk0yTGNoY1VfbEhnZ3ZfdWZRIiwgInRheF9pZF9jb2RlIiwgIlRJ`` + ``WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInRheF9pZF9jb2RlIiwgIlRJ`` ``TklULVhYWFhYWFhYWFhYWFhYWFgiXQ`` -- Contents: ``["Pc33JM2LchcU_lHggv_ufQ", "tax_id_code",`` +- Contents: ``["AJx-095VPrpTtN4QMOqROA", "tax_id_code",`` ``"TINIT-XXXXXXXXXXXXXXXX"]`` The combined format for the PID issuance is given by .. code-block:: - eyJ0eXAiOiJ2YytzZC1qd3QiLCJhbGciOiJSUzUxMiIsImtpZCI6ImQxMjZhNmE4NTZmNzcyNDU2MDQ4NGZhOWRjNTlkMTk1IiwidHJ1c3RfY2hhaW4iOlsiTkVoUmRFUnBZbmxIWTNNNVdsZFdUV1oyYVVobSAuLi4iLCJleUpoYkdjaU9pSlNVekkxTmlJc0ltdHBaQ0k2IC4uLiIsIklrSllkbVp5Ykc1b1FVMTFTRkl3TjJGcVZXMUIgLi4uIl19.eyJpc3MiOiJodHRwczovL3BpZHByb3ZpZGVyLmV4YW1wbGUub3JnIiwic3ViIjoiTnpiTHNYaDh1RENjZDdub1dYRlpBZkhreFpzUkdDOVhzLi4uIiwianRpIjoidXJuOnV1aWQ6NmM1YzBhNDktYjU4OS00MzFkLWJhZTctMjE5MTIyYTllYzJjIiwiaWF0IjoxNTQxNDkzNzI0LCJleHAiOjE1NDE0OTM3MjQsInN0YXR1cyI6Imh0dHBzOi8vcGlkcHJvdmlkZXIuZXhhbXBsZS5vcmcvc3RhdHVzIiwiY25mIjp7Imp3ayI6eyJrdHkiOiJSU0EiLCJ1c2UiOiJzaWciLCJuIjoiMVRhLXNFIOKApiIsImUiOiJBUUFCIiwia2lkIjoiWWhORlMzWW5DOXRqaUNhaXZoV0xWVUozQXh3R0d6Xzk4dVJGYXFNRUVzIn19LCJ0eXBlIjoiUGVyc29uSWRlbnRpZmljYXRpb25EYXRhIiwidmVyaWZpZWRfY2xhaW1zIjp7InZlcmlmaWNhdGlvbiI6eyJfc2QiOlsiT0dtN3J5WGd0NVh6bGV2cC1IdS1VVGswYS1UeEFhUEFvYnF2MXBJV01mdyJdLCJ0cnVzdF9mcmFtZXdvcmsiOiJlaWRhcyIsImFzc3VyYW5jZV9sZXZlbCI6ImhpZ2gifSwiY2xhaW1zIjp7Il9zZCI6WyI4SmpvekJmb3ZNTnZRM0hmbG1QV3k0TzE5R3B4czYxRldIalplYlU1ODlFIiwiQm9NR2t0VzFyYmlrbnR3OEZ6eF9CZUw0WWJBbmRyNkFIc2RncGF0RkNpZyIsIkNGTEd6ZW50R05SRm5nbkxWVlFWY29BRmkwNXI2UkpVWC1yZGJMZEVmZXciLCJKVV9zVGFIQ25nUzMyWC0wYWpIcmQxLUhDTENrcFQ1WXFnY2ZRbWUxNjh3IiwiVlFJLVMxbVQxS3hmcTJvOEo5aW83eE1NWDJNSXhhRzlNOVBlSlZxck1jQSIsInpWZGdoY21DbE1WV2xVZ0dzR3BTa0NQa0VIWjR1OW9XajFTbElCbENjMW8iXX19LCJfc2RfYWxnIjoic2hhLTI1NiJ9.WzEiFaOjnobQisjTQ92JtKEXRN-2Sgvjklpu4IdC_cT2T6Tm8Z6sqbVy6n94AAEv-HFSv5JoSt6YjPDnGzOxN_W_131rILU8YaiNt8w31nRGIvHjJIC0w-hHIcG1LmvJshSMcT3RHeApRCmsO7xkHWmUsjt37dOzEagEti5i47hnZAbu7vWXsvUlBNNN8v7tJBLspO2Q0vnWhEDX1hQ7IH1b8oKh-_aQrhwVm9Bcs9CG8o6N9iqubCSpFI6Gty4ZZgHEb95knETVhw8IL10Z9P_Hr9twXZQaCCC8xrNh4afwR9TiDQzTr92m7luyvDfmzVgHCponI7VBhqmRqZVYQyDhq6EJbtRtIsYenla5NSKBjV8Etdlec94vJAHZNzue9aNUQeXae55V5m5O9wLoWhgV2vl4xV5C-N5s5Uzs08GAxo-CUaNOD3BQE9vfrT47IBCm4hUCnvDise_aWNCeKOQABV1J9_tV9lWZsECVuUuWWwELHCUXgdyiA3QtUtXz + eyJ0eXAiOiJ2YytzZC1qd3QiLCJhbGciOiJSUzUxMiIsImtpZCI6ImQxMjZhNmE4NTZmNzcyNDU2MDQ4NGZhOWRjNTlkMTk1IiwidHJ1c3RfY2hhaW4iOlsiTkVoUmRFUnBZbmxIWTNNNVdsZFdUV1oyYVVobSAuLi4iLCJleUpoYkdjaU9pSlNVekkxTmlJc0ltdHBaQ0k2IC4uLiIsIklrSllkbVp5Ykc1b1FVMTFTRkl3TjJGcVZXMUIgLi4uIl19.eyJpc3MiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLm9yZyIsInN1YiI6Ik56YkxzWGg4dURDY2Q3bm9XWEZaQWZIa3hac1JHQzlYcy4uLiIsImp0aSI6InVybjp1dWlkOjZjNWMwYTQ5LWI1ODktNDMxZC1iYWU3LTIxOTEyMmE5ZWMyYyIsImlhdCI6MTU0MTQ5MzcyNCwiZXhwIjoxNTQxNDkzNzI0LCJzdGF0dXMiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLm9yZy9zdGF0dXMiLCJjbmYiOnsiandrIjp7Imt0eSI6IlJTQSIsInVzZSI6InNpZyIsIm4iOiIxVGEtc0Ug4oCmIiwiZSI6IkFRQUIiLCJraWQiOiJZaE5GUzNZbkM5dGppQ2FpdmhXTFZVSjNBeHdHR3pfOTh1UkZhcU1FRXMifX0sInR5cGUiOiJIZWFsdGhJbnN1cmFuY2VEYXRhIiwidmVyaWZpZWRfY2xhaW1zIjp7InZlcmlmaWNhdGlvbiI6eyJfc2QiOlsiMmpJUjE4Z2ZlQVNIWUdCMjdzN3NTM1NfaVE0eHhGSXhDUnlpb2hyQmZucyJdLCJ0cnVzdF9mcmFtZXdvcmsiOiJlaWRhczIiLCJhc3N1cmFuY2VfbGV2ZWwiOiJoaWdoIn0sImNsYWltcyI6eyJfc2QiOlsiMWl6dHE3Ym92NjR4VFliRGtXRmM0NF9WaldlMDI5aFpxWGVVSWxvcVVONCIsIkVOTm8zMWpmekZwOFkyRFcwUi1mSU1lV3dlN0VMR3ZHb0hNd01CcHUxNEUiLCJGVjJDRE5XdVRxVGdPSGFmdHZWYXVtQkYwT2xtbnl4TXN3eWY0dUl4cmhZIiwiZFpXanE3bUpTU1gtWFRJX0hXdUU4QjJ4NklkTTVsRS1kb0RfeUJwS0phbyIsImdIWWkxOWZyYkRfaTRCb2FXRU5PamMzbENuTWo0cGJHTlFjc0JqX1FNNFEiXX19LCJfc2RfYWxnIjoic2hhLTI1NiJ9.Dy8IdMBmzL5QSxAHiYTv9Fg0HhiI-AFIwL2slNEVI5iTxcne0reX2w-Bo78bY0UkOF5LHBLjGV_l5wbX6pvDY0v193ifp7KzJIpj2jUuQ-XR7RHng9RFdjKSj7urVYaseQxKA97vWcJxNX7bYKLQ6jKOdxl0CXmFdg00HTA1MnO7OPWdRiT7BlDyl0HfwQ-X08Yk23zX2Po90p1pBIWMlqnkfeZwQIWyz6LvFcK7OClEYlmzhtLR5QmYHbIbu9oGhn00hv0Q94TcheGpSm8WmfUjE-dV6YvfWtkcsTg7bjmawt6B4W_YMwV9pSmoC1euwO1svoyAdqxjGbInmLT4hA MDOC-CBOR ========= From ea8026be4a03da116fec4ffff4b27d3f36c09db2 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Fri, 14 Jul 2023 15:27:20 +0200 Subject: [PATCH 05/39] chore: typo --- docs/en/pid-eaa-data-model.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index 2733b5188..c09abd7b9 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -121,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 contain the information as sub claims regarding the identity proofing evidence during the issuing phase of the PID. Some of these additional claims MAY be included in the Disclosures and MAY be selectively disclosed and they are given in the following tables that also specify whether a claim is selectively disclosable (SD) or not (NSD). +The ``verification`` claim contain the information, as sub claims, regarding the identity trust framework used by the PID/(Q)EAA Issuer to provide a verified User claims. Some of these additional claims MAY be included in the Disclosures and MAY be selectively disclosed and they are given in the following tables that also 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. @@ -167,7 +167,7 @@ The ``record`` MUST have at least the following sub parameters: - `[OID.IDA. Section 5.1.1.2] `_ .. warning:: - Note that the sub-claims of the **evidence** parameter are not selectively disclosable separately, thus, for example, the User cannot give only the *record type* without disclosure the *record source* (organization name, identifier and country that hendles the User identity proofing). + Note that the sub-claims of the **evidence** parameter are not selectively disclosable separately, thus, for example, the User cannot give only the *record type* without disclosure the *record source* (organization name, identifier and country). PID Claims field ---------------- From 548874d3afbc726290580424a211f946947fc21c Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Fri, 14 Jul 2023 15:45:12 +0200 Subject: [PATCH 06/39] chore: fix PID VC type --- docs/en/pid-eaa-issuance.rst | 15 ++++++--------- 1 file changed, 6 insertions(+), 9 deletions(-) diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst index 15804e3ec..909ffaeb0 100644 --- a/docs/en/pid-eaa-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -137,7 +137,7 @@ The JWS payload of the request object is represented below: "type":"openid_credential", "format": "vc+sd-jwt", "credential_definition": { - "type": ["eu.eudiw.pid.it"] + "type": ["PersonIdentificationData"] } } ], @@ -255,7 +255,7 @@ The JWS payload of the request object is represented below: c05yV0JiMHhXWG9hTnk1OUlpS0NBcWtzbVFFbyJ9.2oW9RP35yRqzhrtNP86L-Ey71E OptxRimPPToA1plemAgR6pxHF8y6-yqyVnmcw6Fy1dqd-jfxSYoMxhAJpLjA - credential_definition=%7B%22type%22:%5B%22eu.eudiw.pid.it%22%5D%7D + credential_definition=%7B%22type%22:%5B%22PersonIdentificationData%22%5D%7D &format=vc+sd-jwt &proof=%7B%22proof_type%22:%22...-ace0-9c5210e16c32%22%7D @@ -411,7 +411,7 @@ The JWT payload is given by the following parameters: - **type**: it MUST be set to ``openid_credential``, - **format**: it MUST be set to ``vc+sd-jwt``, - - **credential_definition**: JSON Object. It MUST have the **type** claim which MUST be set in accordance to the type of the requested PID/(Q)EAA that is obtained from the PID/(Q)EAA Issuer metadata. For example, in the case of the PID, it MUST be set to ``eu.eudiw.pid.it`` + - **credential_definition**: JSON Object. It MUST have the **type** claim which MUST be set in accordance to the type of the requested PID/(Q)EAA that is obtained from the PID/(Q)EAA Issuer metadata. For example, in the case of the PID, it MUST be set to ``PersonIdentificationData`` - See [RAR :rfc:`9396`] and `[OIDC4VCI. Draft 13] `_. * - **redirect_uri** - Redirection URI to which the response will be sent. It MUST be an universal or app link registered with the local operating system, so this latter will resolve it and pass the response to the Wallet Instance. @@ -657,9 +657,6 @@ A DPoP-bound Access Token is provided by the PID/(Q)EAA Token endpoint as a resu * - **jti** - It MUST be a String in *uuid4* format. Unique Token ID identifier that the RP MAY use to prevent reuse by rejecting the Token ID if already processed. - [:rfc:`9068`], [:rfc:`7519`]. - * - **nonce** [FIXME] - - It MUST be a random string of at least 32 alphanumeric characters. The value type of this claim MUST be a string, where the value is a **c_nonce** provided by the PID/(Q)EAA Issuer. - - [`OpenID.Core#AuthRequest `_]. * - **jkt** - JWK SHA-256 Thumbprint Confirmation Method. The value of the jkt member MUST be the base64url encoding (as defined in [RFC7515]) of the JWK SHA-256 Thumbprint of the DPoP public key (in JWK format) to which the access token is bound. - [`DPoP-draft16 `_. Section 6.1] and [:rfc:`7638`]. @@ -693,7 +690,7 @@ If the *DPoP proof* is invalid, the Credential endpoint returns an error respons - **Description** - **Reference** * - **credential_definition** - - JSON object containing the detailed description of the credential type. It MUST have at least the **type** sub claims which is a JSON array containing the type values the Wallet shall request in the subsequent Credential Request. It MUST be set in accordance to the type of the requested PID/(Q)EAA that is obtained from the PID/(Q)EAA Issuer metadata. For example, in the case of the PID, it MUST be set to `eu.eudiw.pid.it`. + - JSON object containing the detailed description of the credential type. It MUST have at least the **type** sub claims which is a JSON array containing the type values the Wallet shall request in the subsequent Credential Request. It MUST be set in accordance to the type of the requested PID/(Q)EAA that is obtained from the PID/(Q)EAA Issuer metadata. For example, in the case of the PID, it MUST be set to ``PersonIdentificationData``. - `[OIDC4VCI. Draft 13] `_. * - **format** - Format of the Credential to be issued. This MUST be `vc+sd-jwt`. @@ -767,7 +764,7 @@ Credential Response to the Wallet Instance MUST be sent using `application/json` - Format of the Credential to be issued. This MUST be `vc+sd-jwt`. - `[OIDC4VCI. Draft 13] `_. * - **credential** - - Contains the issued PID. It MUST be an SD-JWT JSON Object (see Section :ref:`PID Data Model `). + - Contains the issued PID/(Q)EAA. It MUST be an SD-JWT JSON Object (see Section :ref:`PID/(Q)EAA Data Model `). - Appendix E in `[OIDC4VCI. Draft 13] `_. * - **c_nonce** - JSON string containing a nonce to be used to create a *proof of possession* of key material when requesting a further credential or for renewal credential. @@ -850,7 +847,7 @@ Below a non-normative example of an Entity Configuration containing an `openid_c } ], "credential_definition": { - "type": ["PIDCredential"], + "type": ["PersonIdentificationData"], "credentialSubject": { "given_name": { "mandatory": true, From 24a73db3a41b645d4fabbf7ee71daac96dc1a8c5 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Fri, 14 Jul 2023 17:19:47 +0200 Subject: [PATCH 07/39] chore: fix typo --- docs/en/pid-eaa-data-model.rst | 2 +- docs/en/pid-eaa-issuance.rst | 19 +++++++++---------- 2 files changed, 10 insertions(+), 11 deletions(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index c09abd7b9..d688cf982 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -19,7 +19,7 @@ The User attributes carried in the Italian PID are: The italian PID is extended according to the `OpenID Identity Assurance Profile [OIDC.IDA] `_, that enables the binding of the PID to a national trust framework, giving all the evidence of the identity proofing procedures underlying the PID issuing in both remote and proximity flows. -The (Q)EAAs are issued by the (Q)EAA Issuers to a Wallet Instance and MUST be provided in SD-JWT-VC or mDOC CBOR data format. They MAY contain any (qualified) attributes, entitlement or any elettronic attestation. +The (Q)EAAs are issued by the (Q)EAA Issuers to a Wallet Instance and MUST be provided in SD-JWT-VC or mDOC CBOR data format. They MAY contain any (qualified) attributes, entitlement or any elettronic attestations. The italian (Q)EAAs are extended according to the `OpenID Identity Assurance Profile [OIDC.IDA] `_, that allows the recipients to know the Authentic Sources where the data are taken. diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst index 909ffaeb0..ebc8674c8 100644 --- a/docs/en/pid-eaa-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -94,7 +94,7 @@ The PID/(Q)EAA Issuance phase is based on the **Authorization Code Flow** with * **Federation Check:** The Wallet Instance needs to check if the PID/(Q)EAA Issuer is part of Federation and then it can consume its Metadata. A non-normative example of a response from the endpoint **.well-known/openid-federation** with the **Entity Configuration** and the **Metadata** of the PID/(Q)EAA Issuer is represented within the section `Entity Configuration Credential Issuer`_. -**Steps 5-6 (PAR Request):** The Wallet Instance creates a PKCE code verifier that sends in a *pushed authorization request*, using the request parameter (see :rfc:`9126` Section 3) to the PID/(Q)EAA Issuer authorization endpoint. The Wallet Instance signs the request using its private key. A OAuth2 client authentication method must be involved, since in this flow the pushed authorization endpoint is a protected endpoint. The client authentication is based on the model defined in [:rfc:`7521`] using the Wallet Instance Attestation JWS inside the **client_assertion** parameter. The authorization_details [RAR :rfc:`9396`] parameter is extended to allow Wallet Instance to specify the types of the credentials when requesting authorization for the PID/(Q)EAA issuance. +**Steps 5-6 (PAR Request):** The Wallet Instance creates a PKCE code verifier that sends in a *pushed authorization request*, using the request parameter (see :rfc:`9126` Section 3) to the PID/(Q)EAA Issuer PAR endpoint. The Wallet Instance signs the request using its private key. A OAuth2 client authentication method MUST be involved, since in this flow the pushed authorization endpoint is a protected endpoint. The client authentication is based on the model defined in [:rfc:`7521`] using the Wallet Instance Attestation JWS inside the **client_assertion** parameter. The authorization_details [RAR :rfc:`9396`] parameter is extended to allow Wallet Instance to specify the types of the credentials when requesting authorization for the PID/(Q)EAA issuance. Below a non-normative example of the PAR. @@ -177,7 +177,7 @@ The JWS payload of the request object is represented below: .. note:: **User Authentication and Consent:** The PID Provider performs the User authentication based on the requirements of eIDAS LoA High by means of national notified eIDAS scheme and asks the User consent for the PID issuance. - The (Q)EAA Issuer performs the User authentication requesting a valid PID to the Wallet Instance. The (Q)EAA Issuer MUST use [`OpenID4VP`_] to dynamically request presentation of the PID. From a protocol perspective, the Credential Issuer then acts as a verifier and sends a presentation request to the Wallet Instance. The Wallet Instance MUST have these Credentials obtained prior to starting a transaction with the (Q)EAA Issuer. + The (Q)EAA Issuer performs the User authentication requesting a valid PID to the Wallet Instance. The (Q)EAA Issuer MUST use [`OpenID4VP`_] to dynamically request presentation of the PID. From a protocol perspective, the Credential Issuer then acts as a verifier and sends a presentation request to the Wallet Instance. The Wallet Instance MUST have a valid PID obtained prior to starting a transaction with the (Q)EAA Issuer. **Steps 10-11 (Authorization Response):** The PID/(Q)EAA Issuer sends an authorization code to the Wallet Instance. @@ -190,6 +190,7 @@ The JWS payload of the request object is represented below: HTTP/1.1 302 Found Location: eudiw://start.wallet.example.org?code=SplxlOBeZQQYbYS6WxSbIA&state=fyZiOL9Lf2CeKuNT2JzxiLRDink0uPcd&iss=https%3A%2F%2Fpid-provider.example.org +**Steps 12-13 (DPoP Proof for Token Endpoint)**: The Wallet Instance creates a key for DPoP and a fresh DPoP proof for the token request to the PID/(Q)EAA Issuer. DPoP provides a way to bind the access token to a certain sender (Wallet Instance) `[DPoP-draft16] `_. Thus, it mitigates the misuse of leaked or stolen Access Tokens at the Credential Endpoint of PID/(Q)EAA Issuer as the attacker needs to present a valid DPoP proof. **Step 14 (Token Request):** The Wallet Instance sends a token request to the PID/(Q)EAA Issuer token endpoint using the authorization *code*, *code_verifier*, *DPoP proof* and *private_key_jwt*. @@ -232,7 +233,7 @@ The JWS payload of the request object is represented below: } -**Steps 16-18 (DPoP Proof):** The Wallet Instance creates a new key pair to which the new credential shall be bound. Then, it creates a proof of possession with the new key and the *c_nonce* obtained in **Step 15** and it creates a DPoP proof for the request to the PID/(Q)EAA credential issuance endpoint. +**Steps 16-18 (DPoP Proof for Credential Endpoint):** The Wallet Instance creates a new key pair to which the new credential shall be bound. Then, it creates a proof of possession with the new key and the *c_nonce* obtained in **Step 15** and it creates a DPoP proof for the request to the PID/(Q)EAA credential issuance endpoint. **Step 19 (Credential Request):** The Wallet Instance sends a PID/(Q)EAA issuance request to the PID/(Q)EAA credential endpoint. It contains the *access token*, the *DPoP proof*, the *credential type*, the *proof* (proof of possession of the key) and the *format*. @@ -388,9 +389,6 @@ The JWT payload is given by the following parameters: * - **iat** - UNIX Timestamp with the time of JWT issuance, coded as NumericDate. - :rfc:`9126` and :rfc:`7519`. - * - **jti** [FIXME] - - Unique identifier of the JWT. The value MUST be assigned in a UUID v4 string format according to [:rfc:`4122`]. - - :rfc:`9126` and :rfc:`7519`. * - **response_type** - It MUST be set as in the :ref:`Table of the HTTP parameters `. - See :ref:`Table of the HTTP parameters `. @@ -640,7 +638,7 @@ A DPoP-bound Access Token is provided by the PID/(Q)EAA Token endpoint as a resu - It MUST be an HTTPS URL that uniquely identifies the PID/(Q)EAA Issuer. The Wallet Instance MUST verify that this value matches the PID/(Q)EAA Issuer where it has requested the credential. - [:rfc:`9068`], `[RFC7519, Section 4.1.1] `_. * - **sub** - - It identifies the subject of the JWT. It MUST be of type *pairwise*. + - It identifies the principal that is the subject of the JWT. It MUST be set to the value of the ``sub`` field in the PID/(Q)EAA SD-JWT-VC. - [:rfc:`9068`], [:rfc:`7519`] and [`OpenID.Core#SubjectIDTypes `_]. * - **client_id** - MUST be set to the *jwk* value in the *cnf* parameter inside the Wallet Instance Attestation. @@ -820,9 +818,10 @@ Below a non-normative example of an Entity Configuration containing an `openid_c "pushed_authorization_request_endpoint": "https://pid-provider.example.org/connect/par", "dpop_signing_alg_values_supported": ["RS256", "RS512", "ES256", "ES512"], "credential_endpoint": "https://pid-provider.example.org/credential", - "credentials_supported": [{ - "eu.eudiw.pid.it": { + "credentials_supported": [ + { "format": "vc+sd-jwt", + "id": "eu.eudiw.pid.it", "cryptographic_binding_methods_supported": ["jwk"], "cryptographic_suites_supported": ["RS256", "RS512", "ES256", "ES512"], "display": [{ @@ -924,7 +923,7 @@ Below a non-normative example of an Entity Configuration containing an `openid_c } } } - }] + ] }, "federation_entity": { From 5435327d223cbb1ea498bbab73e5acdf95de2fc6 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Fri, 14 Jul 2023 19:02:07 +0200 Subject: [PATCH 08/39] chore: editorial fix --- docs/en/pid-eaa-data-model.rst | 4 ++-- docs/en/pid-eaa-issuance.rst | 16 ++++++++-------- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index d688cf982..629c6288b 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -121,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 contain the information, as sub claims, regarding the identity trust framework used by the PID/(Q)EAA Issuer to provide a verified User claims. Some of these additional claims MAY be included in the Disclosures and MAY be selectively disclosed and they are given in the following tables that also specify whether a claim is selectively disclosable (SD) or not (NSD). +The ``verification`` claim contains the information, as sub claims, regarding the identity trust framework used by the PID/(Q)EAA Issuer to provide a verified User claims. Some of these additional claims MAY be included in the Disclosures and MAY be selectively disclosed and they are given in the following tables that also 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. @@ -136,7 +136,7 @@ The ``verification`` claim is a JSON structure with all the following mandatory - [NSD]. For PID credential it MUST be set to ``eidas``. For (Q)EAA it MUST be set to ``eidas2``. - `[OID.IDA. Section 5.1] `_ * - **assurance_level** - - [NSD]. MUST be set according to the LoA. For PID credential it MUST be set o ``high``. + - [NSD]. MUST be set according to the LoA required. For PID credential it MUST be set to ``high``. - `[OID.IDA. Section 5.1] `_ * - **evidence** - [SD]. JSON Array. Each element is the electronic evidence of the user identification during the PID issuing phase or, in case of (Q)EAA, it represents the evidence of the Authentic Sources that ensure the authenticity of the data conveyed by the (Q)EAA. It MUST contain at least the following claims: diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst index ebc8674c8..d0f8d93f8 100644 --- a/docs/en/pid-eaa-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -5,7 +5,7 @@ PID/(Q)EAA Issuance +++++++++++++++++++ -This section describes the issuance flow for the PID and (Q)EAAs that require an high security implementation profile. +This section describes the issuance flow for the PID and (Q)EAAs that require a high security implementation profile. The relevant entities and interfaces involved in the issuance flow are: - *Wallet Provider*: It represents an organization (public or private) that is responsible for the release of an eIDAS-compliant EUDI Wallet Solution. It also issues thes Wallet Instance Attestation to its Wallet Instances by means of an Attestation Service. The Wallet Attestation certifies the genuinity and authenticity of the Wallet Instance and its compliance with a Trust Framework in compliance to the security and privacy requirements. @@ -16,10 +16,10 @@ The relevant entities and interfaces involved in the issuance flow are: - OpenID4VCI Component: based on the “OpenID for Verifiable Credential Issuance” specification `[OIDC4VCI. Draft 13] `_ to release PID credentials. - National eID Relying Party (OpenID Connect or SAML2): It represents the component to authenticate the End-User with the national Digital Identity Providers. - National IdP: 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 `_). - - *Credential Issuer*: It represents the issuer of (Q)EAAs. It is composed of: + - *(Q)EAA Issuer*: 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] `_ to release (Q)EAAs. - - Relying Party: It represents the component to authenticate the End-User with the PID. + - Relying Party: It represents the component to authenticate the End-User with the PID. The (Q)EAA Issuer then acts as a verifier and 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 Issuer. High-Level PID flow @@ -51,7 +51,7 @@ High-Level (Q)EAA flow The :numref:`fig_High-Level-Flow-ITWallet-QEAA-Issuance` shows a general architecture and highlights the main operations involved in the issuance of a (Q)EAA, under the main following assumptions: - the User has a valid PID stored in its own Wallet Instance; - - the (Q)EAA requires an high security implementation profile. + - the (Q)EAA requires a high security implementation profile. .. _fig_High-Level-Flow-ITWallet-QEAA-Issuance: .. figure:: ../../images/High-Level-Flow-ITWallet-QEAA-Issuance.svg @@ -65,8 +65,8 @@ In the following the main operations are detailed: 1. **Obtaining the trusted (Q)EAA Issuer**: the Wallet Instance queries the Trust Anchor to fetch the trusted (Q)EAA Issuer. 2. **Obtaining of (Q)EAA Issuer metadata**: the Wallet Instance establishes the trust to the (Q)EAA Issuer according to the Trust Model, obtaining the Metadata that discloses the formats of the (Q)EAA, the algorithms supported, and any other parameter required for interoperability needs. 3. **(Q)EAA request**: following the Authorization Code Flow in `[OIDC4VCI. Draft 13] `_ the Wallet Instance requests a (Q)EAA to the (Q)EAA Issuer. A fresh key pairs is generated by the Wallet Instance, the public key is used by (Q)EAA Issuer for the key binding of the (Q)EAA. The (Q)EAA Issuer checks the Wallet Instance by means of the Wallet Attestation and the Trust Chain related to the Wallet Provider - 4. **End-user authentication**: the (Q)EAA Issuer authenticates the End-User with the PID owned by the User, acting as a Wallet Verifier (Relying Party). - 5. **(Q)EAA issuance**: once the User authentication with a valid PID happens, the User gives their consent, and the (Q)EAA Issuer releases a (Q)EAA bound to the key material held by the requesting Wallet instance. + 4. **End-user authentication**: the (Q)EAA Issuer authenticates the End-User with the PID owned by the User, acting as a verifier (Relying Party). + 5. **(Q)EAA issuance**: once the User authentication with a valid PID happens, the User gives their consent, and the (Q)EAA Issuer releases a (Q)EAA bound to the key material held by the requesting Wallet Instance. @@ -177,7 +177,7 @@ The JWS payload of the request object is represented below: .. note:: **User Authentication and Consent:** The PID Provider performs the User authentication based on the requirements of eIDAS LoA High by means of national notified eIDAS scheme and asks the User consent for the PID issuance. - The (Q)EAA Issuer performs the User authentication requesting a valid PID to the Wallet Instance. The (Q)EAA Issuer MUST use [`OpenID4VP`_] to dynamically request presentation of the PID. From a protocol perspective, the Credential Issuer then acts as a verifier and sends a presentation request to the Wallet Instance. The Wallet Instance MUST have a valid PID obtained prior to starting a transaction with the (Q)EAA Issuer. + The (Q)EAA Issuer performs the User authentication requesting a valid PID to the Wallet Instance. The (Q)EAA Issuer MUST use [`OpenID4VP`_] to dynamically request presentation of the PID. From a protocol perspective, the (Q)EAA Issuer then acts as a verifier and sends a presentation request to the Wallet Instance. The Wallet Instance MUST have a valid PID obtained prior to starting a transaction with the (Q)EAA Issuer. **Steps 10-11 (Authorization Response):** The PID/(Q)EAA Issuer sends an authorization code to the Wallet Instance. @@ -405,7 +405,7 @@ The JWT payload is given by the following parameters: - It MUST be set as in the :ref:`Table of the HTTP parameters `. - See :ref:`Table of the HTTP parameters `. * - **authorization_details** - - JSON Object. It MUST include the following claims: + - Array of JSON Object. Each JSON Object MUST include the following claims: - **type**: it MUST be set to ``openid_credential``, - **format**: it MUST be set to ``vc+sd-jwt``, From 8f60a78f2ce2990248d053ef6b03b7d4848c7015 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 17 Jul 2023 10:46:00 +0200 Subject: [PATCH 09/39] Apply suggestions from code review Co-authored-by: Giuseppe De Marco --- docs/en/pid-eaa-issuance.rst | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst index d0f8d93f8..5732c2e5a 100644 --- a/docs/en/pid-eaa-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -19,7 +19,7 @@ The relevant entities and interfaces involved in the issuance flow are: - *(Q)EAA Issuer*: 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] `_ to release (Q)EAAs. - - Relying Party: It represents the component to authenticate the End-User with the PID. The (Q)EAA Issuer then acts as a verifier and 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 Issuer. + - Relying Party: It represents the component to authenticate the User with the PID. The (Q)EAA Issuer 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 Issuer. High-Level PID flow @@ -34,14 +34,14 @@ The :numref:`fig_High-Level-Flow-ITWallet-PID-Issuance` shows a general architec PID Issuance - General architecture and high level flow -In the following the main operations are detailed: +Below a detailed description for each step represented in the previous picture: 0. **Wallet Instance Setup**: the first time the Wallet Instance is started a preliminary setup phase MUST be carried out. It consists of the release of a verifiable proof issued by the Attestation Service provided by the Wallet Provider that asserts the genuineness, the authenticity and the compliance with a trust framework of the Wallet Instance. The verifiable proof binds a public key corresponding to a local private key generated by the Wallet Instance. 1. **Obtaining the trusted PID Provider**: the Wallet Instance queries the Trust Anchor to fetch the trusted PID Provider. 2. **Obtaining of PID Provider metadata**: the Wallet Instance establishes the trust to the PID Provider according to the Trust Model, obtaining the Metadata that discloses the formats of the PID, the algorithms supported, and any other parameter required for interoperability needs. 3. **PID request**: following the Authorization Code Flow in `[OIDC4VCI. Draft 13] `_ the Wallet Instance requests a PID to the PID Provider. A fresh key pairs is generated by the Wallet Instance, the public key is used by PID Provider for the key binding of the PID. The PID Provider checks the Wallet Instance by means of the Wallet Attestation and the Trust Chain related to the Wallet Provider 4. **End-user authentication**: the PID Provider authenticates the End-User with LoA High, acting as an IAM Proxy to the National eID system. - 5. **PID issuance**: once the User authentication with LoA High happens, the User gives their consent, and the PID Provider releases a PID bound to the key material held by the requesting Wallet instance. + 5. **PID issuance**: once the User authentication with LoA High happens, the User gives their consent, and the PID Provider releases a PID bound to the key material held by the requesting Wallet Instance. The Wallet Instance Setup phase is described in Section [...]. In the following Section the steps from 1 to 5 are further expanded into more technical detailed steps. @@ -60,12 +60,12 @@ The :numref:`fig_High-Level-Flow-ITWallet-QEAA-Issuance` shows a general archite (Q)EAA Issuance - General architecture and high level flow -In the following the main operations are detailed: +Below the description of the most relevant operations involved in the (Q)EAA issuance: 1. **Obtaining the trusted (Q)EAA Issuer**: the Wallet Instance queries the Trust Anchor to fetch the trusted (Q)EAA Issuer. 2. **Obtaining of (Q)EAA Issuer metadata**: the Wallet Instance establishes the trust to the (Q)EAA Issuer according to the Trust Model, obtaining the Metadata that discloses the formats of the (Q)EAA, the algorithms supported, and any other parameter required for interoperability needs. 3. **(Q)EAA request**: following the Authorization Code Flow in `[OIDC4VCI. Draft 13] `_ the Wallet Instance requests a (Q)EAA to the (Q)EAA Issuer. A fresh key pairs is generated by the Wallet Instance, the public key is used by (Q)EAA Issuer for the key binding of the (Q)EAA. The (Q)EAA Issuer checks the Wallet Instance by means of the Wallet Attestation and the Trust Chain related to the Wallet Provider - 4. **End-user authentication**: the (Q)EAA Issuer authenticates the End-User with the PID owned by the User, acting as a verifier (Relying Party). + 4. **End-user authentication**: the (Q)EAA Issuer authenticates the User with the PID owned by the User, acting as a verifier (Relying Party). 5. **(Q)EAA issuance**: once the User authentication with a valid PID happens, the User gives their consent, and the (Q)EAA Issuer releases a (Q)EAA bound to the key material held by the requesting Wallet Instance. @@ -87,11 +87,11 @@ The PID/(Q)EAA Issuance phase is based on the **Authorization Code Flow** with * PID/(Q)EAA Issuance - Detailed flow -**Steps 1-4 (Discovery):** The User has selected a PID/(Q)EAA Issuer, and the Wallet Instance obtains the metadata for the selected PID/(Q)EAA Issuer. +**Steps 1-4 (Discovery):** The User selects the PID/(Q)EAA Issuer, and the Wallet Instance obtains the metadata for the selected PID/(Q)EAA Issuer. .. note:: - **Federation Check:** The Wallet Instance needs to check if the PID/(Q)EAA Issuer is part of Federation and then it can consume its Metadata. A non-normative example of a response from the endpoint **.well-known/openid-federation** with the **Entity Configuration** and the **Metadata** of the PID/(Q)EAA Issuer is represented within the section `Entity Configuration Credential Issuer`_. + **Federation Check:** The Wallet Instance needs to check if the PID/(Q)EAA Issuer is part of Federation, obtaining then its protocol specific metadata. A non-normative example of a response from the endpoint **.well-known/openid-federation** with the **Entity Configuration** and the **Metadata** of the PID/(Q)EAA Issuer is represented within the section `Entity Configuration Credential Issuer`_. **Steps 5-6 (PAR Request):** The Wallet Instance creates a PKCE code verifier that sends in a *pushed authorization request*, using the request parameter (see :rfc:`9126` Section 3) to the PID/(Q)EAA Issuer PAR endpoint. The Wallet Instance signs the request using its private key. A OAuth2 client authentication method MUST be involved, since in this flow the pushed authorization endpoint is a protected endpoint. The client authentication is based on the model defined in [:rfc:`7521`] using the Wallet Instance Attestation JWS inside the **client_assertion** parameter. The authorization_details [RAR :rfc:`9396`] parameter is extended to allow Wallet Instance to specify the types of the credentials when requesting authorization for the PID/(Q)EAA issuance. @@ -176,7 +176,7 @@ The JWS payload of the request object is represented below: .. note:: - **User Authentication and Consent:** The PID Provider performs the User authentication based on the requirements of eIDAS LoA High by means of national notified eIDAS scheme and asks the User consent for the PID issuance. + **User Authentication and Consent:** The PID Provider performs the User authentication based on the requirements of eIDAS LoA High by means of national notified eIDAS scheme and requires the User consent for the PID issuance. The (Q)EAA Issuer performs the User authentication requesting a valid PID to the Wallet Instance. The (Q)EAA Issuer MUST use [`OpenID4VP`_] to dynamically request presentation of the PID. From a protocol perspective, the (Q)EAA Issuer then acts as a verifier and sends a presentation request to the Wallet Instance. The Wallet Instance MUST have a valid PID obtained prior to starting a transaction with the (Q)EAA Issuer. **Steps 10-11 (Authorization Response):** The PID/(Q)EAA Issuer sends an authorization code to the Wallet Instance. @@ -190,7 +190,7 @@ The JWS payload of the request object is represented below: HTTP/1.1 302 Found Location: eudiw://start.wallet.example.org?code=SplxlOBeZQQYbYS6WxSbIA&state=fyZiOL9Lf2CeKuNT2JzxiLRDink0uPcd&iss=https%3A%2F%2Fpid-provider.example.org -**Steps 12-13 (DPoP Proof for Token Endpoint)**: The Wallet Instance creates a key for DPoP and a fresh DPoP proof for the token request to the PID/(Q)EAA Issuer. DPoP provides a way to bind the access token to a certain sender (Wallet Instance) `[DPoP-draft16] `_. Thus, it mitigates the misuse of leaked or stolen Access Tokens at the Credential Endpoint of PID/(Q)EAA Issuer as the attacker needs to present a valid DPoP proof. +**Steps 12-13 (DPoP Proof for Token Endpoint)**: The Wallet Instance creates a key for DPoP and a fresh DPoP proof for the token request to the PID/(Q)EAA Issuer. DPoP provides a way to bind the access token to a certain sender (Wallet Instance) `[DPoP-draft16] `_. This mitigates the misuse of leaked or stolen Access Tokens at the Credential Endpoint of PID/(Q)EAA Issuer as the attacker needs to present a valid DPoP proof. **Step 14 (Token Request):** The Wallet Instance sends a token request to the PID/(Q)EAA Issuer token endpoint using the authorization *code*, *code_verifier*, *DPoP proof* and *private_key_jwt*. @@ -233,7 +233,7 @@ The JWS payload of the request object is represented below: } -**Steps 16-18 (DPoP Proof for Credential Endpoint):** The Wallet Instance creates a new key pair to which the new credential shall be bound. Then, it creates a proof of possession with the new key and the *c_nonce* obtained in **Step 15** and it creates a DPoP proof for the request to the PID/(Q)EAA credential issuance endpoint. +**Steps 16-18 (DPoP Proof for Credential Endpoint):** The Wallet Instance creates a new key pair to which the new credential SHALL be bound. Then, it creates a proof of possession with the new key and the *c_nonce* obtained in **Step 15** and it creates a DPoP proof for the request to the PID/(Q)EAA credential issuance endpoint. **Step 19 (Credential Request):** The Wallet Instance sends a PID/(Q)EAA issuance request to the PID/(Q)EAA credential endpoint. It contains the *access token*, the *DPoP proof*, the *credential type*, the *proof* (proof of possession of the key) and the *format*. @@ -293,7 +293,7 @@ Where the decoded content of the JWT is represented below: -**Steps 20-22 (Credential Response):** The PID/(Q)EAA Issuer checks the *DPoP proof* and whether the *access token* is valid and suitable for the requested PID/(Q)EAA. It also checks the proof of possession for the key material the new credential shall be bound to. If all checks succeed, the PID/(Q)EAA Issuer creates a new credential bound to the key material and sends it to the Wallet Instance. The Wallet Instance MUST perform the PID/(Q)EAA integrity and authenticity checks and if it is successful can proceed with secure storage of the credential. +**Steps 20-22 (Credential Response):** The PID/(Q)EAA Issuer checks the *DPoP proof* and whether the *access token* is valid and suitable for the requested PID/(Q)EAA. It also checks the proof of possession for the key material the new credential SHALL be bound to. If all checks succeed, the PID/(Q)EAA Issuer creates a new credential bound to the key material and sends it to the Wallet Instance. The Wallet Instance MUST perform the PID/(Q)EAA integrity and authenticity checks before proceeding with the secure storage of the credential. .. code-block:: http @@ -384,10 +384,10 @@ The JWT payload is given by the following parameters: - It MUST be set to the identifier of the PID/(Q)EAA Issuer. - :rfc:`9126` and :rfc:`7519`. * - **exp** - - UNIX Timestamp with the expiry time of the JWT, coded as NumericDate. + - UNIX Timestamp with the expiry time of the JWT. - :rfc:`9126` and :rfc:`7519`. * - **iat** - - UNIX Timestamp with the time of JWT issuance, coded as NumericDate. + - UNIX Timestamp with the time of JWT issuance. - :rfc:`9126` and :rfc:`7519`. * - **response_type** - It MUST be set as in the :ref:`Table of the HTTP parameters `. @@ -405,7 +405,7 @@ The JWT payload is given by the following parameters: - It MUST be set as in the :ref:`Table of the HTTP parameters `. - See :ref:`Table of the HTTP parameters `. * - **authorization_details** - - Array of JSON Object. Each JSON Object MUST include the following claims: + - Array of JSON Objects. Each JSON Object MUST include the following claims: - **type**: it MUST be set to ``openid_credential``, - **format**: it MUST be set to ``vc+sd-jwt``, @@ -490,7 +490,7 @@ If the authentication is successful the PID/(Q)EAA Issuer redirects the User by - Unique *Authorization Code* that the Wallet Instance submits to the Token Endpoint. - [:rfc:`6749#section-4.1.2`], `Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants `_ * - **state** - - The Wallet Instance MUST check the correspondence with the state value in the request object. It is defined as in the :ref:`Table of the JWT Request parameters `. + - The Wallet Instance MUST check the correspondence with the ``state`` parameter value in the request object. It is defined as in the :ref:`Table of the JWT Request parameters `. - [:rfc:`6749#section-4.1.2`]. * - **iss** - Unique identifier of the PID/(Q)EAA Issuer who created the Authentication Response. The Wallet Instance MUST validate this parameter. @@ -508,9 +508,9 @@ defined in :rfc:`6749`. Token Request ^^^^^^^^^^^^^^^ -The request to the PID/(Q)EAA Token endpoint MUST be an HTTP request with method POST, where its body message is encoded in ``application/x-www-form-urlencoded`` format. The Wallet Instance sends the Token endpoint request with *private_key_jwt* authentication and a *DPoP proof* containing the mandatory parameters, defined in the table below. +The request to the PID/(Q)EAA Token endpoint MUST be an HTTP request with method POST, where its body message is encoded in ``application/x-www-form-urlencoded`` format. The Wallet Instance sends the Token endpoint request with *private_key_jwt* authentication and a *DPoP proof* containing the mandatory parameters, defined in the table below. -The Token endpoint MUST accept and validate the DPoP proof sent in the DPoP HTTP header. The Token endpoint MUST validate the DPoP proof based on the steps defined in Section 4.3 of the DPoP specifications `[DPoP-draft16] `_. Thus, this mitigates the misuse of leaked or stolen access tokens at the credential endpoint. If the DPoP proof is invalid, the Token endpoint returns an error response, according to Section 5.2 of [:rfc:`6749`] with ``invalid_dpop_proof`` as the value of the error parameter. +The Token endpoint MUST accept and validate the DPoP proof sent in the DPoP HTTP header. The Token endpoint MUST validate the DPoP proof according to Section 4.3 of the DPoP specifications `[DPoP-draft16] `_. Thus, this mitigates the misuse of leaked or stolen access tokens at the credential endpoint. If the DPoP proof is invalid, the Token endpoint returns an error response, according to Section 5.2 of [:rfc:`6749`] with ``invalid_dpop_proof`` as the value of the error parameter. .. list-table:: @@ -688,7 +688,7 @@ If the *DPoP proof* is invalid, the Credential endpoint returns an error respons - **Description** - **Reference** * - **credential_definition** - - JSON object containing the detailed description of the credential type. It MUST have at least the **type** sub claims which is a JSON array containing the type values the Wallet shall request in the subsequent Credential Request. It MUST be set in accordance to the type of the requested PID/(Q)EAA that is obtained from the PID/(Q)EAA Issuer metadata. For example, in the case of the PID, it MUST be set to ``PersonIdentificationData``. + - JSON object containing the detailed description of the credential type. It MUST have at least the **type** sub claims which is a JSON array containing the type values the Wallet SHALL request in the Credential Request. It MUST be set in accordance to the type of the requested PID/(Q)EAA that is obtained from the PID/(Q)EAA Issuer metadata. For example, in the case of the PID, it MUST be set to ``PersonIdentificationData``. - `[OIDC4VCI. Draft 13] `_. * - **format** - Format of the Credential to be issued. This MUST be `vc+sd-jwt`. From 2e57d0b8802bba99cb309630087eb7f17874c188 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 17 Jul 2023 11:40:53 +0200 Subject: [PATCH 10/39] Apply suggestions from code review Co-authored-by: Giuseppe De Marco --- docs/en/pid-eaa-data-model.rst | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index 629c6288b..1ff53b0e4 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -21,9 +21,9 @@ The italian PID is extended according to the `OpenID Identity Assurance Profile The (Q)EAAs are issued by the (Q)EAA Issuers to a Wallet Instance and MUST be provided in SD-JWT-VC or mDOC CBOR data format. They MAY contain any (qualified) attributes, entitlement or any elettronic attestations. -The italian (Q)EAAs are extended according to the `OpenID Identity Assurance Profile [OIDC.IDA] `_, that allows the recipients to know the Authentic Sources where the data are taken. +The (Q)EAAs are extended according to the `OpenID Identity Assurance Profile [OIDC.IDA] `_, that allows the recipients to know the Authentic Sources where where the data comes from. -The PID/(Q)EAA data format and the mechanism through which it is issued into the Wallet Instance and presented to a RP will be detailed in the next sections. +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. SD-JWT ====== @@ -87,7 +87,7 @@ The following claims MUST be in the JWT payload and MUST NOT be included in the - **Description** - **Reference** * - **iss** - - The PID/(Q)EAA Issuer identifier as URL string (the issuer of this JWT) + - URL string representing the PID/(Q)EAA Issuer unique identifier. - `[RFC7519, Section 4.1.1] `_. * - **sub** - Thumbprint of the JWK in the ``cnf`` parameter @@ -121,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, as sub claims, regarding the identity trust framework used by the PID/(Q)EAA Issuer to provide a verified User claims. Some of these additional claims MAY be included in the Disclosures and MAY be selectively disclosed and they are given in the following tables that also 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 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. @@ -139,7 +139,7 @@ The ``verification`` claim is a JSON structure with all the following mandatory - [NSD]. MUST be set according to the LoA required. For PID credential it MUST be set to ``high``. - `[OID.IDA. Section 5.1] `_ * - **evidence** - - [SD]. JSON Array. Each element is the electronic evidence of the user identification during the PID issuing phase or, in case of (Q)EAA, it represents the evidence of the Authentic Sources that ensure the authenticity of the data conveyed by the (Q)EAA. It MUST contain at least the following claims: + - [SD]. JSON Array. Each element is the electronic evidence of the User identification during the PID issuance or, in the case of (Q)EAA, it represents the evidence of the Authentic Source that ensures the authenticity of the data conveyed by the (Q)EAA. It MUST contain at least the following claims: - **type**: MUST be set to ``electronic_record`` - **record**: JSON object (see the table below) @@ -172,7 +172,7 @@ The ``record`` MUST have at least the following sub parameters: PID Claims field ---------------- -The ``claims`` parameter contains the user attributes claims with the following mandatory fields: +The ``claims`` parameter contains the User attributes with the following mandatory fields: .. list-table:: @@ -209,7 +209,7 @@ The ``claims`` parameter contains the user attributes claims with the following PID Non-normative examples -------------------------- -In the following, we provide a non-normative example of PID VC in JSON. +In the following, the non-normative example of a PID digital credential. .. code-block:: JSON @@ -416,7 +416,7 @@ In the following, we provide a non-normative example of (Q)EAA VC in JSON. } } -The corresponding SD-JWT verson for PID is given by +The corresponding SD-JWT for the preivous data is represented as follow, as decoded JSON for both header and payload. .. code-block:: JSON From 703c261d90b2706dbcc37a76c95290336636ac64 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 17 Jul 2023 11:54:41 +0200 Subject: [PATCH 11/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 3d9a266f0..17d55b36d 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -11,6 +11,7 @@ on: - LICENSE.md - .gitignore pull_request: + branches-ignore: ["gh-pages"] branches: ["*"] paths-ignore: - README.md @@ -49,14 +50,14 @@ jobs: - name: Build branch run: |- if [[ "$GITHUB_REF" = /refs/tags/* ]]; then - replace=/refs/tags/ - TAG=$(echo "$GITHUB_REF" | sed "s/\/refs\/tags\///") SUBPATH="v$TAG/" # note the trailing slash + echo "Building for TAG: $SUBPATH" else SUBPATH="${GITHUB_HEAD_REF}/" # note the trailing slash + echo "Building for PR: $SUBPATH" fi - echo "Publish on $SUBPATH sub path" + echo "Publishing $SUBPATH" sphinx-build -b html docs/it/ html/$SUBPATHit sphinx-build -b html docs/en/ html/$SUBPATHen @@ -67,11 +68,11 @@ jobs: echo ' - Italian eIDAS Wallet Technical Specifications + EUDI Wallet docs -

Italian eIDAS Wallet Technical Specifications

+

EUDI Wallet docs

  • Italian version
    • From d5077313905738171dc5c580cb3abf522f6ec336 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 17 Jul 2023 12:01:04 +0200 Subject: [PATCH 12/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 17d55b36d..4feddc3f6 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -4,15 +4,14 @@ name: gh-pages on: push: - branches: ["versione-corrente"] + branches-ignore: ["gh-pages"] + branches: ["*"] paths-ignore: - README.md - CONTRIBUTING.md - LICENSE.md - .gitignore pull_request: - branches-ignore: ["gh-pages"] - branches: ["*"] paths-ignore: - README.md - CONTRIBUTING.md From 41e0885b3da8686cf534d8c66d9eb688bf6018fc Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 17 Jul 2023 12:06:56 +0200 Subject: [PATCH 13/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 4feddc3f6..1e3aa36c0 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -4,14 +4,14 @@ name: gh-pages on: push: - branches-ignore: ["gh-pages"] - branches: ["*"] + branches: ["versione-corrente"] paths-ignore: - README.md - CONTRIBUTING.md - LICENSE.md - .gitignore pull_request: + branches: ["*"] paths-ignore: - README.md - CONTRIBUTING.md From 3f3ecde67aefe7cf61ecad4654fd19df6baf0e77 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 17 Jul 2023 12:33:01 +0200 Subject: [PATCH 14/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 1e3aa36c0..22db4aa16 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -4,7 +4,7 @@ name: gh-pages on: push: - branches: ["versione-corrente"] + branches: ["*"] paths-ignore: - README.md - CONTRIBUTING.md From 38d0a82e70a10c078cd0d4af632e823ac8dae0c1 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 17 Jul 2023 16:45:00 +0200 Subject: [PATCH 15/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 22db4aa16..7fe982c43 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -53,7 +53,7 @@ jobs: SUBPATH="v$TAG/" # note the trailing slash echo "Building for TAG: $SUBPATH" else - SUBPATH="${GITHUB_HEAD_REF}/" # note the trailing slash + SUBPATH=$(echo "$GITHUB_HEAD_REF/") # "${GITHUB_HEAD_REF}/" # note the trailing slash echo "Building for PR: $SUBPATH" fi echo "Publishing $SUBPATH" From 7ebcd3fb0be34d75ca82332bfc90634651cce760 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 17 Jul 2023 16:55:38 +0200 Subject: [PATCH 16/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 7fe982c43..921ad5854 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -24,7 +24,8 @@ on: # Allows you to run this workflow manually from the Actions tab workflow_dispatch: - +env: + BRANCH_REF: $(echo "$GITHUB_HEAD_REF/") # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: # This workflow contains a single job called "build" @@ -53,7 +54,7 @@ jobs: SUBPATH="v$TAG/" # note the trailing slash echo "Building for TAG: $SUBPATH" else - SUBPATH=$(echo "$GITHUB_HEAD_REF/") # "${GITHUB_HEAD_REF}/" # note the trailing slash + SUBPATH=$(echo "$BRANCH_REF") # "${GITHUB_HEAD_REF}/" # note the trailing slash echo "Building for PR: $SUBPATH" fi echo "Publishing $SUBPATH" From 2f86ec358ffec027ea064b5e4a1404a1e9b540f5 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 17 Jul 2023 23:11:16 +0200 Subject: [PATCH 17/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 921ad5854..b9450cfb0 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -54,7 +54,7 @@ jobs: SUBPATH="v$TAG/" # note the trailing slash echo "Building for TAG: $SUBPATH" else - SUBPATH=$(echo "$BRANCH_REF") # "${GITHUB_HEAD_REF}/" # note the trailing slash + SUBPATH=$(echo "$GITHUB_REF") # "${GITHUB_HEAD_REF}/" # note the trailing slash echo "Building for PR: $SUBPATH" fi echo "Publishing $SUBPATH" From 9400d77459393d3518ca7e6c09fe563dc6be00d4 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 17 Jul 2023 23:48:49 +0200 Subject: [PATCH 18/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index b9450cfb0..7cf765b6e 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -58,8 +58,8 @@ jobs: echo "Building for PR: $SUBPATH" fi echo "Publishing $SUBPATH" - sphinx-build -b html docs/it/ html/$SUBPATHit - sphinx-build -b html docs/en/ html/$SUBPATHen + sphinx-build -b html docs/it/ html/$SUBPATH/it + sphinx-build -b html docs/en/ html/$SUBPATH/en # Runs a single command using the runners shell - name: Create GH page index From 73d59c30ac244960214b0a0f658e7cc72b143000 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 17 Jul 2023 23:56:11 +0200 Subject: [PATCH 19/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 7cf765b6e..1651b1124 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -24,8 +24,7 @@ on: # Allows you to run this workflow manually from the Actions tab workflow_dispatch: -env: - BRANCH_REF: $(echo "$GITHUB_HEAD_REF/") + # A workflow run is made up of one or more jobs that can run sequentially or in parallel jobs: # This workflow contains a single job called "build" @@ -54,7 +53,7 @@ jobs: SUBPATH="v$TAG/" # note the trailing slash echo "Building for TAG: $SUBPATH" else - SUBPATH=$(echo "$GITHUB_REF") # "${GITHUB_HEAD_REF}/" # note the trailing slash + SUBPATH=$(echo "$GITHUB_REF" | sed "s/\/refs\/heads\///") # "${GITHUB_HEAD_REF}/" # note the trailing slash echo "Building for PR: $SUBPATH" fi echo "Publishing $SUBPATH" From a6fa998de49de49444f4f0444fc39a5d4fe9d6d9 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Tue, 18 Jul 2023 00:13:35 +0200 Subject: [PATCH 20/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 1651b1124..54e98c02f 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -53,7 +53,7 @@ jobs: SUBPATH="v$TAG/" # note the trailing slash echo "Building for TAG: $SUBPATH" else - SUBPATH=$(echo "$GITHUB_REF" | sed "s/\/refs\/heads\///") # "${GITHUB_HEAD_REF}/" # note the trailing slash + SUBPATH=$(echo "$GITHUB_HEAD_REF") # "${GITHUB_HEAD_REF}/" # note the trailing slash echo "Building for PR: $SUBPATH" fi echo "Publishing $SUBPATH" From 06e36ff7095ed7b0fc081bdb41716a7310fd03a6 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Tue, 18 Jul 2023 00:16:04 +0200 Subject: [PATCH 21/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 54e98c02f..9be7a05f2 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -53,7 +53,7 @@ jobs: SUBPATH="v$TAG/" # note the trailing slash echo "Building for TAG: $SUBPATH" else - SUBPATH=$(echo "$GITHUB_HEAD_REF") # "${GITHUB_HEAD_REF}/" # note the trailing slash + SUBPATH=$(echo "$GITHUB_REF") # "${GITHUB_HEAD_REF}/" # note the trailing slash echo "Building for PR: $SUBPATH" fi echo "Publishing $SUBPATH" From 959d28b2e0fae70c2a736ace49b501d1a8ed856c Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Tue, 18 Jul 2023 00:22:05 +0200 Subject: [PATCH 22/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 9be7a05f2..1651b1124 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -53,7 +53,7 @@ jobs: SUBPATH="v$TAG/" # note the trailing slash echo "Building for TAG: $SUBPATH" else - SUBPATH=$(echo "$GITHUB_REF") # "${GITHUB_HEAD_REF}/" # note the trailing slash + SUBPATH=$(echo "$GITHUB_REF" | sed "s/\/refs\/heads\///") # "${GITHUB_HEAD_REF}/" # note the trailing slash echo "Building for PR: $SUBPATH" fi echo "Publishing $SUBPATH" From e43ccc1456e9034f41c89d39e1cca64595385d02 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Tue, 18 Jul 2023 00:34:23 +0200 Subject: [PATCH 23/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 1651b1124..58a5c934f 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -53,7 +53,7 @@ jobs: SUBPATH="v$TAG/" # note the trailing slash echo "Building for TAG: $SUBPATH" else - SUBPATH=$(echo "$GITHUB_REF" | sed "s/\/refs\/heads\///") # "${GITHUB_HEAD_REF}/" # note the trailing slash + SUBPATH=$(echo "$GITHUB_REF" | sed "s/refs\/heads\///") # "${GITHUB_HEAD_REF}/" # note the trailing slash echo "Building for PR: $SUBPATH" fi echo "Publishing $SUBPATH" From 9d3974bfb258be4c9c601e405c68c5c48f4d4f78 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Tue, 18 Jul 2023 11:03:41 +0200 Subject: [PATCH 24/39] Update gh-pages.yml --- .github/workflows/gh-pages.yml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 58a5c934f..73867058e 100644 --- a/.github/workflows/gh-pages.yml +++ b/.github/workflows/gh-pages.yml @@ -67,11 +67,11 @@ jobs: echo ' - EUDI Wallet docs + Italian eIDAS Wallet Technical Specifications -

    EUDI Wallet docs

    +

    Italian eIDAS Wallet Technical Specifications

    • Italian version
      • From ed07295dae19d03956ce7f6ffe2ee84923ae0d88 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Tue, 18 Jul 2023 11:29:45 +0200 Subject: [PATCH 25/39] chore: peppelinux review --- docs/en/pid-eaa-data-model.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index 1ff53b0e4..1c0a9fc01 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -19,7 +19,7 @@ The User attributes carried in the Italian PID are: The italian PID is extended according to the `OpenID Identity Assurance Profile [OIDC.IDA] `_, that enables the binding of the PID to a national trust framework, giving all the evidence of the identity proofing procedures underlying the PID issuing in both remote and proximity flows. -The (Q)EAAs are issued by the (Q)EAA Issuers to a Wallet Instance and MUST be provided in SD-JWT-VC or mDOC CBOR data format. They MAY contain any (qualified) attributes, entitlement or any elettronic attestations. +The (Q)EAAs are issued by (Q)EAA Issuers to a Wallet Instance and MUST be provided in SD-JWT-VC or mDOC CBOR data format. The (Q)EAAs are extended according to the `OpenID Identity Assurance Profile [OIDC.IDA] `_, that allows the recipients to know the Authentic Sources where where the data comes from. @@ -28,7 +28,7 @@ The PID/(Q)EAA data format and the mechanism through which a digital credential SD-JWT ====== -The PID/(Q)EAA is given as a Verifiable Credential with JSON payload based on the `Selective Disclosure JWT format `_ as specified in `[draft-terbu-sd-jwt-vc-latest] `__. +The PID/(Q)EAA is issued in the form of a digital credential. The digital credential format is `Selective Disclosure JWT format `_ as specified in `[draft-terbu-sd-jwt-vc-latest] `__. An SD-JWT is a JWT that MUST be signed using the Issuer's private key. The SD-JWT payload of the MUST contain the **_sd_alg** claim described in `[SD-JWT]. Section 5.1.2. `_ and other claims specified in this section, some of them may be selectively disclosable claims. @@ -156,7 +156,7 @@ The ``record`` MUST have at least the following sub parameters: - **Description** - **Reference** * - **type** - - Identification of the trust framework used for obtaining the verified claims. For example, in case of PID, ``eidas.it.cie`` means that the CIE id identification scheme is used by the User. + - It uniquely identifies the trust framework used for the provisioning of the credential. For example, in case of PID, ``eidas.it.cie`` means that the CIE id identification scheme is used. - `[OID.IDA. Section 5.1.1.2] `_ * - **source** - JSON Object cointaining the follwoing mandatory claims: @@ -167,7 +167,7 @@ The ``record`` MUST have at least the following sub parameters: - `[OID.IDA. Section 5.1.1.2] `_ .. warning:: - Note that the sub-claims of the **evidence** parameter are not selectively disclosable separately, thus, for example, the User cannot give only the *record type* without disclosure the *record source* (organization name, identifier and country). + Note that the sub-claims of the **evidence** parameter are not selectively disclosable separately, thus, for example, the User cannot give only the *record type* without the disclosure of the *record source* value (organization name, identifier and country). PID Claims field ---------------- @@ -380,7 +380,7 @@ The combined format for the PID issuance is given by (Q)EAA Non-normative examples ----------------------------- -In the following, we provide a non-normative example of (Q)EAA VC in JSON. +In the following, we provide a non-normative example of (Q)EAA in JSON. .. code-block:: JSON From 740b9001eb58069aa06aff266bd20e049bbd5e93 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Tue, 18 Jul 2023 15:00:33 +0200 Subject: [PATCH 26/39] chore: peppelinux review --- docs/en/pid-eaa-issuance.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst index 5732c2e5a..4ffbb9c72 100644 --- a/docs/en/pid-eaa-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -94,7 +94,7 @@ The PID/(Q)EAA Issuance phase is based on the **Authorization Code Flow** with * **Federation Check:** The Wallet Instance needs to check if the PID/(Q)EAA Issuer is part of Federation, obtaining then its protocol specific metadata. A non-normative example of a response from the endpoint **.well-known/openid-federation** with the **Entity Configuration** and the **Metadata** of the PID/(Q)EAA Issuer is represented within the section `Entity Configuration Credential Issuer`_. -**Steps 5-6 (PAR Request):** The Wallet Instance creates a PKCE code verifier that sends in a *pushed authorization request*, using the request parameter (see :rfc:`9126` Section 3) to the PID/(Q)EAA Issuer PAR endpoint. The Wallet Instance signs the request using its private key. A OAuth2 client authentication method MUST be involved, since in this flow the pushed authorization endpoint is a protected endpoint. The client authentication is based on the model defined in [:rfc:`7521`] using the Wallet Instance Attestation JWS inside the **client_assertion** parameter. The authorization_details [RAR :rfc:`9396`] parameter is extended to allow Wallet Instance to specify the types of the credentials when requesting authorization for the PID/(Q)EAA issuance. +**Steps 5-6 (PAR Request):** The Wallet Instance creates a PKCE code verifier that sends in a *pushed authorization request*, using the request parameter (see :rfc:`9126` Section 3) to the PID/(Q)EAA Issuer PAR endpoint. The Wallet Instance signs the request using its private key. A OAuth2 client authentication method is involved, since in this flow the pushed authorization endpoint is a protected endpoint. The client authentication is based on the model defined in [:rfc:`7521`] using the Wallet Instance Attestation JWS inside the **client_assertion** parameter. The authorization_details [RAR :rfc:`9396`] parameter is extended to allow Wallet Instance to specify the types of the credentials when requesting authorization for the PID/(Q)EAA issuance. Below a non-normative example of the PAR. From 3c75dea106a6e85dd3aa4e837ee2e1be8d6416a0 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Wed, 19 Jul 2023 16:34:10 +0200 Subject: [PATCH 27/39] chore: added LoA definition --- docs/en/defined-terms.rst | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/docs/en/defined-terms.rst b/docs/en/defined-terms.rst index 2df421bfe..c4e1c7054 100644 --- a/docs/en/defined-terms.rst +++ b/docs/en/defined-terms.rst @@ -40,6 +40,8 @@ Below are the description of acronyms and definitions which are useful for furth - Electronic attestation of an entity's compliance with the national regulatory framework, which is cryptographically verifiable and cannot be repudiated over time by the entity that issued it. A Trust Attestation is always related to a particular Trust Framework. * - Trust Layer - 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. Acronyms -------- @@ -60,4 +62,6 @@ Acronyms - Verifiable Presentation * - **API** - Application Programming Interface + * - **LoA** + - Level of Assurance From 2d94bf64159ffc33a105abd3f239209a5aec057a Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Thu, 20 Jul 2023 09:11:47 +0200 Subject: [PATCH 28/39] chore: peppelinux rev --- docs/en/pid-eaa-data-model.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index 1c0a9fc01..86320d877 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -133,7 +133,7 @@ The ``verification`` claim is a JSON structure with all the following mandatory - **Description** - **Reference** * - **trust_framework** - - [NSD]. For PID credential it MUST be set to ``eidas``. For (Q)EAA it MUST be set to ``eidas2``. + - [NSD]. It MUST be set to ``eidas``. - `[OID.IDA. Section 5.1] `_ * - **assurance_level** - [NSD]. MUST be set according to the LoA required. For PID credential it MUST be set to ``high``. From 026dfe38f4ef23a4a2bf42b8136769a55f1d538b Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Thu, 20 Jul 2023 09:35:45 +0200 Subject: [PATCH 29/39] chore: type eidas --- docs/en/pid-eaa-data-model.rst | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index 86320d877..059e2a32d 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -387,7 +387,7 @@ In the following, we provide a non-normative example of (Q)EAA in JSON. { "verified_claims": { "verification": { - "trust_framework": "eidas2", + "trust_framework": "eidas", "assurance_level": "high", "evidence": [ { @@ -423,7 +423,7 @@ The corresponding SD-JWT for the preivous data is represented as follow, as deco { "typ":"vc+sd-jwt", "alg":"RS512", - "kid":"dB67gL7ck3TFiIAf7N6_7SHvqk0MDYMEQcoGGlkUAAw", + "kid":"d126a6a856f7724560484fa9dc59d195", "trust_chain" : [ "NEhRdERpYnlHY3M5WldWTWZ2aUhm ...", "eyJhbGciOiJSUzI1NiIsImtpZCI6 ...", @@ -443,10 +443,11 @@ The corresponding SD-JWT for the preivous data is represented as follow, as deco "cnf": { "jwk": { "kty": "RSA", - "use": "sig", - "n": "1Ta-sE …", "e": "AQAB", - "kid": "YhNFS3YnC9tjiCaivhWLVUJ3AxwGGz_98uRFaqMEEs" + "use": "sig", + "kid": "d126a6a856f7724560484fa9dc59d195", + "alg": "RS256", + "n": "oians5wYCWk4wFtEStVYcn_xOw9edKMNGH33_q6_pBI0XaTY7P3apUgjO0ivk5c1NQAVY6PZmcPQ8P1Y0cBAC9STRmzvTvDQcOocLhVy2ZlcXTu39oOGLNra8_LQsaMA386lO_qMW4-uY6DbGZY4vHkScvAC9FIZYDPafqWBEQUNV2QOFMH5VPoihCTKHwMGXnZBatYObg57xSOUX-bvhO_sFMm3k4RvsXcr3MFojAhLfwutu_jK9k7N9KR_mNc5IpiOyhZw_sUmF6SamRqsSPp42KD10hPMW0YJTDMYxBdHrMFeSMHYIMY4oBBT43__a55zILI_CnIk4241wOvGvw" } }, "type": "HealthInsuranceData", @@ -455,7 +456,7 @@ The corresponding SD-JWT for the preivous data is represented as follow, as deco "_sd": [ "2jIR18gfeASHYGB27s7sS3S_iQ4xxFIxCRyiohrBfns" ], - "trust_framework": "eidas2", + "trust_framework": "eidas", "assurance_level": "high" }, "claims": { @@ -532,7 +533,7 @@ The combined format for the PID issuance is given by .. code-block:: - eyJ0eXAiOiJ2YytzZC1qd3QiLCJhbGciOiJSUzUxMiIsImtpZCI6ImQxMjZhNmE4NTZmNzcyNDU2MDQ4NGZhOWRjNTlkMTk1IiwidHJ1c3RfY2hhaW4iOlsiTkVoUmRFUnBZbmxIWTNNNVdsZFdUV1oyYVVobSAuLi4iLCJleUpoYkdjaU9pSlNVekkxTmlJc0ltdHBaQ0k2IC4uLiIsIklrSllkbVp5Ykc1b1FVMTFTRkl3TjJGcVZXMUIgLi4uIl19.eyJpc3MiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLm9yZyIsInN1YiI6Ik56YkxzWGg4dURDY2Q3bm9XWEZaQWZIa3hac1JHQzlYcy4uLiIsImp0aSI6InVybjp1dWlkOjZjNWMwYTQ5LWI1ODktNDMxZC1iYWU3LTIxOTEyMmE5ZWMyYyIsImlhdCI6MTU0MTQ5MzcyNCwiZXhwIjoxNTQxNDkzNzI0LCJzdGF0dXMiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLm9yZy9zdGF0dXMiLCJjbmYiOnsiandrIjp7Imt0eSI6IlJTQSIsInVzZSI6InNpZyIsIm4iOiIxVGEtc0Ug4oCmIiwiZSI6IkFRQUIiLCJraWQiOiJZaE5GUzNZbkM5dGppQ2FpdmhXTFZVSjNBeHdHR3pfOTh1UkZhcU1FRXMifX0sInR5cGUiOiJIZWFsdGhJbnN1cmFuY2VEYXRhIiwidmVyaWZpZWRfY2xhaW1zIjp7InZlcmlmaWNhdGlvbiI6eyJfc2QiOlsiMmpJUjE4Z2ZlQVNIWUdCMjdzN3NTM1NfaVE0eHhGSXhDUnlpb2hyQmZucyJdLCJ0cnVzdF9mcmFtZXdvcmsiOiJlaWRhczIiLCJhc3N1cmFuY2VfbGV2ZWwiOiJoaWdoIn0sImNsYWltcyI6eyJfc2QiOlsiMWl6dHE3Ym92NjR4VFliRGtXRmM0NF9WaldlMDI5aFpxWGVVSWxvcVVONCIsIkVOTm8zMWpmekZwOFkyRFcwUi1mSU1lV3dlN0VMR3ZHb0hNd01CcHUxNEUiLCJGVjJDRE5XdVRxVGdPSGFmdHZWYXVtQkYwT2xtbnl4TXN3eWY0dUl4cmhZIiwiZFpXanE3bUpTU1gtWFRJX0hXdUU4QjJ4NklkTTVsRS1kb0RfeUJwS0phbyIsImdIWWkxOWZyYkRfaTRCb2FXRU5PamMzbENuTWo0cGJHTlFjc0JqX1FNNFEiXX19LCJfc2RfYWxnIjoic2hhLTI1NiJ9.Dy8IdMBmzL5QSxAHiYTv9Fg0HhiI-AFIwL2slNEVI5iTxcne0reX2w-Bo78bY0UkOF5LHBLjGV_l5wbX6pvDY0v193ifp7KzJIpj2jUuQ-XR7RHng9RFdjKSj7urVYaseQxKA97vWcJxNX7bYKLQ6jKOdxl0CXmFdg00HTA1MnO7OPWdRiT7BlDyl0HfwQ-X08Yk23zX2Po90p1pBIWMlqnkfeZwQIWyz6LvFcK7OClEYlmzhtLR5QmYHbIbu9oGhn00hv0Q94TcheGpSm8WmfUjE-dV6YvfWtkcsTg7bjmawt6B4W_YMwV9pSmoC1euwO1svoyAdqxjGbInmLT4hA + eyJ0eXAiOiJ2YytzZC1qd3QiLCJhbGciOiJSUzUxMiIsImtpZCI6ImQxMjZhNmE4NTZmNzcyNDU2MDQ4NGZhOWRjNTlkMTk1IiwidHJ1c3RfY2hhaW4iOlsiTkVoUmRFUnBZbmxIWTNNNVdsZFdUV1oyYVVobSAuLi4iLCJleUpoYkdjaU9pSlNVekkxTmlJc0ltdHBaQ0k2IC4uLiIsIklrSllkbVp5Ykc1b1FVMTFTRkl3TjJGcVZXMUIgLi4uIl19.eyJpc3MiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLm9yZyIsInN1YiI6Ik56YkxzWGg4dURDY2Q3bm9XWEZaQWZIa3hac1JHQzlYcy4uLiIsImp0aSI6InVybjp1dWlkOjZjNWMwYTQ5LWI1ODktNDMxZC1iYWU3LTIxOTEyMmE5ZWMyYyIsImlhdCI6MTU0MTQ5MzcyNCwiZXhwIjoxNTQxNDkzNzI0LCJzdGF0dXMiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLm9yZy9zdGF0dXMiLCJjbmYiOnsiandrIjp7Imt0eSI6IlJTQSIsImUiOiJBUUFCIiwidXNlIjoic2lnIiwia2lkIjoiZDEyNmE2YTg1NmY3NzI0NTYwNDg0ZmE5ZGM1OWQxOTUiLCJhbGciOiJSUzI1NiIsIm4iOiJvaWFuczV3WUNXazR3RnRFU3RWWWNuX3hPdzllZEtNTkdIMzNfcTZfcEJJMFhhVFk3UDNhcFVnak8waXZrNWMxTlFBVlk2UFptY1BROFAxWTBjQkFDOVNUUm16dlR2RFFjT29jTGhWeTJabGNYVHUzOW9PR0xOcmE4X0xRc2FNQTM4NmxPX3FNVzQtdVk2RGJHWlk0dkhrU2N2QUM5RklaWURQYWZxV0JFUVVOVjJRT0ZNSDVWUG9paENUS0h3TUdYblpCYXRZT2JnNTd4U09VWC1idmhPX3NGTW0zazRSdnNYY3IzTUZvakFoTGZ3dXR1X2pLOWs3TjlLUl9tTmM1SXBpT3loWndfc1VtRjZTYW1ScXNTUHA0MktEMTBoUE1XMFlKVERNWXhCZEhyTUZlU01IWUlNWTRvQkJUNDNfX2E1NXpJTElfQ25JazQyNDF3T3ZHdncifX0sInR5cGUiOiJIZWFsdGhJbnN1cmFuY2VEYXRhIiwidmVyaWZpZWRfY2xhaW1zIjp7InZlcmlmaWNhdGlvbiI6eyJfc2QiOlsiMmpJUjE4Z2ZlQVNIWUdCMjdzN3NTM1NfaVE0eHhGSXhDUnlpb2hyQmZucyJdLCJ0cnVzdF9mcmFtZXdvcmsiOiJlaWRhcyIsImFzc3VyYW5jZV9sZXZlbCI6ImhpZ2gifSwiY2xhaW1zIjp7Il9zZCI6WyIxaXp0cTdib3Y2NHhUWWJEa1dGYzQ0X1ZqV2UwMjloWnFYZVVJbG9xVU40IiwiRU5ObzMxamZ6RnA4WTJEVzBSLWZJTWVXd2U3RUxHdkdvSE13TUJwdTE0RSIsIkZWMkNETld1VHFUZ09IYWZ0dlZhdW1CRjBPbG1ueXhNc3d5ZjR1SXhyaFkiLCJkWldqcTdtSlNTWC1YVElfSFd1RThCMng2SWRNNWxFLWRvRF95QnBLSmFvIiwiZ0hZaTE5ZnJiRF9pNEJvYVdFTk9qYzNsQ25NajRwYkdOUWNzQmpfUU00USJdfX0sIl9zZF9hbGciOiJzaGEtMjU2In0.PrVt9qpf1WmfoRKncGXw6loKRANomsL-foXMqMUIyK2AO0tWM5laveqRet9Bb5A0fPq7rxNQLU57ngV3o8VzKLhFkbKm1_wtA5XuZXBfz0qGCmIP6tZQu9yAvXy162h6_i4FOINyHoL8i5mNPFTHFY0nBYTyVkCScfBC2Ccv4i7RSALbpbpviTpoYVBzFWtdOKuuMED5XwKpW9-VF_JK11yaJJ880walzu5tZ3XAOb0KkfUS3sCmSkKO5wMm1SeaS7xL5iiPSnAMTMrlmKE6qcwAkdDX-hNeGzncwBjHASTWb2udayK8Cal-wFGDWrRWGq3mU0rfuxMIFkjv4gdi8Q MDOC-CBOR ========= From 3052cc55a8c3365a06d6491edfa6e9531f1f64b2 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Thu, 20 Jul 2023 09:43:26 +0200 Subject: [PATCH 30/39] chore: peppelinux rev --- docs/en/pid-eaa-data-model.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index 059e2a32d..9f5545d78 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -162,7 +162,7 @@ The ``record`` MUST have at least the following sub parameters: - JSON Object cointaining the follwoing mandatory claims: - **organization_name**: Name of the Organization. In case of PID, it is the Organization handling the eID used by the User. For the (Q)EAA it is the Authentic Source. - - **organization_id**: Identification code for the Organization. For public Organization, it MUST be set to the *IPA Code*. + - **organization_id**: Identification code for the Organization. For public Organization, it MUST be set to the *IPA Code*, following the URN namespace ``urn:eudi:it:organization_id:ipa_code:``. - **country_code**: String representing country in `[ISO3166-1] Alpha-2 (e.g., IT) or [ISO3166-3] syntax `_. - `[OID.IDA. Section 5.1.1.2] `_ From b8f7aaf7cbd56e5af7c0d29c32c3e482ffa1d7f1 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Fri, 21 Jul 2023 17:33:31 +0200 Subject: [PATCH 31/39] chore: peppelinux revision --- docs/en/pid-eaa-data-model.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index 9f5545d78..e558b38d4 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -161,7 +161,7 @@ The ``record`` MUST have at least the following sub parameters: * - **source** - JSON Object cointaining the follwoing mandatory claims: - - **organization_name**: Name of the Organization. In case of PID, it is the Organization handling the eID used by the User. For the (Q)EAA it is the Authentic Source. + - **organization_name**: Name of the Organization acting as Authentic Source. - **organization_id**: Identification code for the Organization. For public Organization, it MUST be set to the *IPA Code*, following the URN namespace ``urn:eudi:it:organization_id:ipa_code:``. - **country_code**: String representing country in `[ISO3166-1] Alpha-2 (e.g., IT) or [ISO3166-3] syntax `_. - `[OID.IDA. Section 5.1.1.2] `_ From 7a2971c8f2f66efbbf2bb507f89bfc5578cba23f Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Fri, 21 Jul 2023 17:40:25 +0200 Subject: [PATCH 32/39] chore: editorial --- docs/en/pid-eaa-data-model.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index e558b38d4..7d28ad84f 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -209,7 +209,7 @@ The ``claims`` parameter contains the User attributes with the following mandato PID Non-normative examples -------------------------- -In the following, the non-normative example of a PID digital credential. +In the following, the non-normative example of a PID. .. code-block:: JSON From f000f074a00e32892e03d6b36e50df1b1f13339a Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Fri, 21 Jul 2023 17:46:47 +0200 Subject: [PATCH 33/39] chore: record type value --- docs/en/pid-eaa-data-model.rst | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index 7d28ad84f..70103fba8 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -156,7 +156,7 @@ The ``record`` MUST have at least the following sub parameters: - **Description** - **Reference** * - **type** - - It uniquely identifies the trust framework used for the provisioning of the credential. For example, in case of PID, ``eidas.it.cie`` means that the CIE id identification scheme is used. + - It uniquely identifies the trust framework used for the provisioning of the credential. For example, in case of PID, ``https://eudi.wallet.cie.gov.it`` means that the CIE id identification scheme is used. - `[OID.IDA. Section 5.1.1.2] `_ * - **source** - JSON Object cointaining the follwoing mandatory claims: @@ -222,7 +222,7 @@ In the following, the non-normative example of a PID. { "type": "electronic_record", "record": { - "type": "eidas.it.cie", + "type": "https://eudi.wallet.cie.gov.it", "source": { "organization_name": "Ministero dell'Interno", "organization_id": "m_it", @@ -315,7 +315,7 @@ Claim **evidence**: ``OiAiTWluaXN0ZXJvIGRlbGwnSW50ZXJubyIsICJvcmdhbml6YXRpb25faWQi`` ``OiAibV9pdCIsICJjb3VudHJ5X2NvZGUiOiAiSVQifX19XV0`` - Contents: ``["2GLC42sKQveCfGfryNRN9w", "evidence", [{"type":`` - ``"electronic_record", "record": {"type": "eidas.it.cie",`` + ``"electronic_record", "record": {"type": "https://eudi.wallet.cie.gov.it",`` ``"source": {"organization_name": "Ministero dell'Interno",`` ``"organization_id": "m_it", "country_code": "IT"}}}]]`` @@ -393,7 +393,7 @@ In the following, we provide a non-normative example of (Q)EAA in JSON. { "type": "electronic_record", "record": { - "type": "eidas.it.pdnd", + "type": "https://eudi.wallet.pdnd.gov.it", "source": { "organization_name": "Ragioneria Generale dello Stato", "organization_id": "QLHCFC", @@ -485,7 +485,7 @@ Claim **evidence**: ``emF0aW9uX2lkIjogIlFMSENGQyIsICJjb3VudHJ5X2NvZGUiOiAiSVQifX19`` ``XV0`` - Contents: ``["2GLC42sKQveCfGfryNRN9w", "evidence", [{"type":`` - ``"electronic_record", "record": {"type": "eidas.it.pdnd",`` + ``"electronic_record", "record": {"type": "https://eudi.wallet.pdnd.gov.it",`` ``"source": {"organization_name": "Ragioneria Generale dello Stato",`` ``"organization_id": "QLHCFC", "country_code":"IT"}}}]]`` From 60d7539a8835c26e319eab115d55eefc1ccb70b6 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Fri, 21 Jul 2023 17:49:29 +0200 Subject: [PATCH 34/39] Update docs/en/pid-eaa-issuance.rst Co-authored-by: Giuseppe De Marco --- docs/en/pid-eaa-issuance.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst index 4ffbb9c72..efa17a3db 100644 --- a/docs/en/pid-eaa-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -16,7 +16,7 @@ The relevant entities and interfaces involved in the issuance flow are: - OpenID4VCI Component: based on the “OpenID for Verifiable Credential Issuance” specification `[OIDC4VCI. Draft 13] `_ to release PID credentials. - National eID Relying Party (OpenID Connect or SAML2): It represents the component to authenticate the End-User with the national Digital Identity Providers. - National IdP: 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 `_). - - *(Q)EAA Issuer*: It represents the issuer of (Q)EAAs. It is composed of: + - *(Q)EAA Issuer*: 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] `_ to release (Q)EAAs. - Relying Party: It represents the component to authenticate the User with the PID. The (Q)EAA Issuer 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 Issuer. From ff8b363c426ef69137ab0bdd8519ca9f6ec900fd Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Fri, 21 Jul 2023 17:51:40 +0200 Subject: [PATCH 35/39] chore: editorial --- docs/en/pid-eaa-issuance.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst index 4ffbb9c72..766ccadd4 100644 --- a/docs/en/pid-eaa-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -39,7 +39,7 @@ Below a detailed description for each step represented in the previous picture: 0. **Wallet Instance Setup**: the first time the Wallet Instance is started a preliminary setup phase MUST be carried out. It consists of the release of a verifiable proof issued by the Attestation Service provided by the Wallet Provider that asserts the genuineness, the authenticity and the compliance with a trust framework of the Wallet Instance. The verifiable proof binds a public key corresponding to a local private key generated by the Wallet Instance. 1. **Obtaining the trusted PID Provider**: the Wallet Instance queries the Trust Anchor to fetch the trusted PID Provider. 2. **Obtaining of PID Provider metadata**: the Wallet Instance establishes the trust to the PID Provider according to the Trust Model, obtaining the Metadata that discloses the formats of the PID, the algorithms supported, and any other parameter required for interoperability needs. - 3. **PID request**: following the Authorization Code Flow in `[OIDC4VCI. Draft 13] `_ the Wallet Instance requests a PID to the PID Provider. A fresh key pairs is generated by the Wallet Instance, the public key is used by PID Provider for the key binding of the PID. The PID Provider checks the Wallet Instance by means of the Wallet Attestation and the Trust Chain related to the Wallet Provider + 3. **PID request**: following the Authorization Code Flow in `[OIDC4VCI. Draft 13] `_ the Wallet Instance requests a PID to the PID Provider. A fresh key pairs is generated by the Wallet Instance, the public key is used by PID Provider for the key binding of the PID. The PID Provider checks the Wallet Instance by means of the Wallet Attestation and the Trust Chain related to the Wallet Provider. 4. **End-user authentication**: the PID Provider authenticates the End-User with LoA High, acting as an IAM Proxy to the National eID system. 5. **PID issuance**: once the User authentication with LoA High happens, the User gives their consent, and the PID Provider releases a PID bound to the key material held by the requesting Wallet Instance. From cfee7fa3c303628ce2821bde6c2b0373f21747ac Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Sun, 23 Jul 2023 15:55:24 +0200 Subject: [PATCH 36/39] chore: peppelinux revision --- docs/en/pid-eaa-issuance.rst | 36 ++++++++++++++++++------------------ 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst index ff370544d..aac50d83f 100644 --- a/docs/en/pid-eaa-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -5,7 +5,7 @@ PID/(Q)EAA Issuance +++++++++++++++++++ -This section describes the issuance flow for the PID and (Q)EAAs that require a high security implementation profile. +This section describes the PID and (Q)EAAs issuance flow with an high level of security. The relevant entities and interfaces involved in the issuance flow are: - *Wallet Provider*: It represents an organization (public or private) that is responsible for the release of an eIDAS-compliant EUDI Wallet Solution. It also issues thes Wallet Instance Attestation to its Wallet Instances by means of an Attestation Service. The Wallet Attestation certifies the genuinity and authenticity of the Wallet Instance and its compliance with a Trust Framework in compliance to the security and privacy requirements. @@ -48,7 +48,7 @@ The Wallet Instance Setup phase is described in Section [...]. In the following High-Level (Q)EAA flow ---------------------- -The :numref:`fig_High-Level-Flow-ITWallet-QEAA-Issuance` shows a general architecture and highlights the main operations involved in the issuance of a (Q)EAA, under the main following assumptions: +The :numref:`fig_High-Level-Flow-ITWallet-QEAA-Issuance` shows a general architecture and highlights the main operations involved in the issuance of a (Q)EAA, following the assumptions listed below: - the User has a valid PID stored in its own Wallet Instance; - the (Q)EAA requires a high security implementation profile. @@ -64,9 +64,9 @@ Below the description of the most relevant operations involved in the (Q)EAA iss 1. **Obtaining the trusted (Q)EAA Issuer**: the Wallet Instance queries the Trust Anchor to fetch the trusted (Q)EAA Issuer. 2. **Obtaining of (Q)EAA Issuer metadata**: the Wallet Instance establishes the trust to the (Q)EAA Issuer according to the Trust Model, obtaining the Metadata that discloses the formats of the (Q)EAA, the algorithms supported, and any other parameter required for interoperability needs. - 3. **(Q)EAA request**: following the Authorization Code Flow in `[OIDC4VCI. Draft 13] `_ the Wallet Instance requests a (Q)EAA to the (Q)EAA Issuer. A fresh key pairs is generated by the Wallet Instance, the public key is used by (Q)EAA Issuer for the key binding of the (Q)EAA. The (Q)EAA Issuer checks the Wallet Instance by means of the Wallet Attestation and the Trust Chain related to the Wallet Provider - 4. **End-user authentication**: the (Q)EAA Issuer authenticates the User with the PID owned by the User, acting as a verifier (Relying Party). - 5. **(Q)EAA issuance**: once the User authentication with a valid PID happens, the User gives their consent, and the (Q)EAA Issuer releases a (Q)EAA bound to the key material held by the requesting Wallet Instance. + 3. **(Q)EAA request**: following the Authorization Code Flow in `[OIDC4VCI. Draft 13] `_ the Wallet Instance requests a (Q)EAA to the (Q)EAA Issuer. A fresh key pairs is generated by the Wallet Instance, the public key is used by (Q)EAA Issuer for the key binding of the (Q)EAA. The (Q)EAA Issuer checks the Wallet Instance by means of the Wallet Attestation and the Trust Chain related to the Wallet Provider. + 4. **End-user authentication**: the (Q)EAA Issuer, acting as a verifier (Relying Party), authenticates the User with the PID. + 5. **(Q)EAA issuance**: once the User has been authenticated with a valid PID, the User gives their consent, then the (Q)EAA Issuer releases a (Q)EAA bound to the key material held by the requesting Wallet Instance. @@ -91,7 +91,7 @@ The PID/(Q)EAA Issuance phase is based on the **Authorization Code Flow** with * .. note:: - **Federation Check:** The Wallet Instance needs to check if the PID/(Q)EAA Issuer is part of Federation, obtaining then its protocol specific metadata. A non-normative example of a response from the endpoint **.well-known/openid-federation** with the **Entity Configuration** and the **Metadata** of the PID/(Q)EAA Issuer is represented within the section `Entity Configuration Credential Issuer`_. + **Federation Check:** The Wallet Instance needs to check if the PID/(Q)EAA Issuer is part of the Federation, obtaining then its protocol specific metadata. A non-normative example of a response from the endpoint **.well-known/openid-federation** with the **Entity Configuration** and the **Metadata** of the PID/(Q)EAA Issuer is represented within the section `Entity Configuration Credential Issuer`_. **Steps 5-6 (PAR Request):** The Wallet Instance creates a PKCE code verifier that sends in a *pushed authorization request*, using the request parameter (see :rfc:`9126` Section 3) to the PID/(Q)EAA Issuer PAR endpoint. The Wallet Instance signs the request using its private key. A OAuth2 client authentication method is involved, since in this flow the pushed authorization endpoint is a protected endpoint. The client authentication is based on the model defined in [:rfc:`7521`] using the Wallet Instance Attestation JWS inside the **client_assertion** parameter. The authorization_details [RAR :rfc:`9396`] parameter is extended to allow Wallet Instance to specify the types of the credentials when requesting authorization for the PID/(Q)EAA issuance. @@ -177,7 +177,7 @@ The JWS payload of the request object is represented below: .. note:: **User Authentication and Consent:** The PID Provider performs the User authentication based on the requirements of eIDAS LoA High by means of national notified eIDAS scheme and requires the User consent for the PID issuance. - The (Q)EAA Issuer performs the User authentication requesting a valid PID to the Wallet Instance. The (Q)EAA Issuer MUST use [`OpenID4VP`_] to dynamically request presentation of the PID. From a protocol perspective, the (Q)EAA Issuer then acts as a verifier and sends a presentation request to the Wallet Instance. The Wallet Instance MUST have a valid PID obtained prior to starting a transaction with the (Q)EAA Issuer. + The (Q)EAA Issuer performs the User authentication requesting a valid PID to the Wallet Instance. The (Q)EAA Issuer MUST use [`OpenID4VP`_] to dynamically request the presentation of the PID. From a protocol perspective, the (Q)EAA Issuer then acts as a verifier and sends a presentation request to the Wallet Instance. The Wallet Instance MUST have a valid PID obtained prior to starting a transaction with the (Q)EAA Issuer. **Steps 10-11 (Authorization Response):** The PID/(Q)EAA Issuer sends an authorization code to the Wallet Instance. @@ -190,7 +190,7 @@ The JWS payload of the request object is represented below: HTTP/1.1 302 Found Location: eudiw://start.wallet.example.org?code=SplxlOBeZQQYbYS6WxSbIA&state=fyZiOL9Lf2CeKuNT2JzxiLRDink0uPcd&iss=https%3A%2F%2Fpid-provider.example.org -**Steps 12-13 (DPoP Proof for Token Endpoint)**: The Wallet Instance creates a key for DPoP and a fresh DPoP proof for the token request to the PID/(Q)EAA Issuer. DPoP provides a way to bind the access token to a certain sender (Wallet Instance) `[DPoP-draft16] `_. This mitigates the misuse of leaked or stolen Access Tokens at the Credential Endpoint of PID/(Q)EAA Issuer as the attacker needs to present a valid DPoP proof. +**Steps 12-13 (DPoP Proof for Token Endpoint)**: The Wallet Instance creates a key for DPoP and a fresh DPoP proof for the token request to the PID/(Q)EAA Issuer. DPoP provides a way to bind the Access Token to a certain sender (Wallet Instance) `[DPoP-draft16] `_. This mitigates the misuse of leaked or stolen Access Tokens at the Credential Endpoint of PID/(Q)EAA Issuer as the attacker needs to present a valid DPoP proof. **Step 14 (Token Request):** The Wallet Instance sends a token request to the PID/(Q)EAA Issuer token endpoint using the authorization *code*, *code_verifier*, *DPoP proof* and *private_key_jwt*. @@ -216,7 +216,7 @@ The JWS payload of the request object is represented below: &client_assertion=eyJhbGciOiJIUzI1NiI -**Step 15 (Token Response):** The PID/(Q)EAA Issuer validates the request and if it is successful, it issues an *access token* (bound to the DPoP key) and a fresh *c_nonce*. +**Step 15 (Token Response):** The PID/(Q)EAA Issuer validates the request and if it is successful, it issues an *Access Token* (bound to the DPoP key) and a fresh *c_nonce*. .. code-block:: http @@ -235,7 +235,7 @@ The JWS payload of the request object is represented below: **Steps 16-18 (DPoP Proof for Credential Endpoint):** The Wallet Instance creates a new key pair to which the new credential SHALL be bound. Then, it creates a proof of possession with the new key and the *c_nonce* obtained in **Step 15** and it creates a DPoP proof for the request to the PID/(Q)EAA credential issuance endpoint. -**Step 19 (Credential Request):** The Wallet Instance sends a PID/(Q)EAA issuance request to the PID/(Q)EAA credential endpoint. It contains the *access token*, the *DPoP proof*, the *credential type*, the *proof* (proof of possession of the key) and the *format*. +**Step 19 (Credential Request):** The Wallet Instance sends a PID/(Q)EAA issuance request to the PID/(Q)EAA credential endpoint. It contains the *Access Token*, the *DPoP proof*, the *credential type*, the *proof* (proof of possession of the key) and the *format*. .. note:: @@ -293,7 +293,7 @@ Where the decoded content of the JWT is represented below: -**Steps 20-22 (Credential Response):** The PID/(Q)EAA Issuer checks the *DPoP proof* and whether the *access token* is valid and suitable for the requested PID/(Q)EAA. It also checks the proof of possession for the key material the new credential SHALL be bound to. If all checks succeed, the PID/(Q)EAA Issuer creates a new credential bound to the key material and sends it to the Wallet Instance. The Wallet Instance MUST perform the PID/(Q)EAA integrity and authenticity checks before proceeding with the secure storage of the credential. +**Steps 20-22 (Credential Response):** The PID/(Q)EAA Issuer checks the *DPoP proof* and whether the *Access Token* is valid and suitable for the requested PID/(Q)EAA. It also checks the proof of possession for the key material the new credential SHALL be bound to. If all checks succeed, the PID/(Q)EAA Issuer creates a new credential bound to the key material and sends it to the Wallet Instance. The Wallet Instance MUST perform the PID/(Q)EAA integrity and authenticity checks before proceeding with the secure storage of the credential. .. code-block:: http @@ -502,7 +502,7 @@ Token endpoint -------------- The token endpoint is used by the Wallet Instance -to obtain an access token by presenting its authorization grant, as +to obtain an Access Token by presenting its authorization grant, as defined in :rfc:`6749`. Token Request @@ -510,7 +510,7 @@ Token Request The request to the PID/(Q)EAA Token endpoint MUST be an HTTP request with method POST, where its body message is encoded in ``application/x-www-form-urlencoded`` format. The Wallet Instance sends the Token endpoint request with *private_key_jwt* authentication and a *DPoP proof* containing the mandatory parameters, defined in the table below. -The Token endpoint MUST accept and validate the DPoP proof sent in the DPoP HTTP header. The Token endpoint MUST validate the DPoP proof according to Section 4.3 of the DPoP specifications `[DPoP-draft16] `_. Thus, this mitigates the misuse of leaked or stolen access tokens at the credential endpoint. If the DPoP proof is invalid, the Token endpoint returns an error response, according to Section 5.2 of [:rfc:`6749`] with ``invalid_dpop_proof`` as the value of the error parameter. +The Token endpoint MUST accept and validate the DPoP proof sent in the DPoP HTTP header. The Token endpoint MUST validate the DPoP proof according to Section 4.3 of the DPoP specifications `[DPoP-draft16] `_. Thus, this mitigates the misuse of leaked or stolen Access Tokens at the credential endpoint. If the DPoP proof is invalid, the Token endpoint returns an error response, according to Section 5.2 of [:rfc:`6749`] with ``invalid_dpop_proof`` as the value of the error parameter. .. list-table:: @@ -641,7 +641,7 @@ A DPoP-bound Access Token is provided by the PID/(Q)EAA Token endpoint as a resu - It identifies the principal that is the subject of the JWT. It MUST be set to the value of the ``sub`` field in the PID/(Q)EAA SD-JWT-VC. - [:rfc:`9068`], [:rfc:`7519`] and [`OpenID.Core#SubjectIDTypes `_]. * - **client_id** - - MUST be set to the *jwk* value in the *cnf* parameter inside the Wallet Instance Attestation. + - It MUST be set to the *jwk* value in the *cnf* parameter, as taken in the Wallet Instance Attestation. - [:rfc:`9068`]. * - **aud** - It MUST match the value *client_id*. The RP MUST verify that this value matches its client ID. @@ -656,7 +656,7 @@ A DPoP-bound Access Token is provided by the PID/(Q)EAA Token endpoint as a resu - It MUST be a String in *uuid4* format. Unique Token ID identifier that the RP MAY use to prevent reuse by rejecting the Token ID if already processed. - [:rfc:`9068`], [:rfc:`7519`]. * - **jkt** - - JWK SHA-256 Thumbprint Confirmation Method. The value of the jkt member MUST be the base64url encoding (as defined in [RFC7515]) of the JWK SHA-256 Thumbprint of the DPoP public key (in JWK format) to which the access token is bound. + - JWK SHA-256 Thumbprint Confirmation Method. The value of the jkt member MUST be the base64url encoding (as defined in [RFC7515]) of the JWK SHA-256 Thumbprint of the DPoP public key (in JWK format) to which the Access Token is bound. - [`DPoP-draft16 `_. Section 6.1] and [:rfc:`7638`]. @@ -669,7 +669,7 @@ The Credential Endpoint issues a Credential as approved by the End-User upon pre Credential Request ^^^^^^^^^^^^^^^^^^^ -A Wallet Instance makes a PID/(Q)EAA Request to the PID/(Q)EAA Credential endpoint by sending the following mandatory parameters in the entity-body of an HTTP POST request using the `application/json` media type. +The Wallet Instance when requests the PID/(Q)EAA to the PID/(Q)EAA Credential endpoint, MUST use the following parameters in the entity-body of the HTTP POST request, using the `application/json` media type. The Credential endpoint MUST accept and validate the *DPoP proof* sent in the DPoP field of the Header based on the steps defined in Section 4.3 of [DPoP-draft16]. The *DPoP proof* in addition to the values that are defined in the Token Endpoint section MUST contain the following claim: - **ath**: hash of the Access Token. The value MUST be the result of a base64url encoding (as defined in Section 2 of :rfc:`7515`) the SHA-256 hash of the ASCII encoding of the associated Access Token's value. @@ -702,7 +702,7 @@ If the *DPoP proof* is invalid, the Credential endpoint returns an error respons .. note:: - If the **format** value is `mso_mdoc`, the credential request MUST contain the doctype claim which is a JSON string identifying the credential type according to `EIDAS-ARF`_ . See Appendix E.2. of `[OIDC4VCI. Draft 13] `_ for more details. + If the **format** value is `mso_mdoc`, the credential request MUST contain the ``doctype`` claim which is a JSON string identifying the credential type according to `EIDAS-ARF`_ . See Appendix E.2. of `[OIDC4VCI. Draft 13] `_ for more details. The JWT proof type MUST contain the following parameters for the JOSE header and the JWT body: @@ -821,7 +821,7 @@ Below a non-normative example of an Entity Configuration containing an `openid_c "credentials_supported": [ { "format": "vc+sd-jwt", - "id": "eu.eudiw.pid.it", + "id": "eudiw.pid.it", "cryptographic_binding_methods_supported": ["jwk"], "cryptographic_suites_supported": ["RS256", "RS512", "ES256", "ES512"], "display": [{ From 987dc772635d80543ae808c2183c79af013755df Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Sun, 23 Jul 2023 16:01:38 +0200 Subject: [PATCH 37/39] chore: new keys for credential binding --- docs/en/pid-eaa-issuance.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst index aac50d83f..7ff72ce85 100644 --- a/docs/en/pid-eaa-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -233,7 +233,7 @@ The JWS payload of the request object is represented below: } -**Steps 16-18 (DPoP Proof for Credential Endpoint):** The Wallet Instance creates a new key pair to which the new credential SHALL be bound. Then, it creates a proof of possession with the new key and the *c_nonce* obtained in **Step 15** and it creates a DPoP proof for the request to the PID/(Q)EAA credential issuance endpoint. +**Steps 16-18 (DPoP Proof for Credential Endpoint):** The Wallet Instance SHOULD create a new key pair to which the new credential SHALL be bound. Then, it creates a proof of possession with the new key and the *c_nonce* obtained in **Step 15** and it creates a DPoP proof for the request to the PID/(Q)EAA credential issuance endpoint. **Step 19 (Credential Request):** The Wallet Instance sends a PID/(Q)EAA issuance request to the PID/(Q)EAA credential endpoint. It contains the *Access Token*, the *DPoP proof*, the *credential type*, the *proof* (proof of possession of the key) and the *format*. From 29f57d28db0eb1616788450405eee7825840ecfa Mon Sep 17 00:00:00 2001 From: fmarino-ipzs Date: Sun, 23 Jul 2023 16:10:46 +0200 Subject: [PATCH 38/39] chore: peppelinux revision --- docs/en/pid-eaa-data-model.rst | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index 70103fba8..6baf141ed 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -21,7 +21,7 @@ The italian PID is extended according to the `OpenID Identity Assurance Profile The (Q)EAAs are issued by (Q)EAA Issuers to a Wallet Instance and MUST be provided in SD-JWT-VC or mDOC CBOR data format. -The (Q)EAAs are extended according to the `OpenID Identity Assurance Profile [OIDC.IDA] `_, that allows the recipients to know the Authentic Sources where where the data comes from. +The (Q)EAAs are extended according to the `OpenID Identity Assurance Profile [OIDC.IDA] `_, 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. @@ -139,7 +139,7 @@ The ``verification`` claim is a JSON structure with all the following mandatory - [NSD]. MUST be set according to the LoA required. For PID credential it MUST be set to ``high``. - `[OID.IDA. Section 5.1] `_ * - **evidence** - - [SD]. JSON Array. Each element is the electronic evidence of the User identification during the PID issuance or, in the case of (Q)EAA, it represents the evidence of the Authentic Source that ensures the authenticity of the data conveyed by the (Q)EAA. It MUST contain at least the following claims: + - [SD]. JSON Array. Each element is the electronic evidence of the User identification during the PID issuance or, in the case of (Q)EAA, with this evidence the Authentic Source assures the authenticity of the data conveyed in the (Q)EAA. It MUST contain at least the following claims: - **type**: MUST be set to ``electronic_record`` - **record**: JSON object (see the table below) @@ -156,7 +156,7 @@ The ``record`` MUST have at least the following sub parameters: - **Description** - **Reference** * - **type** - - It uniquely identifies the trust framework used for the provisioning of the credential. For example, in case of PID, ``https://eudi.wallet.cie.gov.it`` means that the CIE id identification scheme is used. + - It uniquely identifies the trust framework used for the provisioning of the credential. For example, in case of PID, the value ``https://eudi.wallet.cie.gov.it`` means that the CIE id identification scheme is used. - `[OID.IDA. Section 5.1.1.2] `_ * - **source** - JSON Object cointaining the follwoing mandatory claims: @@ -396,7 +396,7 @@ In the following, we provide a non-normative example of (Q)EAA in JSON. "type": "https://eudi.wallet.pdnd.gov.it", "source": { "organization_name": "Ragioneria Generale dello Stato", - "organization_id": "QLHCFC", + "organization_id": "urn:eudi:it:organization_id:ipa_code:QLHCFC", "country_code": "IT" } } From 985262c5e665733d9509a69288d5bed87232f4c1 Mon Sep 17 00:00:00 2001 From: fmarino-ipzs <77629526+fmarino-ipzs@users.noreply.github.com> Date: Mon, 24 Jul 2023 11:51:06 +0200 Subject: [PATCH 39/39] Apply suggestions from code review Co-authored-by: Giuseppe De Marco --- docs/en/pid-eaa-data-model.rst | 8 ++++---- docs/en/pid-eaa-issuance.rst | 2 +- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index 6baf141ed..e999c5d60 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -206,7 +206,7 @@ The ``claims`` parameter contains the User attributes with the following mandato -PID Non-normative examples +PID Non-normative Examples -------------------------- In the following, the non-normative example of a PID. @@ -416,7 +416,7 @@ In the following, we provide a non-normative example of (Q)EAA in JSON. } } -The corresponding SD-JWT for the preivous data is represented as follow, as decoded JSON for both header and payload. +The corresponding SD-JWT for the previous data is represented as follow, as decoded JSON for both header and payload. .. code-block:: JSON @@ -472,7 +472,7 @@ The corresponding SD-JWT for the preivous data is represented as follow, as deco "_sd_alg": "sha-256" } -In the following the disclosure list is given +In the following the disclosure list is given: Claim **evidence**: @@ -529,7 +529,7 @@ Claim **tax_id_code**: - Contents: ``["AJx-095VPrpTtN4QMOqROA", "tax_id_code",`` ``"TINIT-XXXXXXXXXXXXXXXX"]`` -The combined format for the PID issuance is given by +The combined format for the PID issuance is represented below: .. code-block:: diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst index 7ff72ce85..9cfca1822 100644 --- a/docs/en/pid-eaa-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -50,7 +50,7 @@ High-Level (Q)EAA flow The :numref:`fig_High-Level-Flow-ITWallet-QEAA-Issuance` shows a general architecture and highlights the main operations involved in the issuance of a (Q)EAA, following the assumptions listed below: - - the User has a valid PID stored in its own Wallet Instance; + - the User has a valid PID stored in their own Wallet Instance; - the (Q)EAA requires a high security implementation profile. .. _fig_High-Level-Flow-ITWallet-QEAA-Issuance: