From cb1f3319ffa6cb1b7b3accac09c26258c3bd31f8 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Tue, 31 Oct 2023 20:56:56 +0100 Subject: [PATCH 1/4] fix!: attested_security_context -> aal --- docs/en/wallet-instance-attestation.rst | 12 ++++-------- docs/en/wallet-solution.rst | 13 +++++-------- 2 files changed, 9 insertions(+), 16 deletions(-) diff --git a/docs/en/wallet-instance-attestation.rst b/docs/en/wallet-instance-attestation.rst index 2a26c9c85..8bd6f9f0a 100644 --- a/docs/en/wallet-instance-attestation.rst +++ b/docs/en/wallet-instance-attestation.rst @@ -249,9 +249,9 @@ Payload || || problems is to have a limited | || || duration of the attestation. | +---------------------------+------------------------------------------------+ -|| attested_security_context|| Attested security context: | -|| || Represents the level of "security" | -|| || attested by the Wallet Provider. | +|| aal || JSON String asserting the authentication level| +|| || of the Wallet and the key as asserted in | +|| || the cnf claim. | +---------------------------+------------------------------------------------+ || cnf || This parameter contains the ``jwk`` | || || parameter | @@ -283,10 +283,6 @@ Payload || || reference. MUST set to `false`. | +---------------------------+------------------------------------------------+ -.. note:: - The claim ``attested_security_context`` (Attested Security Context) is under discussion - and MUST be intended as experimental. - Below is an example of Wallet Instance Attestation: .. code-block:: javascript @@ -305,7 +301,7 @@ Below is an example of Wallet Instance Attestation: { "iss": "https://wallet-provider.example.org", "sub": "vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c", - "attested_security_context": "https://wallet-provider.example.org/LoA/basic", + "aal": "https://wallet-provider.example.org/LoA/basic", "cnf": { "jwk": diff --git a/docs/en/wallet-solution.rst b/docs/en/wallet-solution.rst index 887f1c557..dfe8ab4ca 100644 --- a/docs/en/wallet-solution.rst +++ b/docs/en/wallet-solution.rst @@ -145,14 +145,11 @@ Payload | token_endpoint | Endpoint for obtaining the Wallet | | | Instance Attestation. | +---------------------------------------------+---------------------------------------------------------------------+ -| attested_security_context_values_supported | List of supported values for the | +| aal_values_supported | List of supported values for the | | | certifiable security context. These | | | values specify the security level | | | of the app, according to the levels: low, medium, or high. | -| | An attested security context is | -| | defined by the proof that the | -| | Wallet Instance can provide to the | -| | Wallet Provider. | +| | Authenticator Assurance Level values supported. | +---------------------------------------------+---------------------------------------------------------------------+ | grant_types_supported | The types of grants supported by | | | the token endpoint. It MUST be set to | @@ -163,11 +160,11 @@ Payload | ted | the token endpoint. | +---------------------------------------------+---------------------------------------------------------------------+ | token_endpoint_auth_signing_alg_va | Supported signature | -| lues_supported | algorithms for the token endpoint | +| lues_supported | algorithms for the token endpoint. | +---------------------------------------------+---------------------------------------------------------------------+ .. note:: - The `attested_security_context_values_supported` parameter is experimental and under review. + The `aal_values_supported` parameter is experimental and under review. Payload `federation_entity` ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -224,7 +221,7 @@ Below a non-normative example of the Entity Configuration. ] }, "token_endpoint": "https://wallet-provider.example.org/token", - "attested_security_context_values_supported": [ + "aal_values_supported": [ "https://wallet-provider.example.org/LoA/basic", "https://wallet-provider.example.org/LoA/medium", "https://wallet-provider.example.org/LoA/high" From 6d930959dd7f545cdd57f928e958ba36344c469e Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Mon, 6 Nov 2023 10:56:30 +0100 Subject: [PATCH 2/4] fix: mistakes and ambiguities removed related to PE and scopes (#157) * fix: mistakes and ambiguities removed related to PE and scopes * added tax_id_number in request scope --- docs/en/relying-party-solution.rst | 20 ++++++-------------- 1 file changed, 6 insertions(+), 14 deletions(-) diff --git a/docs/en/relying-party-solution.rst b/docs/en/relying-party-solution.rst index 630ffefd5..a9df8afa0 100644 --- a/docs/en/relying-party-solution.rst +++ b/docs/en/relying-party-solution.rst @@ -188,17 +188,13 @@ To attest a high level of security, the Wallet Instance submits its Wallet Insta Below the description of the parameters defined in *OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer (DPoP)*. -.. note:: - The use of DPoP doesn't represent any breaking changes to Wallet Instances that do not support DPoP to a *request_uri* endpoint, since it is assumed to use it as an additional security mechanisms for the attestation of the status of the Wallet Instance. - - If the DPoP HTTP Header is missing, the Relying Party would assume the lowest attestable level of security to the Wallet Instance it is interacting with. +If the DPoP HTTP Header is missing, the Relying Party would assume the lowest attestable level of security to the Wallet Instance it is interacting with. DPoP HTTP Header ^^^^^^^^^^^^^^^^ A **DPoP proof** is included in the request using the HTTP Header ``DPoP`` and containing a JWS. The JWS MUST be verified with the public key made available in the Wallet Instance Attestation (``Authorization: DPoP``). - The JOSE header of the **DPoP JWS** MUST contain at least the following parameters: .. list-table:: @@ -288,7 +284,7 @@ The Relying Party issues the signed Request Object, where a non-normative exampl } . { - "scope": "eu.europa.ec.eudiw.pid.it.1 pid-sd-jwt:unique_id+given_name+family_name", + "scope": "eu.europa.ec.eudiw.pid.it.1 tax_id_number", "client_id_scheme": "entity_id", "client_id": "https://relying-party.example.org", "response_mode": "direct_post.jwt", @@ -353,11 +349,7 @@ The JWS payload parameters are described herein: .. warning:: - This implementation profile use the parameter ``scope`` within the request instead of the ``presentation_definition``. - -Using the parameter ``scope`` requires that the Relying Party Metadata MUST -contain the ``presentation_definition``, where a non-normative example of it -is given below: + Using the parameter ``scope`` requires that the Relying Party Metadata MUST contain the ``presentation_definition``, where a non-normative example of it is given below: .. code-block:: JSON @@ -366,7 +358,7 @@ is given below: "id": "presentation definitions", "input_descriptors": [ { - "id": "pid-sd-jwt:unique_id+given_name+family_name", + "id": "eu.europa.ec.eudiw.pid.it.1", "name": "Person Identification Data", "purpose": "User authentication", "format": "vc+sd-jwt", @@ -432,7 +424,7 @@ Below is a non-normative example of the decrypted JSON ``response`` content: "id": "04a98be3-7fb0-4cf5-af9a-31579c8b0e7d", "descriptor_map": [ { - "id": "pid-sd-jwt:unique_id+given_name+family_name", + "id": "eu.europa.ec.eudiw.pid.it.1", "path": "$.vp_token.verified_claims.claims._sd[0]", "format": "vc+sd-jwt" } @@ -578,7 +570,7 @@ Below is a non-normative response example: }, "presentation_definitions": [ { - "id": "pid-sd-jwt:unique_id+given_name+family_name", + "id": "eu.europa.ec.eudiw.pid.it.1", "input_descriptors": [ { "id": "sd-jwt", From a1a5193f3b00f6faa3404cd1855249fad4c8b48d Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Mon, 6 Nov 2023 10:57:03 +0100 Subject: [PATCH 3/4] fix!: sd-jwt type -> vct (#160) --- docs/en/pid-eaa-data-model.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/en/pid-eaa-data-model.rst b/docs/en/pid-eaa-data-model.rst index dda139908..90e7f7c5e 100644 --- a/docs/en/pid-eaa-data-model.rst +++ b/docs/en/pid-eaa-data-model.rst @@ -107,9 +107,9 @@ The following claims MUST be in the JWT payload and MUST NOT be included in the * - **cnf** - JSON object containing the proof-of-possession key materials. By including a **cnf** (confirmation) claim in a JWT, the issuer of the JWT declares that the Holder is in control of the private key related to the public one defined in the **cnf** parameter. The recipient MUST cryptographically verify that the Holder is in control of that key. - `[RFC7800, Section 3.1] `_. - * - **type** + * - **vct** - 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] `__. + - `[draft-terbu-sd-jwt-vc-latest. Section Type Claim] `__. * - **verified_claims** - JSON object containing the following sub-elements: @@ -532,7 +532,7 @@ The combined format for the PID issuance is represented below: .. code-block:: - eyJ0eXAiOiJ2YytzZC1qd3QiLCJhbGciOiJSUzUxMiIsImtpZCI6ImQxMjZhNmE4NTZmNzcyNDU2MDQ4NGZhOWRjNTlkMTk1IiwidHJ1c3RfY2hhaW4iOlsiTkVoUmRFUnBZbmxIWTNNNVdsZFdUV1oyYVVobSAuLi4iLCJleUpoYkdjaU9pSlNVekkxTmlJc0ltdHBaQ0k2IC4uLiIsIklrSllkbVp5Ykc1b1FVMTFTRkl3TjJGcVZXMUIgLi4uIl19.eyJpc3MiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLm9yZyIsInN1YiI6Ik56YkxzWGg4dURDY2Q3bm9XWEZaQWZIa3hac1JHQzlYcy4uLiIsImp0aSI6InVybjp1dWlkOjZjNWMwYTQ5LWI1ODktNDMxZC1iYWU3LTIxOTEyMmE5ZWMyYyIsImlhdCI6MTU0MTQ5MzcyNCwiZXhwIjoxNTQxNDkzNzI0LCJzdGF0dXMiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLm9yZy9zdGF0dXMiLCJjbmYiOnsiandrIjp7Imt0eSI6IlJTQSIsImUiOiJBUUFCIiwidXNlIjoic2lnIiwia2lkIjoiZDEyNmE2YTg1NmY3NzI0NTYwNDg0ZmE5ZGM1OWQxOTUiLCJhbGciOiJSUzI1NiIsIm4iOiJvaWFuczV3WUNXazR3RnRFU3RWWWNuX3hPdzllZEtNTkdIMzNfcTZfcEJJMFhhVFk3UDNhcFVnak8waXZrNWMxTlFBVlk2UFptY1BROFAxWTBjQkFDOVNUUm16dlR2RFFjT29jTGhWeTJabGNYVHUzOW9PR0xOcmE4X0xRc2FNQTM4NmxPX3FNVzQtdVk2RGJHWlk0dkhrU2N2QUM5RklaWURQYWZxV0JFUVVOVjJRT0ZNSDVWUG9paENUS0h3TUdYblpCYXRZT2JnNTd4U09VWC1idmhPX3NGTW0zazRSdnNYY3IzTUZvakFoTGZ3dXR1X2pLOWs3TjlLUl9tTmM1SXBpT3loWndfc1VtRjZTYW1ScXNTUHA0MktEMTBoUE1XMFlKVERNWXhCZEhyTUZlU01IWUlNWTRvQkJUNDNfX2E1NXpJTElfQ25JazQyNDF3T3ZHdncifX0sInR5cGUiOiJIZWFsdGhJbnN1cmFuY2VEYXRhIiwidmVyaWZpZWRfY2xhaW1zIjp7InZlcmlmaWNhdGlvbiI6eyJfc2QiOlsiMmpJUjE4Z2ZlQVNIWUdCMjdzN3NTM1NfaVE0eHhGSXhDUnlpb2hyQmZucyJdLCJ0cnVzdF9mcmFtZXdvcmsiOiJlaWRhcyIsImFzc3VyYW5jZV9sZXZlbCI6ImhpZ2gifSwiY2xhaW1zIjp7Il9zZCI6WyIxaXp0cTdib3Y2NHhUWWJEa1dGYzQ0X1ZqV2UwMjloWnFYZVVJbG9xVU40IiwiRU5ObzMxamZ6RnA4WTJEVzBSLWZJTWVXd2U3RUxHdkdvSE13TUJwdTE0RSIsIkZWMkNETld1VHFUZ09IYWZ0dlZhdW1CRjBPbG1ueXhNc3d5ZjR1SXhyaFkiLCJkWldqcTdtSlNTWC1YVElfSFd1RThCMng2SWRNNWxFLWRvRF95QnBLSmFvIiwiZ0hZaTE5ZnJiRF9pNEJvYVdFTk9qYzNsQ25NajRwYkdOUWNzQmpfUU00USJdfX0sIl9zZF9hbGciOiJzaGEtMjU2In0.PrVt9qpf1WmfoRKncGXw6loKRANomsL-foXMqMUIyK2AO0tWM5laveqRet9Bb5A0fPq7rxNQLU57ngV3o8VzKLhFkbKm1_wtA5XuZXBfz0qGCmIP6tZQu9yAvXy162h6_i4FOINyHoL8i5mNPFTHFY0nBYTyVkCScfBC2Ccv4i7RSALbpbpviTpoYVBzFWtdOKuuMED5XwKpW9-VF_JK11yaJJ880walzu5tZ3XAOb0KkfUS3sCmSkKO5wMm1SeaS7xL5iiPSnAMTMrlmKE6qcwAkdDX-hNeGzncwBjHASTWb2udayK8Cal-wFGDWrRWGq3mU0rfuxMIFkjv4gdi8Q + eyJhbGciOiJSUzI1NiIsImtpZCI6Iks2S2hpUDNrOC1XOWVHdk1SVTg0NVVwWVRTdEJsR0g4ejFKZl85czMtUWsifQ.eyJpc3MiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLm9yZyIsInN1YiI6Ik56YkxzWGg4dURDY2Q3bm9XWEZaQWZIa3hac1JHQzlYcy4uLiIsImp0aSI6InVybjp1dWlkOjZjNWMwYTQ5LWI1ODktNDMxZC1iYWU3LTIxOTEyMmE5ZWMyYyIsImlhdCI6MTU0MTQ5MzcyNCwiZXhwIjoxNTQxNDkzNzI0LCJzdGF0dXMiOiJodHRwczovL2lzc3Vlci5leGFtcGxlLm9yZy9zdGF0dXMiLCJjbmYiOnsiandrIjp7Imt0eSI6IlJTQSIsImUiOiJBUUFCIiwidXNlIjoic2lnIiwia2lkIjoiZDEyNmE2YTg1NmY3NzI0NTYwNDg0ZmE5ZGM1OWQxOTUiLCJhbGciOiJSUzI1NiIsIm4iOiJvaWFuczV3WUNXazR3RnRFU3RWWWNuX3hPdzllZEtNTkdIMzNfcTZfcEJJMFhhVFk3UDNhcFVnak8waXZrNWMxTlFBVlk2UFptY1BROFAxWTBjQkFDOVNUUm16dlR2RFFjT29jTGhWeTJabGNYVHUzOW9PR0xOcmE4X0xRc2FNQTM4NmxPX3FNVzQtdVk2RGJHWlk0dkhrU2N2QUM5RklaWURQYWZxV0JFUVVOVjJRT0ZNSDVWUG9paENUS0h3TUdYblpCYXRZT2JnNTd4U09VWC1idmhPX3NGTW0zazRSdnNYY3IzTUZvakFoTGZ3dXR1X2pLOWs3TjlLUl9tTmM1SXBpT3loWndfc1VtRjZTYW1ScXNTUHA0MktEMTBoUE1XMFlKVERNWXhCZEhyTUZlU01IWUlNWTRvQkJUNDNfX2E1NXpJTElfQ25JazQyNDF3T3ZHdncifX0sInR5cGUiOiJIZWFsdGhJbnN1cmFuY2VEYXRhIiwidmVyaWZpZWRfY2xhaW1zIjp7InZlcmlmaWNhdGlvbiI6eyJfc2QiOlsiMmpJUjE4Z2ZlQVNIWUdCMjdzN3NTM1NfaVE0eHhGSXhDUnlpb2hyQmZucyJdLCJ0cnVzdF9mcmFtZXdvcmsiOiJlaWRhcyIsImFzc3VyYW5jZV9sZXZlbCI6ImhpZ2gifSwiY2xhaW1zIjp7Il9zZCI6WyIxaXp0cTdib3Y2NHhUWWJEa1dGYzQ0X1ZqV2UwMjloWnFYZVVJbG9xVU40IiwiRU5ObzMxamZ6RnA4WTJEVzBSLWZJTWVXd2U3RUxHdkdvSE13TUJwdTE0RSIsIkZWMkNETld1VHFUZ09IYWZ0dlZhdW1CRjBPbG1ueXhNc3d5ZjR1SXhyaFkiLCJkWldqcTdtSlNTWC1YVElfSFd1RThCMng2SWRNNWxFLWRvRF95QnBLSmFvIiwiZ0hZaTE5ZnJiRF9pNEJvYVdFTk9qYzNsQ25NajRwYkdOUWNzQmpfUU00USJdfX0sIl9zZF9hbGciOiJzaGEtMjU2In0.vl5ELdx9d7smuDHHDfBGaUySolBe7O3RROqpHDkM3txvXJxgZcCwZQhbWN3sSrBkJgSZ_kFEs2ddYIVKE4bglASlBbSizC8CASdJlyDD3T_dyimA1r2bwSfsHTyrcG_SpoU5Ee9KS-Lr2PCQ3LmTc8_nhaeBGtZCO4B8oZI9bpD6zqms1Zr-ymaE0pYnnQ3aWOclhiLavVudKxLxZvYXTdMStjyNbwBXekVVOnAZuCTuXMsD_jah7_MkmJP_buJgq3u6TthctsORHp4pKuZeI_43Y728-Qg7mIDeL5_-j_vgXdu7FWVa0OSTjZJM27GCDzr2M8LAhApk4aeDoF1Cmw MDOC-CBOR ========= From 8c7dde57b38de32773ec1d9538ec0eaf4aedc581 Mon Sep 17 00:00:00 2001 From: Giuseppe De Marco Date: Mon, 6 Nov 2023 10:57:25 +0100 Subject: [PATCH 4/4] fix: Issuance detailed flow (#162) * fix: Issuance detailed flow * fix: Issuance detailed flow --- docs/en/pid-eaa-issuance.rst | 2 +- images/Low-Level-Flow-ITWallet-PID-QEAA-Issuance.svg | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/docs/en/pid-eaa-issuance.rst b/docs/en/pid-eaa-issuance.rst index a01ee45a4..d4a87a50b 100644 --- a/docs/en/pid-eaa-issuance.rst +++ b/docs/en/pid-eaa-issuance.rst @@ -84,7 +84,7 @@ The PID/(Q)EAA Issuance phase is based on the **Authorization Code Flow** with * .. figure:: ../../images/Low-Level-Flow-ITWallet-PID-QEAA-Issuance.svg :figwidth: 100% :align: center - :target: https://www.plantuml.com/plantuml/svg/bLJDRXit4BxpAGREeJQmGky24aIErLXeK0Yk0ryABAZTaJJrYjoIGodgeS_UuL9Yk79Zr8O1IUJypFSp_EXPEmwxJkd0reJT2frIlPnHGxqs35TVFRehq1w2KYlxBHtyvC7l9AhVMeDNyEuBRRPysmKSvzuwUyZfUdptfBiE6HP6HZ0D3Z47XQO5wQB-CtRfx9xQKxtLHSnoSJSE82L_1vXyW305ks9D1eusE9185M0Y5uSf7D4hvOnb1Bj71mTuztI_U9ohKuQ6ZZo3NSEZ2vwnXR9Hd7T8bawJ3zAdiMPDRWUyHV3OOSDaZMIFirIGxjBSFezxLoHKBZxVFtv-cCz_KnSKGRF5vjbBRSr3Wx8ca8V8X_GQxdv1ETH3TstQCtvY3pjatMhMvUmGoG0Ptw5cAVphfxb0QH5aB5eJkg78qs8sMThbAPuaVZbxW0VyAw1dk7ReUsiyrdpiiOAc8pHSKriDfUfc6-6O3Lx-hcMYhPKmbohbLEqzkWYXg5WUlvU1_ZaDTGCbarIjHaoEcBgaiNJNwqo-NiVJncWE3YMpB3nZHizPYq64lUwe9Jv2eOAYPChCQw8Jha-yrC5H1VYj9uU-9dEJ_1qDhgSm2qAYexzJdonAeK9HvaO5FMJIcnFLcETmtfVWeqkabcHHaueTYBU0YxlPxt1Fc-s0lecO3B_4BHDT35DG41rJGMHHFiZx3E3mbgJ2wHiqKLM4Ep4FFEFnXtUzitPT-X_MrertZ-qp6X14lIM1LYp8eznaKWS-og8boHkd3P-DRjlpbfmNy0TByJuuCoNazLGigtT-QgC4qnGxoR6J63lzyy2JyyrtJrP_c5StA-hVaiFcR01AF6LmcM_TDEXzFR1H9L8IeCAqWgCsrZIOlzGZHry-HOae-U-jzr8zAdnzoXp2n_4bkozaaf0skbDtMQj2ga_VRr_gLKABNXYhc3Fh5jTaQA0rzjzfhbBKJRasvsV-zilNkNh03NcEozDryTaenfmux0HK2ufCgYQ51rp95cdDVdQujwUDAz-Jh5E9B8jrcgxezh-b4LBp0pQG4PqKV7eGYpZFrfLmr4SPBkowVm40 + :target: https://www.plantuml.com/plantuml/svg/bLJVRzis47xdNt587vO0DlPke4MTn6kC5OEHfSXB086HplOj4gcHnwZUm_xs7KLPfkQqQ8C0KSZxyNtVVSUFdhNZqDHA1xOcDC_eb6hbZ4fgjM6u-EBHNO3s49Hwjb_JmIyUV2DHxTuQl81tdsctv-iwu3JtsjbkJDVJkqTTryYmDWB1bDZ7T0fD1TBbVnWswrlOEFjArL2CbFnqCFy0OG7scJKPEDZWG29LWBbST0iue5VA6Si8zXKTTF3kyMxzi5931kyHQl8CTjj_FxZW6Il8s_a8gQyX3USVf5rfpPPSqsTuhB5aiYQMoDEK2W92CDYNAOGPYLhhJtSFd-vNgp_KpHxBbqaca0SXFuBw3ULGzpsqgOvaYJqqoBhIh7E449c3W7Ie6M7p-yrA05S8qfosXAulyhXUpZTsCyIJn6-Mzt2FVmVq39TF1i2XRwtnMF2XnLayAMj2mmLLwJyfMfJxE4IpmpUE2e6tjodOfSfv6UqzkiXgsY2_UIym_nsWFfaho7LyIyNag1yHSaZmj3EQWyCXv5XXoOoUJvf7iLzrJHNn0JAr5IMdZVeboU1ou5i4HpF0hoqvz0MPgsJQw5gzW6KGVHpza_gCufzaXgpCbGgwpwIVJbGJtMRXk0J1HpT8BScYCXNhYFU0wzlbdt0dAzspBoCdm-Uy1T4Pc562Q8OPH1Nb3ta_4kX-9Ybpz0vD71_2hTW1Nl3mpRlMMRlDVGvRwwOxnlO53GYZrf9GonRXGMv6KPCUMT7ByqNOEMquCx6jicquRjstdVy-EBCWvEr2lAeRlx1n98iKEnzZvp5syLV7y-FDoQDI_BkxCwnWHGxBtXDFqOcKn4kCyo7eiaJlYrwYML8gqSkSF8EoCDQKE7uKcStFtw6adlosrdkf7iT-EMJsuTFuNFApsKb85Ishwt60sVnkJhVdGyofzGR9HtkgMrIu9KEzjh5_etcMegxUUeEkFtzPgNlSaUUuKNKTtv8CvjnXBQGgK6HIDIdSyqhsIBltgyDNcpuXVsI6EUNCic4DwB9kFpmQ4VNqgaKnefs2XpA-ZLcSP-joEkgZW0jD_Hy0 PID/(Q)EAA Issuance - Detailed flow diff --git a/images/Low-Level-Flow-ITWallet-PID-QEAA-Issuance.svg b/images/Low-Level-Flow-ITWallet-PID-QEAA-Issuance.svg index 9ccf93993..d4bacd980 100644 --- a/images/Low-Level-Flow-ITWallet-PID-QEAA-Issuance.svg +++ b/images/Low-Level-Flow-ITWallet-PID-QEAA-Issuance.svg @@ -1 +1,2 @@ -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 verifier and WIA-PoP6PAR Request (response_type, client_id, code_challenge, code_challenge_method, request, client_assertion_type, client_assertion=WIA~WIA-PoP)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, iss)11Authorization Response (code, state, iss)12generate DPoP key13generate DPoP proof and WIA-PoP for PID Provider token endpoint14Token Request with DPoP proof (client_id, grant_type, code, code_verifier, client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation,client_assertion=WIA~WIA-PoP, redirect_uri)15Token Response (access_token, token_type, expires_in, c_nonce, c_nonce_expires_in)16create proof of possession (c_nonce)17create DPoP proof for PID Provider credential endpoint18Credential Request with DPoP access_token and DPoP proof (credential_definition, format, proof)Register all the credential-relatedinformation for verification/revocation19Credential Response (format, credential, c_nonce, c_nonce_expires_in)20PID validity and status check21store credential \ No newline at end of file + +User's smartphoneUserUserBrowserBrowserWallet InstanceWallet InstancePID ProviderPID Provider1obtain your PID2yesobtain the list of the Trusted PID Providers3confirm the selection of PID Provider4okCheck PID Provider is part of the Federation and obtain its metadata5create PKCE code verifier and WIA-PoP6PAR Request (response_type,client_id,code_challenge,code_challenge_method,request,client_assertion_type,client_assertion=WIA~WIA-PoP)Check Wallet Provider is part of the FederationCheck 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, iss)11Authorization Response (code, state, iss)12generate DPoP key13generate DPoP proof and WIA-PoP for PID Provider token endpoint14Token Request with DPoP proof (client_id,grant_type,code,code_verifier,client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-client-attestation,client_assertion=WIA~WIA-PoP,redirect_uri)15Token Response (access_token, token_type, expires_in, c_nonce, c_nonce_expires_in)16create proof of possession (c_nonce)17create DPoP proof for PID Provider credential endpoint18Credential Request with DPoP access_token and DPoP proof (credential_definition, format, proof)Register all the credential-relatedinformation for verification/revocation19Credential Response (format, credential, c_nonce, c_nonce_expires_in)20PID validity and status check21store credential \ No newline at end of file