diff --git a/ewc-rfc002-present-verifiable-credentials.md b/ewc-rfc002-present-verifiable-credentials.md index 4409e03..f1bb684 100644 --- a/ewc-rfc002-present-verifiable-credentials.md +++ b/ewc-rfc002-present-verifiable-credentials.md @@ -1,598 +1,120 @@ -# EWC RFC003: Issue Person Identification Data (PID) - v1.0 +# EWC RFC002: Present Verifiable Credentials - v1.0 -**Authors:** - -* Mr Matteo Mirabelli (Infocert, Italy) +**Authors:** +* Mr George Padaytti (iGrant.io, Sweden) * Mr Lal Chandran (iGrant.io, Sweden) +* Dr Andreas Abraham (ValidatedID, Spain) -**Reviewers:** +**Reviewers:** -* Mr George Padayatti (iGrant.io, Sweden) +* Dr Nikos Triantafyllou (University of the Aegean, Greece) +* Mr Florin Coptil (Bosch, Germany) +* Mr Matteo Mirabelli (Infocert, Italy) +* Dr Mikael Linden (Vero, Finland) +* Mr Renaud Murat (Archipels, France) +* Mr. Sebastian Bickerle (Lissi ID, Germany) -**Status:** Ready for Review +**Status:** Approved for v1.0 release **Table of Contents** -- [EWC RFC003: Issue Person Identification Data (PID) - v1.0](#ewc-rfc003-issue-person-identification-data-pid---v10) -- [1.0 Summary](#10-summary) -- [2.0 Motivation](#20-motivation) -- [3.0 Messages](#30-messages) - - [Preliminary Steps for PID Issuance](#preliminary-steps-for-pid-issuance) - - [PID Credential Issuance Process](#pid-credential-issuance-process) - - [Post-Issuance Verification and Management](#post-issuance-verification-and-management) - - [3.1 Credential offer](#31-credential-offer) - - [3.2 Credential offer response](#32-credential-offer-response) - - [3.3 Discover request](#33-discover-request) - - [3.4 Discover response](#34-discover-response) - - [3.5 Authorization request](#35-authorization-request) - - [3.6 Authorization response](#36-authorization-response) - - [3.7 Token request](#37-token-request) - - [3.7.1 Authorisation code flow](#371-authorisation-code-flow) - - [3.7.2 Pre-authorised code flow](#372-pre-authorised-code-flow) - - [3.8 Token response](#38-token-response) - - [3.9 Credential request](#39-credential-request) - - [3.10 Credential response](#310-credential-response) - - [3.10.1 In-time](#3101--in-time) - - [3.10.2 Deferred](#3102-deferred) - - [3.11 Issuer Authorization Verification](#311-issuer-authorization-verification) - - [3.12 Check Wallet's Conformity](#312-check-wallets-conformity) -- [4.0 Alternate response format](#40-alternate-response-format) -- [5.0 Implementers](#50-implementers) -- [6.0 Reference](#60-reference) +- [EWC RFC002: Present Verifiable Credentials - v1.0](#ewc-rfc002-present-verifiable-credentials---v10) +- [1.0 Summary](#10summary) +- [2.0 Motivation](#20motivation) +- [3.0 Messages](#30messages) + - [3.1 Authorisation request](#31authorisation-request) + - [3.1.1 Scope Parameter Usage](#311-scope-parameter-usage) + - [3.2 Authorisation response](#32authorisation-response) +- [4.0 Alternate response format](#40alternate-response-format) +- [5.0 Implementers](#50implementers) +- [6.0 Reference](#60reference) - [Appendix A: Public key resolution](#appendix-a-public-key-resolution) -# 1.0 Summary - -This specification implements the OID4VCI workflow for issuing Person Identification Data (PID) credentials by government-approved identity providers within the European Wallet Ecosystem. It defines a standard process to minimize risks and ensure interoperability in issuing high-assurance PIDs across the EUDI wallet ecosystem, adhering to the requirements set forth in the ARF [2]. - -# 2.0 Motivation - -The EWC LSP must align with the standard protocol for issuing PID from trusted and accredited sources. This uniform approach serves as the foundation for enabling interoperability between identity providers and wallet holders throughout the EWC ecosystem. This RFC assumes that users are familiar with the chosen EWC protocols and standards, and can reference the original specifications when required. - -# 3.0 Messages - -The PID credential issuance process incorporates comprehensive steps to ensure the security, reliability, and compliance. This includes both an authorization flow and a pre-authorized flow, with additional preliminary and post-issuance steps to align with regulatory standards and security best practices. The process is illustrated below, incorporating the critical steps of Wallet Conformity, Trust Anchor Verification, Reliable Data Acquisition, PID Generation, Secure Issuance and Storage; Renewal and Revocation Policies Management it's not in scope of this rfc. +# 1.0 Summary -### Preliminary Steps for PID Issuance +This specification implements the OIDC4VP workflow for any verifier (relying party) as per reference specification [1]. This minimises risks towards interoperability across the European Wallet Ecosystem with a standard specification in the EUDI wallet ecosystem as per the ARF [2] requirements. -1. **Wallet Conformity:** Before initiating the PID issuance, the user's wallet must be confirmed to comply with established standards. This includes possessing an internal certificate from Certification Assessment Bodies (CAB) that validates its conformity, ensuring the wallet's capability to securely manage the PID and associated qualified electronic attestations. +# 2.0 Motivation -2. **Trust Anchor Verification:** The issuing entity's authorization within the Trust Anchor framework must be validated, ensuring it is listed as an authorized actor, thus guaranteeing that only verified entities can issue the PID. +The EWC LSP must align with the standard protocol for issuing credentials. This is the basis of interoperability between Verifiers (Relying Parties) and Holders across the EWC LSPs. The assumption is that the user is familiar with the EWC-chosen protocols and standards and can refer to original standards references when necessary. -3. **Data Acquisition from Reliable Sources:** Personal data used for PID generation must be sourced from authentic and current databases, such as civil registries, ensuring the PID credentials are based on accurate and up-to-date information. +# 3.0 Messages -### PID Credential Issuance Process - -The PID issuance follows detailed steps starting from the discovery of issuer capabilities, through authentication and authorization, leading to the actual credential issuance. The process is adapted to include the preliminary steps, ensuring a secure and compliant issuance path. +As shown in Figure 1 below, a individual using the wallet presents a credential to a verifier on the same device that the device the wallet resides on. ```mermaid sequenceDiagram - participant I as Individual using EUDI Wallet - participant TA as Trust Anchor - box PID Provisioning Services - participant O as Identity Provider - participant CI as Credential Issuer - participant AS as Authentic Source - end - - Note over I,CI: Discovery of Issuer Capabilities - - I->>CI: GET: Credential Offer URI - I->> CI: GET: /.well-known/openid-credential-issuer - CI-->> I: OpenID credential issuer configuration - I->> O: GET: /.well-known/oauth-authorization-server - O-->>I: OAuth authorization server metadata - - Note over I,TA: Issuer Authorization Verification - I->>TA: Request Issuer Authorization Status - TA-->>I: Confirm Issuer is Trusted - - Note over I,O: Authenticate, Authorize, Check Wallet's Conformity - opt authorized flow - I->>O: Authorization request (with WTA and WIA) - Note over O,AS: User Authentication - O->>O: User authentication - opt user data verified vs authentic source - O->>AS: Request Personal Identifier Data - AS-->>O: Provide Personal Identifier Data - end - O-->>I: Authorization response - end - - I->> O: Token request - Note right of I: hypotesis: WTA and WIA should be sent as parameters on token request - O-->>O: Wallet Unit attestation validation - O-->>O: Wallet Provider verification against Trust Framework - opt wallet attestations not valid - O-->>I: Error message response - end - - O->>O: authorization code validation - O-->>I: Token response - - Note over I,O: PID Generation and Secure Issuance - I->>O: POST: Credential request with access token - O->>CI: Credential request - Note over CI,AS: Data Acquisition from Authentic Source
or temporary storage (userInfo) - CI->>AS: Request Personal Identifier Data - AS-->>CI: Provide Personal Identifier Data - - CI-->>I: Credential response with PID, stored securely in wallet - -``` - -Figure 1: PID Issuance Process Incorporating Preliminary Checks - -The process highlights the integration of the new preliminary steps with the traditional authorization code flow and pre-authorized code flow, adhering to the OID4VCI specification. It ensures a robust framework for digital identity issuance, from initial compliance verification to the secure generation and storage of PID credentials, followed by ongoing management. - -### Post-Issuance Verification and Management - -Following the issuance of the PID, initial and periodic verification procedures are crucial to maintain the validity and integrity of the PID and its related electronic attestations. This includes checking for revocation status and ongoing compliance of both the wallet and issuer within the Trust Anchor framework. Additionally, policies for the renewal and revocation of PIDs and electronic attestations must be established to address changes in the individual's status, data breaches, or compliance issues. + participant I as Individual using EUDI Wallet + participant O as Organisational Wallet (Verifier) -## 3.1 Credential offer - -For PID credential issuance, the member state PID issuer will adopt RFC001 for credential offer pre-authorised code flow, using the credential_offer_uri parameter as shown below: - -``` -openid-credential-offer://?credential_offer_uri=https://identity-provider.gov/pid-credential-offer - -``` - -In this case, the `credential_offer_uri` query parameter contains the URL where the credential offer from the government-approved identity provider can be resolved. This approach ensures a streamlined user experience while maintaining the necessary information exchange for the PID issuance process. The holder wallet obtains the above by scanning a QR code for cross-device workflows or via a deeplink for same-device workflows. - -## 3.2 Credential offer response - -On resolving the `credential_offer_uri` query parameter, the issuer responds with details of the PID credential offer. The response format is adapted to the specific requirements of PID issuance and may include information such as the credential type related to personal identification and the applicable trust framework. The response can be in one of the following formats: - -```json -{ - "credential_issuer": "https://identity-provider.gov", - "credential_configuration_ids": [ - "eu.europa.ec.eudi.pid.1" - ], - "grants": { - "authorization_code": { - "issuer_state": "eyJhbGciOiJSU0Et...FYUaBy" - } - } -} + O->>+I: GET: Authorisation request + I->>+O: POST: Authorisation response ``` +Figure 1: Same Device Verification Flow based on [1] -The holder's wallet retrieves this JSON response and processes it accordingly. The format of the credential (e.g., jwt_vc, vc+sd-jwt) is specified, focusing on the PID. This process ensures that the credential issuance aligns with the stringent requirements for PID within the EWC ecosystem. +For cross device verification, there is an extra step to resolve the authoritsation request object from `request_uri` as given Figure 2 below: -For the pre-authorized flow, the credential response format is adapted to include the necessary grants for PID issuance: - -```json -{ - "credential_issuer": "https://identity-provider.gov", - "credential_configuration_ids": [ - { - "format": "vc+sd-jwt", - "types": [ - "VerifiableCredential", - "eu.europa.ec.eudi.pid.1" - ], - "trust_framework": { - "name": "ewc-issuer-trust-list", - "type": "Accreditation", - "uri": "Link to the issuer trust list" - } - } - ], - "grants": { - "urn:ietf:params:oauth:grant-type:pre-authorized_code": { - "pre-authorized_code": "eyJhbGciOiJSU0Et...FYUaBy", - "user_pin_required": true - } - } -} +```mermaid + sequenceDiagram + participant I as Individual using EUDI Wallet + participant O as Organisational Wallet (Verifier) + + O->>+I: GET: Authorisation request (`request_uri`) + I->>+O: GET: Request object, resolved from the `request_uri` + O->>+I: Respond with the Request object + I->>+O: POST: VP token response + O->>+I: Redirect: Authorisation response ``` +Figure 2: Cross Device Verification Flow based on [1] -## 3.3 Discover request +## 3.1 Authorisation request -The holder's wallet initiates a request to discover the government identity provider’s authorization server configurations, essential for PID credential issuance. To obtain the issuer's configurations, the wallet resolves the /.well-known/openid-credential-issuer endpoint using the credential_issuer URI found in the PID credential offer response (as per EWC RFC001): +Authorisation requests can be presented to the wallet by verifying in two ways: 1) by value 2) by reference as defined in JWT-Secured Authorization Request (JAR) via use of `request_uri` [3]. The custom URL scheme for authorisation requests is `openid4vp://`. An example by value is as given below: -```http -GET https://identity-provider.gov/.well-known/openid-credential-issuer +```sh +openid4vp://?client_id=https://example.verifier.com +&response_type=vp_token +&response_uri=https://example.verifier.com/direct_post +&response_mode=direct_post +&state=100b8521-461e-4f79-931e-ea5710c4fa5c +&nonce=e6759e72-37e4-42f7-ab48-a9368971620f +&presentation_definition={"id":+"2e3975b7-4834-4650-a97b-5c4f1cdf5f57",+"format":+{"jwt_vc":+{"alg":+["ES256"]},+"jwt_vp":+{"alg":+["ES256"]}},+"input_descriptors":+[{"id":+"841fd89b-f987-4052-88fc-30affccfd99c",+"constraints":+{"fields":+[{"path":+["$.type"],+"filter":+{"type":+"array",+"contains":+{"const":+"VerifiablePortableDocumentA1"}}}]}}]} ``` -Subsequently, the wallet requests the authorization server metadata endpoint to retrieve metadata (openid and oauth standard samples): +If `request_uri` field is present in the authorisation request, it means the authorisation request is presented by reference. Request URI has to be resolved to obtain the JWT, which contains the above fields in the claims. An example is as given below: -```http -GET https://identity-provider.gov/.well-known/openid-configuration -GET https://identity-provider.gov/.well-known/oauth-authorization-server +```sh +openid4vp://?request_uri=https://server.example.com/presentation-request ``` -## 3.4 Discover response - -Upon resolving the well-known endpoints, the **identity provider** responds with its configuration, tailored to support PID credential issuance. The response includes details about supported credentials, endpoints for issuing and managing credentials. It also specifies the cryptographic methods and trust frameworks applicable for PID credentials, as defined by [6]: - -```json -{ - "credential_issuer": "https://identity-provider.gov", - "authorization_server": "https://identity-provider.gov", - "credential_endpoint": "https://identity-provider.gov/credential", - "deferred_credential_endpoint": "https://identity-provider.gov/credential_deferred", - "display": [ - { - "name": "Government Identity Provider", - "location": "Country", - "locale": "en-GB", - "cover": { - "url": "https://identity-provider.gov/cover.jpeg", - "alt_text": "Government Identity Provider" - }, - "logo": { - "url": "https://identity-provider.gov/logo.jpg", - "alt_text": "Government Identity Provider" - }, - "description": "For inquiries about how we manage your personal identification data, please contact our Data Protection Officer." - } - ], - "credentials_configuration_supported": { - "eu.europa.ec.eudi.pid_jwt_vc_json": { - "format": "vc+sd-jwt", - "scope": "eu.europa.ec.eudi.pid_jwt_vc_json", - "cryptographic_binding_methods_supported": [ - "jwk" - ], - "cryptographic_suites_supported": [ - "ES256" - ], - "display": [ - { - "name": "Personal Identification Data", - "locale": "en-GB", - "background_color": "#000000", - "text_color": "#FFFFFF" - } - ], - "vct": "eu.europa.ec.eudi.pid_jwt_vc_json", - "claims": { - "address": { - "display": [ - { - "locale": "en", - "name": "Resident street_address, country, region, locality and postal_code" - } - ], - "mandatory": false - }, - "administrative_number": { - "display": [ - { - "locale": "en", - "name": "Alpha-2 country code, representing the nationality of the PID User." - } - ], - "mandatory": false - }, - "age_in_years": { - "display": [ - { - "locale": "en", - "name": "The subject’s current age in years." - } - ], - "mandatory": false - }, - "age_over_18": { - "display": [ - { - "locale": "en", - "name": "Adult or minor" - } - ], - "mandatory": true - }, - "birth_date": { - "display": [ - { - "locale": "en", - "name": "Date of Birth" - } - ], - "mandatory": true, - "value_type": "full-date" - }, - "birth_family_name": { - "display": [ - { - "locale": "en", - "name": "Last name(s) or surname(s) of the PID User at the time of birth." - } - ], - "mandatory": false - }, - "birth_given_name": { - "display": [ - { - "locale": "en", - "name": "First name(s), including middle name(s), of the PID User at the time of birth." - } - ], - "mandatory": false - }, - "birthdate_year": { - "display": [ - { - "locale": "en", - "name": "test" - } - ], - "mandatory": false - }, - "document_number": { - "display": [ - { - "locale": "en", - "name": "Alpha-2 country code, representing the nationality of the PID User." - } - ], - "mandatory": false - }, - "expiry_date": { - "display": [ - { - "locale": "en", - "name": "Alpha-2 country code, representing the nationality of the PID User." - } - ], - "mandatory": true - }, - "family_name": { - "display": [ - { - "locale": "en", - "name": "Current Family Name" - } - ], - "mandatory": true, - "value_type": "string" - }, - "gender": { - "display": [ - { - "locale": "en", - "name": "PID User’s gender, using a value as defined in ISO/IEC 5218." - } - ], - "mandatory": false - }, - "given_name": { - "display": [ - { - "locale": "en", - "name": "Current First Names" - } - ], - "mandatory": true, - "value_type": "string" - }, - "issuance_date": { - "display": [ - { - "locale": "en", - "name": "Alpha-2 country code, representing the nationality of the PID User." - } - ], - "mandatory": true - }, - "issuing_authority": { - "display": [ - { - "locale": "en", - "name": "Alpha-2 country code, representing the nationality of the PID User." - } - ], - "mandatory": true - }, - "issuing_country": { - "display": [ - { - "locale": "en", - "name": "Alpha-2 country code, representing the nationality of the PID User." - } - ], - "mandatory": true - }, - "issuing_jurisdiction": { - "display": [ - { - "locale": "en", - "name": "Alpha-2 country code, representing the nationality of the PID User." - } - ], - "mandatory": false - }, - "nationalities": { - "display": [ - { - "locale": "en", - "name": "Array of nationalities" - } - ], - "mandatory": false - }, - "place_of_birth": { - "display": [ - { - "locale": "en", - "name": "The country, region, and locality" - } - ], - "mandatory": false - }, - "portrait": { - "display": [ - { - "locale": "en", - "name": "Alpha-2 country code, representing the nationality of the PID User." - } - ], - "mandatory": false - }, - "portrait_capture_date": { - "display": [ - { - "locale": "en", - "name": "Alpha-2 country code, representing the nationality of the PID User." - } - ], - "mandatory": false - } - }, - - } - } -} - -``` - -Once the well-known endpoint for **authorization server** configuration is resolved, the response will follow the oauth standard or openid specification - -> Currently, we retain the trust framework specified by EBSI. Subsequently, we will specify an additional RFC defining the EWC trusted issuer list. - -## 3.5 Authorization request - -The authorization request seeks permission to access the PID credential endpoint. Here is an adapted example of this request, specifically aimed at PID issuance by a government identity provider: - -```http -GET https://identity-provider.gov/auth/authorize? - -&response_type=code -&scope=openid -&issuer_state=uniqueStateIdentifier -&state=client-state -&client_id=did%3Akey%3Az2dmzD81cgPx8Vki7JbuuMmFYrWPgYoytykUZ3eyqht1j9KbsEYvdrjxMjQ4tpnje9BDBTzuNDP3knn6qLZErzd4bJ5go2CChoPjd5GAH3zpFJP5fuwSk66U5Pq6EhF4nKnHzDnznEP8fX99nZGgwbAh1o7Gj1X52Tdhf7U4KTk66xsA5r -&authorization_details%3D%5B%7B%22format%22%3A%22jwt_vc%22%2C%22locations%22%3A%5B%22https%3A%2F%2Fissuer.example.com%22%5D%2C%22type%22%3A%22openid_credential%22%2C%22types%22%3A%5B%22eu.europa.ec.eudi.pid.1%22%5D%7D%5D -&redirect_uri=openid%3A -&nonce=glkFFoisdfEui43 -&code_challenge=YjI0ZTQ4NTBhMzJmMmZhNjZkZDFkYzVhNzlhNGMyZDdjZDlkMTM4YTY4NjcyMTA5M2Q2OWQ3YjNjOGJlZDBlMSAgLQo%3D -&code_challenge_method=S256 -&client_metadata=%7B%22vp_formats_supported%22%3A%7B%22jwt_vp%22%3A%7B%22alg%22%3A%5B%22ES256%22%5D%7D%2C%22jwt_vc%22%3A%7B%22alg%22%3A%5B%22ES256%22%5D%7D%7D%2C%22response_types_supported%22%3A%5B%22vp_token%22%2C%22id_token%22%5D%2C%22authorization_endpoint%22%3A%22openid%3A%2F%2F%22%7D - -Host: https://identity-provider.gov -``` +> [!NOTE] +> The above authorisation request can be presented to the holder wallet as a QR code, a link or as NFC blip. For QR code based presentation, it is recommended to use the `request_uri` as **it makes the QR code compact**. -Query params for the authorisation request are given below: +The authorisation request will contain the following fields: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
response_type - The value must be ‘code’ -
scope - The value must be ‘openid’ -
state - The client uses an opaque value to maintain the state between the request and callback. -
client_id Decentralised identifier -
authorization_details - As specified in OAuth 2.0 Rich Authorization Requests specification to specify fine-grained access [4]. An example is as given below: - - ```json - { - "type": "openid_credential", - "locations": [ - "https://credential-issuer.example.com" - ], - "format": "jwt_vc_json", - "credential_definition": { - "type": [ - "eu.europa.ec.eudi.pid.1" - ] - } - } - ``` - + Verifier identifier for .e.g URI / DID. This value must be present in sub field of the verifiable presentation JWT
redirect_uri - For redirection of the response -
code_challenge - As specified in PKCE for OAuth Public Client specification [5] -
code_challenge_method - As specified in PKCE for OAuth Public Client specification -
client_metadata - Holder wallets are non-reachable and can utilise this field in the Authorisation Request to deliver configuration -
issuer_state - If present in the credential offer -
- -> Note 1: the wallet trust attestation and the wallet instance attestantion could be requested to the user as string parameters or through an engagement using qrcode. - -> Note 2: In the authorization flow, we assume that the user will be asked to authenticate and optionally personal data will be collected and stored by identity provider. - -## 3.6 Authorization response - -In the context of PID credential issuance, the government identity provider may **optionally** request additional details for enhanced authentication, such as DID verification. In scenarios necessitating this heightened security, the authorization response will include a `response_type` parameter set to `direct_post`. An example of such a response is: - -```http -HTTP/1.1 302 Found -Location: http://localhost:8080?state=22857405-1a41-4db9-a638-a980484ecae1&client_id=https%3A%2F%2Fapi-conformance.ebsi.eu%2Fconformance%2Fv3%2Fauth-mock&redirect_uri=https%3A%2F%2Fapi-conformance.ebsi.eu%2Fconformance%2Fv3%2Fauth-mock%2Fdirect_post&response_type=id_token&response_mode=direct_post&scope=openid&nonce=a6f24536-b109-4623-a41a-7a9be932bdf6&request_uri=https%3A%2F%2Fapi-conformance.ebsi.eu%2Fconformance%2Fv3%2Fauth-mock%2Frequest_uri%2F111d2819-9ab7-4959-83e5-f414c57fdc27 -``` -Query params for the authorisation response are given below: - - - - - - - - - - - - - @@ -602,228 +124,103 @@ Query params for the authorisation response are given below: - - - - -
state - The client uses an opaque value to maintain the state between the request and callback. -
client_id + response_type Decentralised identifier + The value must be vp_token
redirect_uri + scope For redirection of the response + Optional value, details are specified in [Section 3.1.1](#3.1.1-scope-parameter-usage)
response_type + response_uri The value must be id_token if the issuer requests DID authentication. + This should be present when the response_mode is direct_post.
scope + state The value must be openid + The client uses an opaque value to maintain the state between the request and callback.
nonce A value used to associate a client session with an ID token and to mitigate replay attacks + Securely bin verifiable presentations provided by the wallet to a particular transaction
request_uri + presentation_definition The authorisation server’s private key signed the request. + The verifier requires proof. It must conform to the DIF Presentation Exchange specification [4].
-Following this protocol, the holder wallet is expected to respond with an id_token signed by its DID to the direct post endpoint, completing the authentication: - -```http -POST /direct_post -Content-Type: application/x-www-form-urlencoded -&id_token=eyJraWQiOiJkaW...a980484ecae1 -``` - -If no additional details are requested, the identity provider issues an authorization response containing a `code` parameter with a short-lived authorization code. This streamlined response facilitates a quick and secure exchange, vital for the sensitive nature of PID credential issuance: - -```http -HTTP/1.1 302 Found -Location: https://Wallet.example.org/cb?code=SplxlOBeZQQYbYS6WxSbIA -``` - > [!NOTE] -> The above can be deeplinked to the EUDI wallet as well. - -## 3.7 Token request - -This step foresees the wallet attestation validation and trustworthiness of wallet instance and its provider. -> Note: The validation of wallet is based on wallet unit attestation (rif RFC004 [https://github.com/EWC-consortium/eudi-wallet-rfcs/blob/main/ewc-rfc004-individual-wallet-attestation.md]) - -### 3.7.1 Authorisation code flow - -For PID credential issuance, the token request using the authorization code flow is structured as follows: - -```http -POST /token HTTP/1.1 -Host: identity-provider.gov -Content-Type: application/x-www-form-urlencoded -Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW - -&grant_type=authorization_code -&code=SplxlOBeZQQYbYS6WxSbIA -&code_verifier=dBjftJeZ4CVP-mB92K27uhbUJU1p1r_wW1gFWFOEjXk -&redirect_uri=https%3A%2F%2FWallet.example.org%2Fcb +> The authorisation request within EWC context only supports `direct_post` as `response_mode` due to security concerns that come with the alternative method using redirect URIs. + +### [3.1.1 Scope Parameter Usage](#3.1.1-scope-parameter-usage) + +According to OIDCVP draft version >= 18, the scope parameter can be used as an optional parameter to request verifiable presentations using the scope parameter. When this parameter is presented, it must fulfill the following requirements: + +1. The scope value MUST serve as an alias for a well-defined Presentation Definition, which will be referenced in the `presentation_submission` response parameter. +2. Scope value definition MUST enable Verifiers to determine: + * **Presentation definition** `definition_id` and **Input Descriptor(s)** `descriptor_map.id` in the `presentation_submission` response parameter + * **Credential formats and types** in the `vp_token` response parameter +3. It is RECOMMENDED to use collision-resistant scope values. +4. An example could be: `scope=com.example.passport_credential_presentation` +5. The specific scope values and their mapping to Presentation Definitions are not defined in this specification. + +An example usage of `scope` parameter is as given below: + +```sh +openid4vp://?client_id=https://example.verifier.com +&response_type=vp_token +&scope=com.example.passport_credential_presentation +&response_uri=https://example.verifier.com/direct_post +&response_mode=direct_post +&state=100b8521-461e-4f79-931e-ea5710c4fa5c +&nonce=e6759e72-37e4-42f7-ab48-a9368971620f ``` -This request is made with the following query params: +## 3.2 Authorisation response - - - - - - - - - - - - - - - - - -
grant_type - Grant type for authorisation. E.g. authorization_code -
client_id - Decentralised identifier -
code - Authorisation code -
code_verifier - Wallet-generated secure random token used to validate the original code_challenge provided in the initial Authorization Request -
- -### 3.7.2 Pre-authorised code flow - -In scenarios where a pre-authorized code is used, the token request is structured as follows: - -```http -POST /token HTTP/1.1 -Host: identity-provider.gov -Content-Type: application/x-www-form-urlencoded +Authorisation response is sent by constructing the `vp_token` and `presentation_submission` values. An example `vp_token` is as given: -&grant_type=urn:ietf:params:oauth:grant-type:pre-authorized_code -&pre-authorized_code=SplxlOBeZQQYbYS6WxSbIA -&user_pin=493536 +```jwt +eyJraWQiOiJkaWQ6a2V5OnoyZG16RDgxY2dQeDhWa2k3SmJ1dU1tRllyV1BnWW95dHlrVVozZXlxaHQxajlLYnJXd2pEYnJ2eDlIaHpBNWJlNEplaFJ2WlRvRGpRb0g4V0hkQURVeDlQeFpYRXVLUURYdDVkdXQ4QlpMaGpoaFNIanZtanROM3gyZzRqZlFNUXhjVWVZbzV3RTRTUmd0QTVDUWt6b3VjUVk5eVpjR0pLTXk4ZVVzQUZHZnpZNnBtNVcjejJkbXpEODFjZ1B4OFZraTdKYnV1TW1GWXJXUGdZb3l0eWtVWjNleXFodDFqOUticld3akRicnZ4OUhoekE1YmU0SmVoUnZaVG9EalFvSDhXSGRBRFV4OVB4WlhFdUtRRFh0NWR1dDhCWkxoamhoU0hqdm1qdE4zeDJnNGpmUU1ReGNVZVlvNXdFNFNSZ3RBNUNRa3pvdWNRWTl5WmNHSktNeThlVXNBRkdmelk2cG01VyIsInR5cCI6IkpXVCIsImFsZyI6IkVTMjU2IiwiandrIjp7Imt0eSI6IkVDIiwiY3J2IjoiUC0yNTYiLCJ4IjoiZTZsZXVsQThCS3otQ1lDVHMyUkowbzhjSDZTb1h0QXY2MmIwRUV5WDN4dyIsInkiOiJiRG10anZCYmlfRktBbEdCRFM5bkVfWUN2bF9pbjNsQ19nbkpDNHU5bkgwIn19.eyJhdWQiOiJodHRwczpcL1wvc3dlZGVuLWV1ZGktd2FsbGV0LmlncmFudC5pbyIsInN1YiI6ImRpZDprZXk6ejJkbXpEODFjZ1B4OFZraTdKYnV1TW1GWXJXUGdZb3l0eWtVWjNleXFodDFqOUticld3akRicnZ4OUhoekE1YmU0SmVoUnZaVG9EalFvSDhXSGRBRFV4OVB4WlhFdUtRRFh0NWR1dDhCWkxoamhoU0hqdm1qdE4zeDJnNGpmUU1ReGNVZVlvNXdFNFNSZ3RBNUNRa3pvdWNRWTl5WmNHSktNeThlVXNBRkdmelk2cG01VyIsIm5iZiI6MTcwNzEzMjYzNywiaXNzIjoiZGlkOmtleTp6MmRtekQ4MWNnUHg4VmtpN0pidXVNbUZZcldQZ1lveXR5a1VaM2V5cWh0MWo5S2JyV3dqRGJydng5SGh6QTViZTRKZWhSdlpUb0RqUW9IOFdIZEFEVXg5UHhaWEV1S1FEWHQ1ZHV0OEJaTGhqaGhTSGp2bWp0TjN4Mmc0amZRTVF4Y1VlWW81d0U0U1JndEE1Q1Frem91Y1FZOXlaY0dKS015OGVVc0FGR2Z6WTZwbTVXIiwidnAiOnsiaG9sZGVyIjoiZGlkOmtleTp6MmRtekQ4MWNnUHg4VmtpN0pidXVNbUZZcldQZ1lveXR5a1VaM2V5cWh0MWo5S2JyV3dqRGJydng5SGh6QTViZTRKZWhSdlpUb0RqUW9IOFdIZEFEVXg5UHhaWEV1S1FEWHQ1ZHV0OEJaTGhqaGhTSGp2bWp0TjN4Mmc0amZRTVF4Y1VlWW81d0U0U1JndEE1Q1Frem91Y1FZOXlaY0dKS015OGVVc0FGR2Z6WTZwbTVXIiwiaWQiOiJ1cm46dXVpZDo3OGQ3NjY1ZC00NWEzLTQwZTgtYWEzYS1mZTAwYjlhNTkxMWMiLCJ0eXBlIjpbIlZlcmlmaWFibGVQcmVzZW50YXRpb24iXSwiQGNvbnRleHQiOlsiaHR0cHM6XC9cL3d3dy53My5vcmdcLzIwMThcL2NyZWRlbnRpYWxzXC92MSJdLCJ2ZXJpZmlhYmxlQ3JlZGVudGlhbCI6WyJleUpoYkdjaU9pSkZVekkxTmlJc0ltdHBaQ0k2SW1ScFpEcHJaWGs2ZWpKa2JYcEVPREZqWjFCNE9GWnJhVGRLWW5WMVRXMUdXWEpYVUdkWmIzbDBlV3RWV2pObGVYRm9kREZxT1V0aWMyTllZVEYxUjI5bGJubG1iVlY1V1V0a1RWQldRMmRDVWtwQmQwVkdhVWd5UTFscWRIbG1abXRNVERGelpGTlRXbTVRY2twdGIwZE9abTE2UzFoR04yMDJTMEZ4TVZkalpYVkxVbFpUU2tWeGNYVnZRa2g2UVdWcFptMXpUVzFHZG1GSWFWVmFjRWh5Um1ab2EyaHplR1puVWxabmNXUlNkamwzYVdFM1pEVlpPQ042TW1SdGVrUTRNV05uVUhnNFZtdHBOMHBpZFhWTmJVWlpjbGRRWjFsdmVYUjVhMVZhTTJWNWNXaDBNV281UzJKelkxaGhNWFZIYjJWdWVXWnRWWGxaUzJSTlVGWkRaMEpTU2tGM1JVWnBTREpEV1dwMGVXWm1hMHhNTVhOa1UxTmFibEJ5U20xdlIwNW1iWHBMV0VZM2JUWkxRWEV4VjJObGRVdFNWbE5LUlhGeGRXOUNTSHBCWldsbWJYTk5iVVoyWVVocFZWcHdTSEpHWm1ocmFITjRabWRTVm1keFpGSjJPWGRwWVRka05WazRJaXdpZEhsd0lqb2lTbGRVSW4wLmV5SmxlSEFpT2pFM01EY3hNell4T1RBc0ltbGhkQ0k2TVRjd056RXpNalU1TUN3aWFYTnpJam9pWkdsa09tdGxlVHA2TW1SdGVrUTRNV05uVUhnNFZtdHBOMHBpZFhWTmJVWlpjbGRRWjFsdmVYUjVhMVZhTTJWNWNXaDBNV281UzJKelkxaGhNWFZIYjJWdWVXWnRWWGxaUzJSTlVGWkRaMEpTU2tGM1JVWnBTREpEV1dwMGVXWm1hMHhNTVhOa1UxTmFibEJ5U20xdlIwNW1iWHBMV0VZM2JUWkxRWEV4VjJObGRVdFNWbE5LUlhGeGRXOUNTSHBCWldsbWJYTk5iVVoyWVVocFZWcHdTSEpHWm1ocmFITjRabWRTVm1keFpGSjJPWGRwWVRka05WazRJaXdpYW5ScElqb2lkWEp1T21ScFpEbzFPV1k0TWpOa01TMHdNakl5TFRRMU0yUXRPR00yWlMwMU1XVXdNalUxTm1KaU1EWWlMQ0p1WW1ZaU9qRTNNRGN4TXpJMU9UQXNJbk4xWWlJNklpSXNJblpqSWpwN0lrQmpiMjUwWlhoMElqcGJJbWgwZEhCek9pOHZkM2QzTG5jekxtOXlaeTh5TURFNEwyTnlaV1JsYm5ScFlXeHpMM1l4SWwwc0ltTnlaV1JsYm5ScFlXeFRZMmhsYldFaU9sdDdJbWxrSWpvaWFIUjBjSE02THk5aGNHa3RZMjl1Wm05eWJXRnVZMlV1WldKemFTNWxkUzkwY25WemRHVmtMWE5qYUdWdFlYTXRjbVZuYVhOMGNua3Zkakl2YzJOb1pXMWhjeTk2TTAxblZVWlZhMkkzTWpKMWNUUjRNMlIyTlhsQlNtMXVUbTE2UkVabFN6VlZRemg0T0ROUmIyVk1TazBpTENKMGVYQmxJam9pUm5Wc2JFcHpiMjVUWTJobGJXRldZV3hwWkdGMGIzSXlNREl4SW4xZExDSmpjbVZrWlc1MGFXRnNVM1ZpYW1WamRDSTZleUpwWkNJNmJuVnNiQ3dpYzJWamRHbHZiakVpT25zaVpHRjBaVUpwY25Sb0lqb2lNVGsyT0MweE1pMHlPU0lzSW1admNtVnVZVzFsY3lJNklrTm9ZWEpzYjNSMFpTSXNJbTVoZEdsdmJtRnNhWFJwWlhNaU9sc2lVMFVpWFN3aWNHVnljMjl1WVd4SlpHVnVkR2xtYVdOaGRHbHZiazUxYldKbGNpSTZJakU1TmpneE1qSTVMVEUwTVRJaUxDSndiR0ZqWlVKcGNuUm9JanA3SW1OdmRXNTBjbmxEYjJSbElqb2lVMFVpTENKeVpXZHBiMjRpT2lKVGRHOWphMmh2YkcwaUxDSjBiM2R1SWpvaVUzUnZZMnRvYjJ4dEluMHNJbk5sZUNJNklrWmxiV0ZzWlNJc0luTjBZWFJsVDJaU1pYTnBaR1Z1WTJWQlpHUnlaWE56SWpwN0ltTnZkVzUwY25sRGIyUmxJam9pVTBVaUxDSndiM04wUTI5a1pTSTZJalF4T0NBM09DSXNJbk4wY21WbGRFNXZJam9pUjNWdWJtRnlJRVZ1WjJWc2JHRjFjeUIyWVdjZ09Dd2dPVEVnTVVJaUxDSjBiM2R1SWpvaVUzUnZZMnRvYjJ4dEluMHNJbk4wWVhSbFQyWlRkR0Y1UVdSa2NtVnpjeUk2ZXlKamIzVnVkSEo1UTI5a1pTSTZJbE5GSWl3aWNHOXpkRU52WkdVaU9pSTBNVGdnTnpnaUxDSnpkSEpsWlhST2J5STZJa2QxYm01aGNpQkZibWRsYkd4aGRYTWdkbUZuSURnc0lEa3hJREZDSWl3aWRHOTNiaUk2SWxOMGIyTnJhRzlzYlNKOUxDSnpkWEp1WVcxbElqb2lRVzVrWlhKemIyNGlMQ0p6ZFhKdVlXMWxRWFJDYVhKMGFDSTZJa0Z1WkdWeWMyOXVJbjBzSW5ObFkzUnBiMjR5SWpwN0ltTmxjblJwWm1sallYUmxSbTl5UkhWeVlYUnBiMjVCWTNScGRtbDBlU0k2ZEhKMVpTd2laR1YwWlhKdGFXNWhkR2x2YmxCeWIzWnBjMmx2Ym1Gc0lqcG1ZV3h6WlN3aVpXNWthVzVuUkdGMFpTSTZJakl3TWpRdE1EY3RNRE1pTENKdFpXMWlaWEpUZEdGMFpWZG9hV05vVEdWbmFYTnNZWFJwYjI1QmNIQnNhV1Z6SWpvaVNWUWlMQ0p6ZEdGeWRHbHVaMFJoZEdVaU9pSXlNREl6TFRBNUxUSXhJaXdpZEhKaGJuTnBkR2x2YmxKMWJHVnpRWEJ3YkhsQmMwVkRPRGd6TWpBd05DSTZabUZzYzJWOUxDSnpaV04wYVc5dU15STZleUpqYVhacGJFRnVaRVZ0Y0d4dmVXVmtVMlZzWmtWdGNHeHZlV1ZrSWpwbVlXeHpaU3dpWTJsMmFXeFRaWEoyWVc1MElqcG1ZV3h6WlN3aVkyOXVkSEpoWTNSVGRHRm1aaUk2Wm1Gc2MyVXNJbVZ0Y0d4dmVXVmtRVzVrVTJWc1prVnRjR3h2ZVdWa0lqcG1ZV3h6WlN3aVpXMXdiRzk1WldSVWQyOVBjazF2Y21WVGRHRjBaWE1pT21aaGJITmxMQ0psZUdObGNIUnBiMjRpT21aaGJITmxMQ0psZUdObGNIUnBiMjVFWlhOamNtbHdkR2x2YmlJNklpSXNJbVpzYVdkb2RFTnlaWGROWlcxaVpYSWlPbVpoYkhObExDSnRZWEpwYm1WeUlqcG1ZV3h6WlN3aWNHOXpkR1ZrUlcxd2JHOTVaV1JRWlhKemIyNGlPbVpoYkhObExDSndiM04wWldSVFpXeG1SVzF3Ykc5NVpXUlFaWEp6YjI0aU9uUnlkV1VzSW5ObGJHWkZiWEJzYjNsbFpGUjNiMDl5VFc5eVpWTjBZWFJsY3lJNlptRnNjMlVzSW5kdmNtdHBibWRKYmxOMFlYUmxWVzVrWlhJeU1TSTZabUZzYzJWOUxDSnpaV04wYVc5dU5DSTZleUpsYlhCc2IzbGxaU0k2Wm1Gc2MyVXNJbVZ0Y0d4dmVXVnlVMlZzWmtWdGNHeHZlV1ZrUVdOMGFYWnBkSGxEYjJSbGN5STZXeUl4T0RnNU1URXpNalEwSWwwc0ltNWhiV1ZDZFhOcGJtVnpjMDVoYldVaU9pSldiMngyYnlJc0luSmxaMmx6ZEdWeVpXUkJaR1J5WlhOeklqcDdJbU52ZFc1MGNubERiMlJsSWpvaVUwVWlMQ0p3YjNOMFEyOWtaU0k2SWpReE9DQTNPQ0lzSW5OMGNtVmxkRTV2SWpvaVIzVnVibUZ5SUVWdVoyVnNiR0YxY3lCMlhIVXdNR1UwWnlBNExDQXhOalFnUVNJc0luUnZkMjRpT2lKSGIzUmxZbTl5WnlKOUxDSnpaV3htUlcxd2JHOTVaV1JCWTNScGRtbDBlU0k2ZEhKMVpYMHNJbk5sWTNScGIyNDFJanA3SW01dlJtbDRaV1JCWkdSeVpYTnpJanBtWVd4elpTd2lkMjl5YTFCc1lXTmxRV1JrY21WemMyVnpJanBiZXlKaFpHUnlaWE56SWpwN0ltTnZkVzUwY25sRGIyUmxJam9pU1ZRaUxDSndiM04wUTI5a1pTSTZJak0wTVRNeUlpd2ljM1J5WldWMFRtOGlPaUpRYVdGNmVtRWdSSFZqWVNCa1pXZHNhU0JCWW5KMWVucHBJRElzSURRME1DSXNJblJ2ZDI0aU9pSlVjbWxsYzNSbEluMHNJbk5sY1c1dklqb3hmVjBzSW5kdmNtdFFiR0ZqWlU1aGJXVnpJanBiZXlKamIyMXdZVzU1VG1GdFpWWmxjM05sYkU1aGJXVWlPaUpCYzNOcFkzVnlZWHBwYjI1cElFZGxibVZ5WVd4cElGTXVjQzVCSWl3aWMyVnhibThpT2pGOVhYMHNJbk5sWTNScGIyNDJJanA3SW1Ga1pISmxjM01pT25zaVkyOTFiblJ5ZVVOdlpHVWlPaUpDUlNJc0luQnZjM1JEYjJSbElqb2lNVEF3TUNJc0luTjBjbVZsZEU1dklqb2lUV0ZwYmlCVGRISmxaWFFnTVNJc0luUnZkMjRpT2lKQ2NuVnpjMlZzY3lKOUxDSmtZWFJsSWpvaU1qQXlNeTB3T1Mwd055SXNJbVZ0WVdsc0lqb2lhVzVtYjBCdWMzTnBMV0psTG1WMUlpd2lhVzV6ZEdsMGRYUnBiMjVKUkNJNklrNVRVMGt0UWtVdE1ERWlMQ0p1WVcxbElqb2lUbUYwYVc5dVlXd2dVMjlqYVdGc0lGTmxZM1Z5YVhSNUlFOW1abWxqWlNJc0ltOW1abWxqWlVaaGVFNXZJam9pTURnd01DQTVPRGMyTlNJc0ltOW1abWxqWlZCb2IyNWxUbThpT2lJd09EQXdJREV5TXpRMUlpd2ljMmxuYm1GMGRYSmxJam9pVDJabWFXTnBZV3dnYzJsbmJtRjBkWEpsSW4xOUxDSmxlSEJwY21GMGFXOXVSR0YwWlNJNklqSXdNalF0TURJdE1EVlVNVEk2TWprNk5UQmFJaXdpYVdRaU9pSjFjbTQ2Wkdsa09qVTVaamd5TTJReExUQXlNakl0TkRVelpDMDRZelpsTFRVeFpUQXlOVFUyWW1Jd05pSXNJbWx6YzNWaGJtTmxSR0YwWlNJNklqSXdNalF0TURJdE1EVlVNVEU2TWprNk5UQmFJaXdpYVhOemRXVmtJam9pTWpBeU5DMHdNaTB3TlZReE1Ub3lPVG8xTUZvaUxDSnBjM04xWlhJaU9pSmthV1E2YTJWNU9ub3laRzE2UkRneFkyZFFlRGhXYTJrM1NtSjFkVTF0UmxseVYxQm5XVzk1ZEhsclZWb3paWGx4YUhReGFqbExZbk5qV0dFeGRVZHZaVzU1Wm0xVmVWbExaRTFRVmtOblFsSktRWGRGUm1sSU1rTlphblI1Wm1aclRFd3hjMlJUVTFwdVVISktiVzlIVG1adGVrdFlSamR0Tmt0QmNURlhZMlYxUzFKV1UwcEZjWEYxYjBKSWVrRmxhV1p0YzAxdFJuWmhTR2xWV25CSWNrWm1hR3RvYzNobVoxSldaM0ZrVW5ZNWQybGhOMlExV1RnaUxDSjBlWEJsSWpwYklsWmxjbWxtYVdGaWJHVkRjbVZrWlc1MGFXRnNJaXdpVm1WeWFXWnBZV0pzWlVGMGRHVnpkR0YwYVc5dUlpd2lWbVZ5YVdacFlXSnNaVkJ2Y25SaFlteGxSRzlqZFcxbGJuUkJNU0pkTENKMllXeHBaRVp5YjIwaU9pSXlNREkwTFRBeUxUQTFWREV4T2pJNU9qVXdXaUo5ZlEuTVpaajNJLThlcDQyd05CT0tZVkxIdWhaN3BvdnJkSjl2T216RHBWVktyQWtNR2VHRFN4SFB5aVBGcXpaaWk0bUw3VzlkYWtJaUx6eXNJWHNZbWRKUmciXX0sImV4cCI6MTcwNzEzMjY5NywiaWF0IjoxNzA3MTMyNjM3LCJub25jZSI6IjlhYTgyYmQ5LTkyYTgtNDE2Zi04NTc0LTJhMDIxMTE4MWMyOCIsImp0aSI6InVybjp1dWlkOjc4ZDc2NjVkLTQ1YTMtNDBlOC1hYTNhLWZlMDBiOWE1OTExYyJ9.cBFkT_--HcEbzS4mLnt_NdiPZo0mk9ndG-A1QUsg1arK2JUYSMObJvJQbqr-fzBmbTIOW8kZ-1_msCBcxh7XEA ``` -This request is made with the following query params: - - - - - - - - - - - - - - -
grant_type - Grant type for authorisation. E.g. urn:ietf:params:oauth:grant-type:pre-authorized_code -
pre-authorized_code - Code representing the Credential Issuer's authorisation for the Wallet to obtain Credentials of a certain type. This code must be short-lived and single-use. -
user_pin - The end user pin is decided by the issuer and sent to the holder through an out-of-band process. E.g. Email, SMS -
- -## 3.8 Token response - -The token response for PID credential issuance includes: +An example `presentation_submission` values is as given: ```json { - "access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6Ikp..sHQ", - "refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCI4a5k..zEF", - "token_type": "bearer", - "expires_in": 86400, - "id_token": "eyJodHRwOi8vbWF0dHIvdGVuYW50L..3Mz", - "c_nonce": "PAPPf3h9lexTv3WYHZx8ajTe", - "c_nonce_expires_in": 86400 + "definition_id": "841fd89b-f987-4052-88fc-30affccfd99c", + "descriptor_map": [ + { + "format": "jwt_vp", + "id": "2cfa0952-76ae-4172-a1c1-d223a8c00ce8", + "path": "$", + "path_nested": { + "format": "jwt_vc", + "id": "2cfa0952-76ae-4172-a1c1-d223a8c00ce8", + "path": "$.verifiableCredential[0]" + } + } + ], + "id": "f7a98fa3-23b8-4d01-a656-b7f9f95ee470" } ``` -This response grants the wallet an access token and a refresh token to be used for the request of PID credential. -## 3.9 Credential request - -To request the PID credential, the holder’s wallet sends a request to the PID Endpoint as follows: +Verifiable credentials matching the input descriptor constraints are embedded in the VP token. Presentation submission contains the descriptor map conveying which verifiable credentials are satisfying corresponding input descriptor constraints. Both `vp_token` and `presentation_submission` are sent by HTTP POST to the direct post endpoint. ```http -POST /credential -Content-Type: application/json -Authorization: Bearer eyJ0eXAi...KTjcrDMg +POST https://example.verifier.com/direct_post +Content-Type: application/x-www-form-urlencoded -{ - "format": "vc+sd-jwt", - "vct": "eu.europa.ec.eudi.pid.1", - "proof": { - "proof_type": "jwt", - "jwt":"eyJraW...KWjceMcr" - } -} +&vp_token=eyJraWQiOiJk...Z-1_msCBcxh7XEA +&presentation_submission={"definition_id":"9a044aea-275d-43d6-8ec4-0ae88df46256","descriptor_map":[{"format":"jwt_vp","id":"2cfa0952-76ae-4172-a1c1-d223a8c00ce8","path":"$","path_nested":{"format":"jwt_vc","id":"2cfa0952-76ae-4172-a1c1-d223a8c00ce8","path":"$.verifiableCredential[0]"}}],"id":"f7a98fa3-23b8-4d01-a656-b7f9f95ee470"} +&state=475e634e-2633-4235-953d-eb879334cae7 ``` -This request specifies the format and type of credential being requested, along with a JWT proof of the holder’s identity. - -## 3.10 Credential response - -The issuance of PID credentials may proceed directly or be deferred, contingent on the issuer's readiness to issue the credential immediately or require additional processing time. - -### 3.10.1 In-time +# 4.0 Alternate response format -In cases where the PID credential is immediately available, the response is structured as follows: +Standard HTTP response codes shall be supported. Any additional ones can ```json -{ - "format": "vc+sd-jwt", - "credential": "eyJ0eXAiOi...F0YluuK2Cog", //EncodedPIDCredential - "c_nonce": "fGFF7UkhLa", //NonceForThisCredential - "c_nonce_expires_in": 86400 -} -``` - -This response provides the PID credential in an encoded format, ensuring that the recipient can use it straightaway. The c_nonce ensures the response's freshness, enhancing security. - -### 3.10.2 Deferred - -Should the credential not be ready for immediate issuance, the response includes an acceptance token, signaling that the PID credential's issuance is deferred: - -```json -{ - "acceptance_token": "eyJ0eXAiOiJKV1QiLCJhbGci..zaEhOOXcifQ", - "c_nonce": "wlbQc6pCJp", - "c_nonce_expires_in": 86400 -} -``` - -If the response contains `acceptance_token` field, then it indicates the credential is not yet available and will be accessible through a deferred PID credential retrieval process: - -```http -POST /deferred-credential -Authorization: BEARER eyJ0eXAiOiJKV1QiLCJhbGci..zaEhOOXcifQ -``` - -The holder can later use the acceptance_token to request the credential once it's ready for issuance. - -## 3.11 Issuer Authorization Verification - -During this process, the wallet queries the Trust Anchor to ascertain the issuer's trust status, thereby affirming that the issuer has been vetted and is compliant with established standards and regulations governing PID. It ensures that only entities with verified trustworthiness can issue PID. Further details will be added as soon as additional requirements are derived from ongoing discussions. - -## 3.12 Check Wallet's Conformity - -This verification process involves assessing whether the wallet possesses an internal certificate, issued by Certification Assessment Bodies (CAB), which confirms its compliance with the requisite standards for securely handling PID digital identities and associated qualified electronic attestations. It guarantees the secure storage and management of the PID. Further details will be added as soon as additional requirements are derived from ongoing discussions. - -# 4.0 Alternate response format - -Standard HTTP response codes shall be supported. Any additional ones can be formulated in the following format. - -``` { "error": "invalid_request", - "error_description": "The PID credential request is invalid or expired" + "error_description": "Verification failed" } ``` - -The table below summarises the success/error responses that can be used: +Some of the identifier deviations from success responses are as given: @@ -835,41 +232,21 @@ The table below summarises the success/error responses that can be used: - - - - - - - - -
invalid_request The request was invalid or improperly formatted. E.g. The PID credential is expired -
invalid_grant - -
    - -
  • The Authorization Server expects a PIN in the Pre-Authorized Code Flow but the Client provides the wrong PIN. - -
  • The end user provides the wrong Pre-Authorized Code or the Pre-Authorized Code has expired. -
    • -
-
invalid_client - The Client tried to send a Token Request with a Pre-Authorized Code without Client ID, but the Authorization Server does not support anonymous access + Verification failed
-# 5.0 Implementers +# 5.0 Implementers Please refer to the [implementers table](https://github.com/EWC-consortium/eudi-wallet-rfcs?tab=readme-ov-file#implementers). -# 6.0 Reference +# 6.0 Reference -1. OpenID Foundation (2024), 'OpenID for Verifiable Credential Issuance (OID4VCI)', Available at: [https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-ID1.html](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0-ID1.html) (Accessed: October 10, 2024). -2. European Commission (2024) The European Digital Identity Wallet Architecture and Reference Framework (2024-09, v1.4.1) [Online]. Available at: [https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/releases](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/releases) (Accessed: October 16, 2024). -3. OAuth 2.0 Rich Authorization Requests, Available at: [https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-11](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-rar-11) (Accessed: February 01, 2024) -4. Proof Key for Code Exchange by OAuth Public Clients, Available at: [https://datatracker.ietf.org/doc/html/rfc7636](https://datatracker.ietf.org/doc/html/rfc7636) (Accessed: February 01, 2024) -5. OpenID4VC High Assurance Interoperability Profile with SD-JWT VC - draft 1.0, Available at [https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.html](https://openid.net/specs/openid4vc-high-assurance-interoperability-profile-sd-jwt-vc-1_0.html) (Accessed: February 16, 2024) +1. OpenID Foundation (2023), 'OpenID for Verifiable Presentations (OID4VP)', Available at: [https://openid.net/specs/openid-4-verifiable-presentations-1_0-ID2.html](https://openid.net/specs/openid-4-verifiable-presentations-1_0-ID2.html) (Accessed: February 1, 2024). +2. European Commission (2023) The European Digital Identity Wallet Architecture and Reference Framework (2023-04, v1.1.0) [Online]. Available at: [https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/releases](https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/releases) (Accessed: October 16, 2023). +3. RFC 9101 OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR) [https://www.rfc-editor.org/rfc/rfc9101.html#name-request-using-the-request_u](https://www.rfc-editor.org/rfc/rfc9101.html#name-request-using-the-request_u) (Accessed: February 05, 2024) +4. DIF Presentation Exchange: [https://identity.foundation/presentation-exchange](https://identity.foundation/presentation-exchange) (Accessed: February 07, 2024) # Appendix A: Public key resolution