From 103b707f887a1ac4847bfe992d1b9d1b33a34703 Mon Sep 17 00:00:00 2001 From: Paul Bastian Date: Thu, 14 Dec 2023 18:08:59 +0100 Subject: [PATCH] Add Credential Offer Flow for Authorized Code Flow in the introduction (#115) 5 approvals. open for more than a week. no objections to merge during Dec-14-2023 DCP WG call * change sequence diagram for auth code flow * Added Issuer-initiated Flow with Credential Offer to the Authorization Code Flow Introduction and added use case example for Wallet-initiated flow. minor improvements on Section 3.4 and 3.5 * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Tobias Looker * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Tobias Looker * Apply suggestions from code review Co-authored-by: Giuseppe De Marco * rename User to End-User in sequence diagrams * Apply suggestions from code review * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Giuseppe De Marco * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Giuseppe De Marco * Apply suggestions from code review Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> Co-authored-by: Giuseppe De Marco * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Giuseppe De Marco * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> * Apply suggestions from code review * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Paul Bastian * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Paul Bastian * Update openid-4-verifiable-credential-issuance-1_0.md * Update openid-4-verifiable-credential-issuance-1_0.md * Update openid-4-verifiable-credential-issuance-1_0.md * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * fixed formatting of bullet list * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> * added history entry * Update openid-4-verifiable-credential-issuance-1_0.md * Update openid-4-verifiable-credential-issuance-1_0.md Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> --------- Co-authored-by: Tobias Looker Co-authored-by: Giuseppe De Marco Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> Co-authored-by: Torsten Lodderstedt Co-authored-by: Judith <59833642+ju-cu@users.noreply.github.com> --- ...id-4-verifiable-credential-issuance-1_0.md | 134 ++++++++++-------- 1 file changed, 76 insertions(+), 58 deletions(-) diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index 8584c8db..772e55ee 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -153,7 +153,7 @@ The Wallet MAY send one Batch Credential Request to the Batch Credential Endpoin * multiple Credentials of the same type/doctype bound to different proofs, or * multiple Credentials of different types/doctypes bound to different proofs. -In the course of the authorization process, the Credential Issuer MAY also request Credential presentation as a means to authenticate or identify the End-User during the issuance flow, as illustrated in a use case in (#use-case-2). +In the course of the authorization process, the Credential Issuer MAY also request Credential presentation as a means to authenticate or identify the End-User during the issuance flow, as illustrated in (#use-case-5). At its core, this specification is Credential format agnostic and allows implementers to leverage specific capabilities of Credential formats of their choice. Multiple Credential formats can be used within the same transaction. @@ -175,95 +175,104 @@ The following subsections illustrate some of the authorization flows supported b ## Authorization Code Flow {#authorization-code-flow} -Below is a diagram of a Credential issuance using the Authorization Code Flow, using grant type `authorization_code` as defined in [@!RFC6749]. +The Authorization Code Flow uses the grant type `authorization_code` as defined in [@!RFC6749] to issue Access Tokens. -The diagram shows how a Wallet-initiated flow use case as described in (#use-case-1) is implemented with the Credential Issuance API defined in this specification. Note that the diagram does not illustrate all the optional features of this specification. +Figure 1 shows the Authorization Code Flows with the two variations that can be implemented for the issuance of Credentials, as outlined in this specification: + +* **Wallet-initiated variation**, described in (#use-case-4) or (#use-case-6); +* **Issuer-initiated variation**, described in (#use-case-1). + +Please note that the diagram does not illustrate all the optional features defined in this specification. !--- ~~~ ascii-art -+--------------+ +-----------+ +-------------------+ -| User | | Wallet | | Credential Issuer | -+--------------+ +-----------+ +-------------------+ - | | | - | interacts | | - |--------------->| | - | | (1) Obtains Issuer's Credential Issuer metadata | - | |<-------------------------------------------------->| - | | | - | | (2) Authorization Request | - | | (type(s) of Credentials to be issued) | - | |--------------------------------------------------->| - | | | - | User Authentication / Consent | - | | | - | | (3) Authorization Response (code) | - | |<---------------------------------------------------| - | | | - | | (4) Token Request (code) | - | |--------------------------------------------------->| - | | Token Response (access_token) | - | |<---------------------------------------------------| - | | | - | | (5) Credential Request (access_token, proof(s)) | - | |--------------------------------------------------->| - | | Credential Response | - | | (Credential(s) OR transaction_id) | - | |<---------------------------------------------------| ++----------+ +-----------+ +-------------------+ +| End-User | | Wallet | | Credential Issuer | ++----------+ +-----------+ +-------------------+ + | | | + | (1a) End-User | | + | selects Credential | (1b) Credential Offer (credential type) | + |-------------------->|<---------------------------------------------------| + | | | + | | (2) Obtains Issuer's Credential Issuer metadata | + | |<-------------------------------------------------->| + | | | + | | (3) Authorization Request | + | | (type(s) of Credentials to be issued) | + | |--------------------------------------------------->| + | | | + | End-User Authentication / Consent | + | | | + | | (4) Authorization Response (code) | + | |<---------------------------------------------------| + | | | + | | (5) Token Request (code) | + | |--------------------------------------------------->| + | | Token Response (access_token) | + | |<---------------------------------------------------| + | | | + | | (6) Credential Request (access_token, proof(s)) | + | |--------------------------------------------------->| + | | Credential Response | + | | (Credential(s) OR Transaction ID) | + | |<---------------------------------------------------| ~~~ !--- Figure: Issuance using Authorization Code Flow -(1) The Wallet uses the Credential Issuer's metadata as described in (#credential-issuer-metadata) to learn what Credential types and formats the Credential Issuer supports and to determine the issuer URL of the OAuth 2.0 Authorization Server the Credential Issuer relies on. Note in this example, the Credential Issuer also provides the OAuth 2.0 Authorization Server. This specification enables deployments where the Credential Issuer API and the Authorization Server are different services, perhaps even provided by different entities. +(1a) The Wallet-initiated flow begins as the End-User requests a Credential via the Wallet from the Credential Issuer. The End-User either selects a Credential from a pre-configured list of Credentials ready to be issued, or, alternatively, the Wallet gives guidance to the End-User to select a Credential from a Credential Issuer based on the information it received in the presentation request from a Verifier. + +(1b) The Issuer-initiated flow begins as the Credential Issuer generates a Credential Offer for certain Credential(s) that it communicates to the Wallet, for example, as a QR code or as a URI. The Credential Offer contains the Credential Issuer's URL and the information about the Credential(s) being offered. This step is defined in (#credential_offer). -(2) The Wallet sends an Authorization Request to the Authorization Endpoint. The Authorization Endpoint processes the Authorization Request, which typically includes End-User authentication and gathering of End-User consent. +(2) The Wallet uses the Credential Issuer's URL to fetch the Credential Issuer metadata as described in (#credential-issuer-metadata). The Wallet needs the metadata to learn the Credential types and formats that the Credential Issuer supports, and to determine the Authorization Endpoint (OAuth 2.0 Authorization Server) as well as Credential Endpoint required to start the request. This specification enables deployments where the Credential Endpoint and the Authorization Endpoint are provided by different entities. Please note that in this example the Credential Issuer and OAuth 2.0 Authorization Server correspond to the same entity. -(3) The Authorization Endpoint returns an Authorization Response with the Authorization Code upon successfully processing the Authorization Request. +(3) The Wallet sends an Authorization Request to the Authorization Endpoint. The Authorization Endpoint processes the Authorization Request, which typically includes the End-User authentication and the gathering of the End-User consent. Note: The Authorization Request may be sent as a Pushed Authorization Request. -Note: Steps (2) and (3) happen in the front channel, by redirecting the End-User via the User Agent. Those steps are defined in (#authorization_endpoint). +Note: Steps (3) and (4) happen in the front channel, by redirecting the End-User via the User Agent. Those steps are defined in (#authorization_endpoint). The Authorization Server and the User Agent may exchange any further messages between the steps if required by the Authorization Server to authenticate the End-User. -(4) The Wallet sends a Token Request to the Token Endpoint with the Authorization Code obtained in step (3). The Token Endpoint returns an Access Token in the Token Response upon successfully validating Authorization Code. This step happens in the back-channel communication (direct communication between two systems using HTTP requests and responses without using redirects through an intermediary such as a browser). This step is defined in (#token_endpoint). +(4) The Authorization Endpoint returns the Authorization Response with the Authorization Code upon successfully processing the Authorization Request. -(5) The Wallet sends a Credential Request to the Credential Issuer's Credential Endpoint with the Access Token and (optionally) the proof of possession of the public key to which the issued VC shall be bound to. Upon successfully validating Access Token and proof, the Credential Issuer returns a VC in the Credential Response if it can issue a Credential right away. This step is defined in (#credential-endpoint). +(5) The Wallet sends a Token Request to the Token Endpoint with the Authorization Code obtained in step (4). The Token Endpoint returns an Access Token in the Token Response upon successfully validating the Authorization Code. This step happens in the back-channel communication (direct communication between two systems using HTTP requests and responses without using redirects through an intermediary such as a browser). This step is defined in (#token_endpoint). -If the Credential Issuer requires more time to issue a Credential, the Credential Issuer MAY return a `transaction_id` to the Wallet with information about when the Wallet can start sending a Deferred Credential Request to obtain an issued Credential, as defined in (#deferred-credential-issuance). +(6) The Wallet sends a Credential Request to the Credential Issuer's Credential Endpoint with the Access Token and (optionally) the proof of possession of the private key of a key pair to which the Credential Issuer should bind the issued Credential to. Upon successfully validating Access Token and proof, the Credential Issuer returns a Credential in the Credential Response. This step is defined in (#credential-endpoint). -If the Credential Issuer wants to issue multiple Credentials in one response, the Credential Issuer MAY support the Batch Credential Endpoint and the Wallet MAY send a Batch Credential Request to the Batch Credential Endpoint as defined in (#batch-credential-endpoint). +If the Credential Issuer requires more time to issue a Credential, the Credential Issuer may return a Transaction ID and a time interval in the Credential Response. The Wallet may send a Deferred Credential Request with the Transaction ID to obtain a Credential after the specified time interval has passed, as defined in (#deferred-credential-issuance). -With grant type `authorization_code`, it is RECOMMENDED to use PKCE as defined in [@!RFC7636] to prevent authorization code interception attacks and Pushed Authorization Requests [@RFC9126] to ensure integrity and authenticity of the authorization request. +If the Credential Issuer wants to issue multiple Credentials in one response, the Credential Issuer may support the Batch Credential Endpoint. In this case the Wallet may send a Batch Credential Request to the Batch Credential Endpoint, as defined in (#batch-credential-endpoint). Note: This flow is based on OAuth 2.0 and the Authorization Code Grant type, but this specification can be used with other OAuth 2.0 grant types as well. ## Pre-Authorized Code Flow {#pre-authz-code-flow} -Figure 2 is a diagram of a Credential issuance using the Pre-Authorized Code Flow. In this flow, before initiating the flow with the Wallet, the Credential Issuer first conducts the steps required to prepare the Credential issuance, e.g., End-User authentication and authorization. Consequently, the Pre-Authorized Code is sent by the Credential Issuer to the Wallet. This flow does not use the Authorization Endpoint, and The Wallet exchanges the Pre-Authorized Code for the Access Token directly at the Token Endpoint. Access Token is then used to request Credential issuance at the Credential Endpoint. See (#use-case-4) for a use case. +Figure 2 is a diagram of a Credential issuance using the Pre-Authorized Code Flow. In this flow, before initiating the flow with the Wallet, the Credential Issuer first conducts the steps required to prepare the Credential issuance, e.g., End-User authentication and authorization. Consequently, the Pre-Authorized Code is sent by the Credential Issuer to the Wallet. This flow does not use the Authorization Endpoint, and the Wallet exchanges the Pre-Authorized Code for the Access Token directly at the Token Endpoint. Access Token is then used to request Credential issuance at the Credential Endpoint. See (#use-case-2) for the description of a use case. How the End-User provides information required for the issuance of a requested Credential to the Credential Issuer and the business processes conducted by the Credential Issuer to prepare a Credential are out of scope of this specification. This flow uses the newly defined OAuth 2.0 Grant Type "urn:ietf:params:oauth:grant-type:pre-authorized_code". -The diagram is based on a Credential Issuer initiated flow illustrated in a use case in (#use-case-4) and does not illustrate all the optional features. +The following diagram is based on the Credential Issuer initiated flow, as illustrated in a use case in (#use-case-2). Please note that it does not illustrate all the optional features outlined in this specification. !--- ~~~ ascii-art +--------------+ +-----------+ +-------------------+ -| User | | Wallet | | Credential Issuer | +| End-User | | Wallet | | Credential Issuer | +--------------+ +-----------+ +-------------------+ | | | - | | (1) User provides information required | + | | (1) End-User provides information required | | | for the issuance of a certain Credential | |-------------------------------------------------------------------->| | | | | | (2) Credential Offer (Pre-Authorized Code) | - | |<---------------------------------------------------| + | |<---------------------------------------------------| | | (3) Obtains Issuer's Credential Issuer metadata | | |<-------------------------------------------------->| | interacts | | |--------------->| | | | | | | (4) Token Request (Pre-Authorized Code, pin) | - | |--------------------------------------------------->| + | |--------------------------------------------------->| | | Token Response (access_token) | - | |<---------------------------------------------------| + | |<---------------------------------------------------| | | | | | (5) Credential Request (access_token, proof(s)) | | |--------------------------------------------------->| @@ -276,17 +285,17 @@ Figure: Issuance using Pre-Authorized Code Flow (1) The Credential Issuer successfully obtains consent and End-User data required for the issuance of a requested Credential from the End-User using Issuer-specific business process. -(2) The flow defined in this specification begins as the Credential Issuer generates a Credential Offer for certain Credential(s) and communicates it to the Wallet, for example, as a QR code or as a link. +(2) The flow defined in this specification begins as the Credential Issuer generates a Credential Offer for certain Credential(s) and communicates it to the Wallet, for example, as a QR code or as a URI. The Credential Offer contains the Credential Issuer's URL, the information about the Credential(s) being offered and the Pre-Authorized Code. This step is defined in (#credential_offer). -(3) The Wallet uses information from the Credential Offer to obtain the Credential Issuer's metadata including details about the Credential that this Credential Issuer wants to issue. This step is defined in (#credential-issuer-metadata). +(3) The Wallet uses the Credential Issuer's URL to fetch its metadata as described in (#credential-issuer-metadata). The Wallet needs the metadata to learn the Credential types and formats that the Credential Issuer supports, and to determine the Authorization Endpoint (OAuth 2.0 Authorization Server) as well as Credential Endpoint required to start the request. -(4) The Wallet sends the Pre-Authorized Code obtained in step (2) in the Token Request to the Token Endpoint. The Wallet will send a Transaction Code provided by the User, if it was required by the Credential Issuer. This step is defined in (#token_endpoint). +(4) The Wallet sends the Pre-Authorized Code obtained in step (2) in the Token Request to the Token Endpoint. The Wallet will additionally send a Transaction Code provided by the User, if it was required by the Credential Issuer. This step is defined in (#token_endpoint). -(5) This step is the same as Step 5 in the Authorization Code Flow. +(5) This step is the same as Step 5 in the Authorization Code Flow. It is important to note that anyone who possesses a valid Pre-Authorized Code, without further security measures, would be able to receive a VC from the Credential Issuer. Implementers MUST implement mitigations most suitable to the use case. -One such mechanism defined in this specification is the usage of Transaction Codes. If in the Credential Offer the Credential Issuer indicated that the Transaction Code is required, the End-User is requested to type in a Transaction Code sent via a channel different than the issuance Flow and the Transaction Code is sent to the Credential Issuer in the Token Request. +One such mechanism defined in this specification is the usage of Transaction Codes. The Credential Issuer indicates the usage of Transaction Codes in the Credential Offer and sends the Transaction Code to the End-User via a second channel different than the issuance flow. After the End-User provides the Transaction Code, the Wallet sends the Transaction Code within the Token Request, and the Authorization Server verifies the Transaction Code. For more details and concrete mitigations, see (#security_considerations_pre-authz-code). @@ -391,6 +400,8 @@ The Wallet is not supposed to create a response. UX control stays with the Walle The Authorization Endpoint is used in the same manner as defined in [@!RFC6749], taking into account the recommendations given in [@!I-D.ietf-oauth-security-topics]. +When the grant type `authorization_code` is used, it is RECOMMENDED to use PKCE as defined in [@!RFC7636] and Pushed Authorization Requests as defined in [@RFC9126]. PKCE prevents authorization code interception attacks. Pushed Authorization Requests ensure the integrity and authenticity of the authorization request. + ## Authorization Request {#credential-authz-request} An Authorization Request is an OAuth 2.0 Authorization Request as defined in section 4.1.1 of [@!RFC6749], which requests to grant access to the Credential Endpoint as defined in (#credential-endpoint). @@ -503,7 +514,7 @@ response_type=code ### Dynamic Credential Request -This step is OPTIONAL. After receiving an Authorization Request from the Client, the Credential Issuer MAY use this step to obtain additional Credentials from the End-User required to proceed with the authorization of the Credential issuance. The Credential Issuer MAY obtain a Credential and utilize it to identify the End-User before issuing an additional Credential. For a use case, see (#use-case-2). +This step is OPTIONAL. After receiving an Authorization Request from the Client, the Credential Issuer MAY use this step to obtain additional Credentials from the End-User required to proceed with the authorization of the Credential issuance. The Credential Issuer MAY obtain a Credential and utilize it to identify the End-User before issuing an additional Credential. For a use case, see (#use-case-5). It is RECOMMENDED that the Credential Issuer use [@OpenID4VP] to dynamically request presentation of additional Credentials. From a protocol perspective, the Credential Issuer then acts as a verifier and sends a presentation request to the Wallet. The Client SHOULD have these Credentials obtained prior to starting a transaction with this Credential Issuer. @@ -1760,25 +1771,25 @@ The technology described in this specification was made available from contribut This is a non-exhaustive list of sample use cases. -## Credential Offer - Same-Device {#use-case-3} +## Credential Offer - Same-Device {#use-case-1} While browsing the university's home page, the End-User finds a link "request your digital diploma". The End-User clicks on this link and is being redirected to a digital Wallet. The Wallet notifies the End-User that a Credential Issuer offered to issue a diploma Credential. User confirms this inquiry and is taken to the university's Credential issuance service's End-User experience. After authenticating at the university and consenting to the issuance of a digital diploma, the End-User is sent back to the Wallet, where she can check the successful creation of the digital diploma. -## Credential Offer - Cross-Device (with Information Pre-Submitted by the End-User) {#use-case-4} +## Credential Offer - Cross-Device (with Information Pre-Submitted by the End-User) {#use-case-2} The End-User is starting a job at a new employer. An employer has requested the End-User to upload certain documents to the employee portal. A few days later, the End-User receives an email from the employer notifying her that the employee Credential is ready and asking her to scan a QR code to retrieve it. The End-User scans the QR code with her smartphone, which opens her Wallet. Meanwhile, the End-User has received a text message with a Transaction Code to her smartphone. After entering that Transaction Code in the Wallet for security reasons, the End-User confirms the Credential issuance, and receives Credential into the Wallet. -## Credential Offer - Cross-Device & Deferred {#use-case-5} +## Credential Offer - Cross-Device & Deferred {#use-case-3} The End-User wants to obtain a digital criminal record. She visits the local administration's office and requests the issuance of the official criminal record as a digital Credential. After presenting her ID document, she is asked to scan a QR code with her Wallet. She is being told that the actual issuance of the Credential will take some time due to necessary background checks by the authority. In the Wallet, the End-User sees an indication that issuance of the digital record is under way. A few days later, the End-User receives a notification from her Wallet that requested Credential was successfully issued. When the End-User opens the Wallet, she is asked whether she wants to download the Credential. She confirms, and the new Credential is retrieved and stored in the Wallet. -## Wallet Initiated Issuance during Presentation {#use-case-1} +## Wallet Initiated Issuance during Presentation {#use-case-4} An End-User comes across a verifier app that is requesting the End-User to present a Credential, e.g., a driving license. The Wallet determines the requested Credential type(s) from the presentation request and notifies the End-User that there is currently no matching Credential in the Wallet. The Wallet selects a Credential Issuer capable of issuing the lacking Credential and, upon End-User consent, sends the End-User to the Credential Issuer's End-User experience (Web site or app). Upon being authenticated and providing consent to issue the Credential into her Wallet, the End-User is sent back to the Wallet. The Wallet informs the End-User that Credential was successfully issued into the Wallet and is ready to be presented to the verifier app that originally requested presentation of that Credential. -## Wallet Initiated Issuance during Presentation (Requires Presentation of Additional Credentials During Issuance) {#use-case-2} +## Wallet Initiated Issuance during Presentation (Requires Presentation of Additional Credentials During Issuance) {#use-case-5} An End-User comes across a verifier app that is requesting the End-User to present a Credential, e.g., a university diploma. The Wallet determines the requested Credential type(s) from the presentation request and notifies the End-User that there is currently no matching Credential in the Wallet. The Wallet then offers the End-User a list of Credential Issuers, which might be based on a Credential Issuer list curated by the Wallet provider. The End-User picks the university she graduated from and is sent to that university's End-User experience (Web site or app). @@ -1786,6 +1797,12 @@ The End-User logs in to the university, which determines that the respective End Upon providing consent, the End-User is sent back to the Wallet. The Wallet informs the End-User Credential was successfully issued into the Wallet and is ready to be presented to the verifier app that originally requested presentation of that Credential. +## Wallet Initiated Issuance after Installation {#use-case-6} + +The End-User installs a new Wallet and executes it. The Wallet offers the End-User a selection of the Credentials that the End-User may obtain from a Credential Issuer, e.g. a national identity credential, a mobile driving license or a public transport ticket. The corresponding Credential Issuers (and their URLs) are pre-configured by the Wallet or follow some discovery processes that are out of scope for this specification. By clicking on one these options corresponding to the Credentials available for the issuance, the Issuance process starts with the flows supported by the Credential Issuer (Pre-Authorized Code flow or Auth Code flow). + +Wallet Providers may also provide a market place where Issuers can register to be found for Wallet-initiated flows. + # Credential Format Profiles {#format_profiles} This specification defines several extension points to accommodate the differences across Credential formats. Sets of Credential format specific parameters or claims referred to as Credential format Identifiers are identified by the Credential format identifier and used at each extension point. @@ -2021,6 +2038,7 @@ The value of the `credential` claim in the Credential Response MUST be a string -13 * replaced `user_pin_required` in Credential Offer with a `tx_code` object that also now contains `description` and `length` + * reworked flow description in Overview section * removed Credential Offer examples from Credential format profiles -12