diff --git a/.github/workflows/gh-pages.yml b/.github/workflows/gh-pages.yml index 1e3aa36c0..58a5c934f 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 @@ -24,7 +24,7 @@ on: # Allows you to run this workflow manually from the Actions tab workflow_dispatch: - + # 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,12 +53,12 @@ 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_REF" | sed "s/refs\/heads\///") # "${GITHUB_HEAD_REF}/" # note the trailing slash 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 diff --git a/docs/en/defined-terms.rst b/docs/en/defined-terms.rst index 73bd92d33..fffdb9a10 100644 --- a/docs/en/defined-terms.rst +++ b/docs/en/defined-terms.rst @@ -47,6 +47,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 -------- @@ -67,4 +69,6 @@ Acronyms - Verifiable Presentation * - **API** - Application Programming Interface + * - **LoA** + - Level of Assurance diff --git a/docs/en/index.rst b/docs/en/index.rst index 5e806f649..82ff010e5 100644 --- a/docs/en/index.rst +++ b/docs/en/index.rst @@ -65,8 +65,8 @@ Index of content ssi-introduction.rst defined-terms.rst trust.rst - pid-data-model.rst - pid-issuance.rst + pid-eaa-data-model.rst + pid-eaa-issuance.rst wallet-solution.rst wallet-instance-attestation.rst relying-party-solution.rst diff --git a/docs/en/pid-data-model.rst b/docs/en/pid-eaa-data-model.rst similarity index 60% rename from docs/en/pid-data-model.rst rename to docs/en/pid-eaa-data-model.rst index a8d9a4c81..25888685e 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 (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 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. 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 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. @@ -48,8 +50,9 @@ 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 +88,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) + - URL string representing the PID/(Q)EAA Issuer unique identifier. - `[RFC7519, Section 4.1.1] `_. * - **sub** - Thumbprint of the JWK in the ``cnf`` parameter @@ -106,7 +109,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,10 +119,10 @@ 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). +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. @@ -131,13 +134,13 @@ The ``verification`` claim is a JSON structure with all the following mandatory - **Description** - **Reference** * - **trust_framework** - - [NSD]. MUST be set to eidas + - [NSD]. It MUST be set to ``eidas``. - `[OID.IDA. Section 5.1] `_ * - **assurance_level** - - [NSD]. MUST be set to 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. 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) @@ -154,24 +157,23 @@ 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. + - 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: - - **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 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] `_ .. 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 the disclosure of the *record source* value (organization name, identifier and country). -Claims field ------------- - -The ``claims`` parameter contains the user attributes claims with the following mandatory fields: +PID Claims field +---------------- +The ``claims`` parameter contains the User attributes with the following mandatory fields: .. list-table:: :widths: 20 60 20 @@ -204,10 +206,10 @@ 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. +In the following, the non-normative example of a PID. .. code-block:: JSON @@ -220,7 +222,7 @@ In the following, we provide a non-normative example of PID VC in JSON. { "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", @@ -313,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"}}}]]`` @@ -375,7 +377,163 @@ 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 in JSON. + +.. code-block:: JSON + + { + "verified_claims": { + "verification": { + "trust_framework": "eidas", + "assurance_level": "high", + "evidence": [ + { + "type": "electronic_record", + "record": { + "type": "https://eudi.wallet.pdnd.gov.it", + "source": { + "organization_name": "Ragioneria Generale dello Stato", + "organization_id": "urn:eudi:it:organization_id:ipa_code: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 for the previous data is represented as follow, as decoded JSON for both header and payload. + +.. code-block:: JSON + + { + "typ":"vc+sd-jwt", + "alg":"RS512", + "kid":"d126a6a856f7724560484fa9dc59d195", + "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", + "e": "AQAB", + "use": "sig", + "kid": "d126a6a856f7724560484fa9dc59d195", + "alg": "RS256", + "n": "oians5wYCWk4wFtEStVYcn_xOw9edKMNGH33_q6_pBI0XaTY7P3apUgjO0ivk5c1NQAVY6PZmcPQ8P1Y0cBAC9STRmzvTvDQcOocLhVy2ZlcXTu39oOGLNra8_LQsaMA386lO_qMW4-uY6DbGZY4vHkScvAC9FIZYDPafqWBEQUNV2QOFMH5VPoihCTKHwMGXnZBatYObg57xSOUX-bvhO_sFMm3k4RvsXcr3MFojAhLfwutu_jK9k7N9KR_mNc5IpiOyhZw_sUmF6SamRqsSPp42KD10hPMW0YJTDMYxBdHrMFeSMHYIMY4oBBT43__a55zILI_CnIk4241wOvGvw" + } + }, + "type": "HealthInsuranceData", + "verified_claims": { + "verification": { + "_sd": [ + "2jIR18gfeASHYGB27s7sS3S_iQ4xxFIxCRyiohrBfns" + ], + "trust_framework": "eidas", + "assurance_level": "high" + }, + "claims": { + "_sd": [ + "1iztq7bov64xTYbDkWFc44_VjWe029hZqXeUIloqUN4", + "ENNo31jfzFp8Y2DW0R-fIMeWwe7ELGvGoHMwMBpu14E", + "FV2CDNWuTqTgOHaftvVaumBF0OlmnyxMswyf4uIxrhY", + "dZWjq7mJSSX-XTI_HWuE8B2x6IdM5lE-doD_yBpKJao", + "gHYi19frbD_i4BoaWENOjc3lCnMj4pbGNQcsBj_QM4Q" + ] + } + }, + "_sd_alg": "sha-256" + } + +In the following the disclosure list is given: + +Claim **evidence**: + +- SHA-256 Hash: ``2jIR18gfeASHYGB27s7sS3S_iQ4xxFIxCRyiohrBfns`` +- Disclosure: + ``WyIyR0xDNDJzS1F2ZUNmR2ZyeU5STjl3IiwgImV2aWRlbmNlIiwgW3sidHlw`` + ``ZSI6ICJlbGVjdHJvbmljX3JlY29yZCIsICJyZWNvcmQiOiB7InR5cGUiOiAi`` + ``ZWlkYXMuaXQucGRuZCIsICJzb3VyY2UiOiB7Im9yZ2FuaXphdGlvbl9uYW1l`` + ``IjogIlJhZ2lvbmVyaWEgR2VuZXJhbGUgZGVsbG8gU3RhdG8iLCAib3JnYW5p`` + ``emF0aW9uX2lkIjogIlFMSENGQyIsICJjb3VudHJ5X2NvZGUiOiAiSVQifX19`` + ``XV0`` +- Contents: ``["2GLC42sKQveCfGfryNRN9w", "evidence", [{"type":`` + ``"electronic_record", "record": {"type": "https://eudi.wallet.pdnd.gov.it",`` + ``"source": {"organization_name": "Ragioneria Generale dello Stato",`` + ``"organization_id": "QLHCFC", "country_code":"IT"}}}]]`` + +Claim **given_name**: + +- SHA-256 Hash: ``gHYi19frbD_i4BoaWENOjc3lCnMj4pbGNQcsBj_QM4Q`` +- Disclosure: + ``WyJlbHVWNU9nM2dTTklJOEVZbnN4QV9BIiwgImdpdmVuX25hbWUiLCAiTWFyaW8iXQ`` +- Contents: ``["eluV5Og3gSNII8EYnsxA_A", "given_name", "Mario"]`` + +Claim **family_name**: + +- SHA-256 Hash: ``dZWjq7mJSSX-XTI_HWuE8B2x6IdM5lE-doD_yBpKJao`` +- Disclosure: + ``WyI2SWo3dE0tYTVpVlBHYm9TNXRtdlZBIiwgImZhbWlseV9uYW1lIiwgIlJvc3NpIl0`` +- Contents: ``["6Ij7tM-a5iVPGboS5tmvVA", "family_name", "Rossi"]`` + +Claim **birthdate**: + +- SHA-256 Hash: ``FV2CDNWuTqTgOHaftvVaumBF0OlmnyxMswyf4uIxrhY`` +- Disclosure: + ``WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImJpcnRoZGF0ZSIsICIxOTgwLTAxLTEwIl0`` +- Contents: ``["eI8ZWm9QnKPpNPeNenHdhQ", "birthdate", "1980-01-10"]`` + +Claim **place_of_birth**: + +- SHA-256 Hash: ``1iztq7bov64xTYbDkWFc44_VjWe029hZqXeUIloqUN4`` +- Disclosure: + ``WyJRZ19PNjR6cUF4ZTQxMmExMDhpcm9BIiwgInBsYWNlX29mX2JpcnRoIiwg`` + ``eyJjb3VudHJ5IjogIklUIiwgImxvY2FsaXR5IjogIlJvbWUifV0`` +- Contents: + ``["Qg_O64zqAxe412a108iroA", "place_of_birth", {"country":`` + ``"IT", "locality": "Rome"}]`` + +Claim **tax_id_code**: + +- SHA-256 Hash: ``ENNo31jfzFp8Y2DW0R-fIMeWwe7ELGvGoHMwMBpu14E`` +- Disclosure: + ``WyJBSngtMDk1VlBycFR0TjRRTU9xUk9BIiwgInRheF9pZF9jb2RlIiwgIlRJ`` + ``TklULVhYWFhYWFhYWFhYWFhYWFgiXQ`` +- Contents: ``["AJx-095VPrpTtN4QMOqROA", "tax_id_code",`` + ``"TINIT-XXXXXXXXXXXXXXXX"]`` + +The combined format for the PID issuance is represented below: + +.. code-block:: + eyJ0eXAiOiJ2YytzZC1qd3QiLCJhbGciOiJSUzUxMiIsImtpZCI6ImQxMjZhNmE4NTZmNzcyNDU2MDQ4NGZhOWRjNTlkMTk1IiwidHJ1c3RfY2hhaW4iOlsiTkVoUmRFUnBZbmxIWTNNNVdsZFdUV1oyYVVobSAuLi4iLCJleUpoYkdjaU9pSlNVekkxTmlJc0ltdHBaQ0k2IC4uLiIsIklrSllkbVp5Ykc1b1FVMTFTRkl3TjJGcVZXMUIgLi4uIl19.eyJpc3MiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLm9yZyIsInN1YiI6Ik56YkxzWGg4dURDY2Q3bm9XWEZaQWZIa3hac1JHQzlYcy4uLiIsImp0aSI6InVybjp1dWlkOjZjNWMwYTQ5LWI1ODktNDMxZC1iYWU3LTIxOTEyMmE5ZWMyYyIsImlhdCI6MTU0MTQ5MzcyNCwiZXhwIjoxNTQxNDkzNzI0LCJzdGF0dXMiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLm9yZy9zdGF0dXMiLCJjbmYiOnsiandrIjp7Imt0eSI6IlJTQSIsImUiOiJBUUFCIiwidXNlIjoic2lnIiwia2lkIjoiZDEyNmE2YTg1NmY3NzI0NTYwNDg0ZmE5ZGM1OWQxOTUiLCJhbGciOiJSUzI1NiIsIm4iOiJvaWFuczV3WUNXazR3RnRFU3RWWWNuX3hPdzllZEtNTkdIMzNfcTZfcEJJMFhhVFk3UDNhcFVnak8waXZrNWMxTlFBVlk2UFptY1BROFAxWTBjQkFDOVNUUm16dlR2RFFjT29jTGhWeTJabGNYVHUzOW9PR0xOcmE4X0xRc2FNQTM4NmxPX3FNVzQtdVk2RGJHWlk0dkhrU2N2QUM5RklaWURQYWZxV0JFUVVOVjJRT0ZNSDVWUG9paENUS0h3TUdYblpCYXRZT2JnNTd4U09VWC1idmhPX3NGTW0zazRSdnNYY3IzTUZvakFoTGZ3dXR1X2pLOWs3TjlLUl9tTmM1SXBpT3loWndfc1VtRjZTYW1ScXNTUHA0MktEMTBoUE1XMFlKVERNWXhCZEhyTUZlU01IWUlNWTRvQkJUNDNfX2E1NXpJTElfQ25JazQyNDF3T3ZHdncifX0sInR5cGUiOiJIZWFsdGhJbnN1cmFuY2VEYXRhIiwidmVyaWZpZWRfY2xhaW1zIjp7InZlcmlmaWNhdGlvbiI6eyJfc2QiOlsiMmpJUjE4Z2ZlQVNIWUdCMjdzN3NTM1NfaVE0eHhGSXhDUnlpb2hyQmZucyJdLCJ0cnVzdF9mcmFtZXdvcmsiOiJlaWRhcyIsImFzc3VyYW5jZV9sZXZlbCI6ImhpZ2gifSwiY2xhaW1zIjp7Il9zZCI6WyIxaXp0cTdib3Y2NHhUWWJEa1dGYzQ0X1ZqV2UwMjloWnFYZVVJbG9xVU40IiwiRU5ObzMxamZ6RnA4WTJEVzBSLWZJTWVXd2U3RUxHdkdvSE13TUJwdTE0RSIsIkZWMkNETld1VHFUZ09IYWZ0dlZhdW1CRjBPbG1ueXhNc3d5ZjR1SXhyaFkiLCJkWldqcTdtSlNTWC1YVElfSFd1RThCMng2SWRNNWxFLWRvRF95QnBLSmFvIiwiZ0hZaTE5ZnJiRF9pNEJvYVdFTk9qYzNsQ25NajRwYkdOUWNzQmpfUU00USJdfX0sIl9zZF9hbGciOiJzaGEtMjU2In0.PrVt9qpf1WmfoRKncGXw6loKRANomsL-foXMqMUIyK2AO0tWM5laveqRet9Bb5A0fPq7rxNQLU57ngV3o8VzKLhFkbKm1_wtA5XuZXBfz0qGCmIP6tZQu9yAvXy162h6_i4FOINyHoL8i5mNPFTHFY0nBYTyVkCScfBC2Ccv4i7RSALbpbpviTpoYVBzFWtdOKuuMED5XwKpW9-VF_JK11yaJJ880walzu5tZ3XAOb0KkfUS3sCmSkKO5wMm1SeaS7xL5iiPSnAMTMrlmKE6qcwAkdDX-hNeGzncwBjHASTWb2udayK8Cal-wFGDWrRWGq3mU0rfuxMIFkjv4gdi8Q MDOC-CBOR ========= diff --git a/docs/en/pid-issuance.rst b/docs/en/pid-eaa-issuance.rst similarity index 68% rename from docs/en/pid-issuance.rst rename to docs/en/pid-eaa-issuance.rst index 9516e59f8..9cfca1822 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 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. @@ -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 `_). + - *(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. -.. _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: +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. + 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, following the assumptions listed below: + + - 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: +.. figure:: ../../images/High-Level-Flow-ITWallet-QEAA-Issuance.svg + :figwidth: 70% + :align: center + + (Q)EAA Issuance - General architecture and high level flow + +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, 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. + + + 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/bLHHRnit37xNho3I0ci01tiFiA9EupN6Wi78KlJn8D_HFY9dwIPHSRrVF-fattXf5hX17iuI-V7Zzv7w5Da6JhlEsCJUfTqQWp6zd55DlNKC5ryZXWkm4P8nQ_-z7FmI8Uuagc-zmmjuTq_Rbc-wXDFSc-3tOxgTtdspNOSCIoSKN8r3pDwWQq2gc5TZLy4_KtF4Mx-8MIrlfm5av6yFLnyXNODVioK71vy2IAH9S2KN-siuO3GcECy8_Xa3xE7Tjxlbuy8SConq51dy1Xv3YemDw4APxv0ibQu-IftQkms57N2B4B73ciaxoPvccIJLfRX_cjQUaKYv_7Bt-ELXiVZJl908wXRhfoZObeS26XCeGjP3QWrtlwCSsg6wTSsfV-88EsJRMBQQEsGnGEW7j2p0VtnUI2iDWj2Y3M4unf34hEOFy81_9umC7mB6thk85Hzwd47T4Jgkg9aDwLNTvXRS5b_-heH5woKi5AGnrSQ88TFMYEhuj_T5bPCeSsP97nfzVmbQJPgj9sfgjNwGie2Ue-RRE96spd8AA9aQMD64RCZWnBFjg24-WBB2K9dCKUYYhoXTXAfIe1dWzvv4-ehSPHboIKds6kP9L0tqJoaqkgHiKJ2N9jaXatuwqKo5JgUbIH43MC6IBAeBs9wu1LpUpl-2Up-7EzgsWm9rxiknwfsEVS0BFag5F4Kpo4hYI7z_PhoQyoswx2V2xSglu0aF_tlN1ozERdoORXlx9tGWr7jFqeDQZqUv6HKipIiWhUWsMCUdCVVDQKTEAtVsIcHl6WfOdyoXqahXejMmTOqnLWFvMUcXOAg14lpAULVZ-57zT_cgXXkvQxE8WqoraCdks-x7TwLe8F-zZr6OPAy-b2h57XN_jWEwZh9XTE7pUFkA5Lg6F8fJWyRCgi4DEIeII_sTvLc9kjJZVtgpR-w_Bim3RYcodChQv_rNDAy2TfQn0KEke0dmq5TnlApBhm6VVVa4qBjHfD6TAMEFx5IrisqKKSU7Q10ZBqkAvMLJSP5zGEtk9o6NTjs_ + :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 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 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 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:** 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 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. @@ -97,22 +137,21 @@ 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"] } } ], "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 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 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:** 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:: @@ -150,8 +190,9 @@ 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. -**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 +216,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 +233,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 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:** 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 @@ -215,7 +256,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 @@ -252,7 +293,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 before proceeding with the secure storage of the credential. .. code-block:: http @@ -274,7 +315,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 +377,18 @@ 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. + - :rfc:`9126` and :rfc:`7519`. + * - **iat** + - 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 `. - See :ref:`Table of the HTTP parameters `. @@ -352,11 +405,11 @@ 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 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``, - - **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 ``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. @@ -372,7 +425,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 +446,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 +475,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 +487,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`` 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 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] `_. @@ -449,15 +502,15 @@ 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 ^^^^^^^^^^^^^^^ -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. +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:: @@ -488,12 +541,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 +607,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 +625,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 +635,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*. + - 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** - - It MUST contain a HTTPS URL that uniquely identifies the RP. + - 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. @@ -602,11 +655,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. - - [`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. + - 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`]. @@ -619,9 +669,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. +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. -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 +688,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 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`. @@ -649,7 +702,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 +721,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 +735,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] `_. @@ -709,7 +762,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. @@ -765,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": "eudiw.pid.it", "cryptographic_binding_methods_supported": ["jwk"], "cryptographic_suites_supported": ["RS256", "RS512", "ES256", "ES512"], "display": [{ @@ -792,7 +846,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, @@ -869,7 +923,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 d539715c3..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 LoA 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