diff --git a/openid-4-verifiable-credential-issuance-1_0.md b/openid-4-verifiable-credential-issuance-1_0.md index bd2eb09e..8b627597 100644 --- a/openid-4-verifiable-credential-issuance-1_0.md +++ b/openid-4-verifiable-credential-issuance-1_0.md @@ -1843,167 +1843,6 @@ TBD -# IANA Considerations - -## Sub-Namespace Registration - -This specification registers the following URN in the IANA "OAuth URI" registry [@!IANA.OAuth.Parameters] established by [@!RFC6755]. - -* URN: urn:ietf:params:oauth:grant-type:pre-authorized_code -* Common Name: Pre-Authorized Code -* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Reference: (#token_request) of this spedification - -## OAuth Parameters Registry - -This specification registers the following parameter names in the IANA "OAuth Parameters" registry [@!IANA.OAuth.Parameters] established by [@!RFC6749]. - -* Parameter Name: wallet_issuer -* Parameter Usage Location: authorization request -* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Reference: (#credential-authz-request) of this specification - -* Parameter Name: user_hint -* Parameter Usage Location: authorization request -* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Reference: (#credential-authz-request) of this specification - -* Parameter Name: issuer_state -* Parameter Usage Location: authorization request -* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Reference: (#credential-authz-request) of this specification - -* Parameter Name: pre-authorized_code -* Parameter Usage Location: token request -* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Reference: (#token_request) of this specification - -* Parameter Name: tx_code -* Parameter Usage Location: token request -* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Reference: (#token_request) of this specification - -* Parameter Name: c_nonce -* Parameter Usage Location: token response -* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Reference: (#token-response) of this specification - -* Parameter Name: c_nonce_expires_in -* Parameter Usage Location: token response -* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Reference: (#token-response) of this specification - -## OAuth Dynamic Client Registration Metadata Registry - -This specification registers the following client metadata name in the IANA "OAuth Dynamic Client Registration Metadata" registry [@!IANA.OAuth.Parameters] established by [@!RFC7591]. - -* Client Metadata Name: credential_offer_endpoint -* Client Metadata Description: Credential Offer Endpoint -* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Reference: (#credential_offer_endpoint) of this specification - - -## Well-Known URI Registry - -This specification registers the following well-known URI in the IANA "Well-Known URI" registry established by [@!RFC5785]. - -* URI suffix: openid-credential-issuer -* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Specification document: (#credential_issuer_wellknown) of this document -* Related information: (none) - -## Media Types Registry - -This specification registers the following media types in the IANA "Media Types" registry [@!IANA.MediaTypes] in the manner described in [@!RFC6838]. - -* Type name: `application` -* Subtype name: `openid4vci-proof+jwt` -* Required parameters: n/a -* Optional parameters: n/a -* Encoding considerations: Uses JWS Compact Serialization, as specified in [@!RFC7515]. -* Security considerations: See the Security Considerations in [@!RFC7519]. -* Interoperability considerations: n/a -* Published specification: (#jwt-proof-type) of this specification -* Applications that use this media type: Applications that issue and store verifiable credentials -* Additional information: - - Magic number(s): n/a - - File extension(s): n/a - - Macintosh file type code(s): n/a -* Person & email address to contact for further information: Torsten Lodderstedt, torsten@lodderstedt.net -* Intended usage: COMMON -* Restrictions on usage: none -* Author: Torsten Lodderstedt, torsten@lodderstedt.net -* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Provisional registration? No - -* Type name: `application` -* Subtype name: `openid4vci-proof+cwt` -* Required parameters: n/a -* Optional parameters: n/a -* Encoding considerations: Binary CBOR, as specified in [@!RFC9052] -* Security considerations: See the Security Considerations in [@!RFC8392]. -* Interoperability considerations: n/a -* Published specification: (#cwt-proof-type) of this specification -* Applications that use this media type: Applications that issue and store verifiable credentials -* Additional information: - - Magic number(s): n/a - - File extension(s): n/a - - Macintosh file type code(s): n/a -* Person & email address to contact for further information: Torsten Lodderstedt, torsten@lodderstedt.net -* Intended usage: COMMON -* Restrictions on usage: none -* Author: Torsten Lodderstedt, torsten@lodderstedt.net -* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net -* Provisional registration? No - -# Acknowledgements {#Acknowledgements} - -We would like to thank Paul Bastian, Vittorio Bertocci, Christian Bormann, John Bradley, Brian Campbell, Gabe Cohen, David Chadwick, Andrii Deinega, Giuseppe De Marco, Mark Dobrinic, Daniel Fett, Pedro Felix, George Fletcher, Timo Glasta, Mark Haine, Fabian Hauck, Roland Hedberg, Joseph Heenan, Alen Horvat, Andrew Hughes, Jacob Ideskog, Edmund Jay, Michael B. Jones, Tom Jones, Judith Kahrer, Takahiko Kawasaki, Niels Klomp, Ronald Koenig, Markus Kreusch, Adam Lemmon, Daniel McGrogan, Jeremie Miller, Kenichi Nakamura, Rolson Quadras, Nat Sakimura, Oliver Terbu, Arjen van Veen, David Waite, Jacob Ward for their valuable feedback and contributions to this specification. - -# Notices - -Copyright (c) 2023 The OpenID Foundation. - -The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF. - -The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that MAY cover technology that MAY be required to practice this specification. - -# Use Cases - -This is a non-exhaustive list of sample use cases. - -## 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. Upon successful authentication at the university and consent to the issuance of a digital diploma, the End-User is redirected back to the Wallet. Here, the End-User can verify the successful creation of the digital diploma. - -## 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. The employer requests the End-User to upload specific documents to the employee portal. After a few days, the End-User receives an email from the employer indicating that the employee Credential is ready to be claimed and provides instructions to scan a presented QR code for its retrieval. The End-User scans the QR code with the smartphone, which opens the Wallet. Meanwhile, the End-User has received a text message with a Transaction Code to the smartphone. After entering the Transaction Code in the Wallet for security reasons, the End-User confirms the Credential issuance, and receives the Credential into the Wallet. - -## Credential Offer - Cross-Device & Deferred {#use-case-3} - -The End-User intends to acquire a digital criminal record. This involves a visit to the local administration's office to request the official criminal record be issued as a digital Credential. After presenting the ID document, the End-User is prompted to scan a QR code using the Wallet and is informed that the issuance of the Credential will require some time, due to necessary background checks by the authority. - -While using the Wallet, the End-User notices an indication that the issuance of the digital record is in progress. After a few days, the End-User receives a notification from the Wallet indicating that the requested Credential was successfully issued. Upon opening the Wallet, the End-User is queried about the download of the Credential. After confirmation, the Wallet fetches and saves the new Credential. - -## 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 missing Credential and, upon End-User consent, sends the End-User to the Credential Issuer's End-User experience (Web site or app). Once authenticated and consent is provided for the issuance of the Credential into the Wallet, the End-User is redirected 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-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 selects the university of graduation and is subsequently redirected to the corresponding university's website or app. - -The End-User logs into the university, which identifies that the corresponding End-User account is not yet verified. Among various identification options, the End-User opts to present a Credential from the Wallet. The End-User is redirected back to the Wallet to consent to present the requested Credential(s) to the university. Following this, the End-User is redirected back to the university End-User experience. Based on the presented Credential, the university finalizes the End-User verification, retrieves End-User data from its database, and proposes to issue a diploma as a Verifiable Credential. - -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. @@ -2286,12 +2125,174 @@ The following is a non-normative example of a Credential Request with Credential The value of the `credential` claim in the Credential Response MUST be a string that is an SD-JWT VC. Credentials of this format are already suitable for transfer and, therefore, they need not and MUST NOT be re-encoded. +# IANA Considerations + +## Sub-Namespace Registration + +This specification registers the following URN in the IANA "OAuth URI" registry [@!IANA.OAuth.Parameters] established by [@!RFC6755]. + +* URN: urn:ietf:params:oauth:grant-type:pre-authorized_code +* Common Name: Pre-Authorized Code +* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Reference: (#token_request) of this spedification + +## OAuth Parameters Registry + +This specification registers the following parameter names in the IANA "OAuth Parameters" registry [@!IANA.OAuth.Parameters] established by [@!RFC6749]. + +* Parameter Name: wallet_issuer +* Parameter Usage Location: authorization request +* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Reference: (#credential-authz-request) of this specification + +* Parameter Name: user_hint +* Parameter Usage Location: authorization request +* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Reference: (#credential-authz-request) of this specification + +* Parameter Name: issuer_state +* Parameter Usage Location: authorization request +* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Reference: (#credential-authz-request) of this specification + +* Parameter Name: pre-authorized_code +* Parameter Usage Location: token request +* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Reference: (#token_request) of this specification + +* Parameter Name: tx_code +* Parameter Usage Location: token request +* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Reference: (#token_request) of this specification + +* Parameter Name: c_nonce +* Parameter Usage Location: token response +* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Reference: (#token-response) of this specification + +* Parameter Name: c_nonce_expires_in +* Parameter Usage Location: token response +* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Reference: (#token-response) of this specification + +## OAuth Dynamic Client Registration Metadata Registry + +This specification registers the following client metadata name in the IANA "OAuth Dynamic Client Registration Metadata" registry [@!IANA.OAuth.Parameters] established by [@!RFC7591]. + +* Client Metadata Name: credential_offer_endpoint +* Client Metadata Description: Credential Offer Endpoint +* Change Controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Reference: (#credential_offer_endpoint) of this specification + + +## Well-Known URI Registry + +This specification registers the following well-known URI in the IANA "Well-Known URI" registry established by [@!RFC5785]. + +* URI suffix: openid-credential-issuer +* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Specification document: (#credential_issuer_wellknown) of this document +* Related information: (none) + +## Media Types Registry + +This specification registers the following media types in the IANA "Media Types" registry [@!IANA.MediaTypes] in the manner described in [@!RFC6838]. + +* Type name: `application` +* Subtype name: `openid4vci-proof+jwt` +* Required parameters: n/a +* Optional parameters: n/a +* Encoding considerations: Uses JWS Compact Serialization, as specified in [@!RFC7515]. +* Security considerations: See the Security Considerations in [@!RFC7519]. +* Interoperability considerations: n/a +* Published specification: (#jwt-proof-type) of this specification +* Applications that use this media type: Applications that issue and store verifiable credentials +* Additional information: + - Magic number(s): n/a + - File extension(s): n/a + - Macintosh file type code(s): n/a +* Person & email address to contact for further information: Torsten Lodderstedt, torsten@lodderstedt.net +* Intended usage: COMMON +* Restrictions on usage: none +* Author: Torsten Lodderstedt, torsten@lodderstedt.net +* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Provisional registration? No + +* Type name: `application` +* Subtype name: `openid4vci-proof+cwt` +* Required parameters: n/a +* Optional parameters: n/a +* Encoding considerations: Binary CBOR, as specified in [@!RFC9052] +* Security considerations: See the Security Considerations in [@!RFC8392]. +* Interoperability considerations: n/a +* Published specification: (#cwt-proof-type) of this specification +* Applications that use this media type: Applications that issue and store verifiable credentials +* Additional information: + - Magic number(s): n/a + - File extension(s): n/a + - Macintosh file type code(s): n/a +* Person & email address to contact for further information: Torsten Lodderstedt, torsten@lodderstedt.net +* Intended usage: COMMON +* Restrictions on usage: none +* Author: Torsten Lodderstedt, torsten@lodderstedt.net +* Change controller: OpenID Foundation Digital Credentials Protocols Working Group - openid-specs-digital-credentials-protocols@lists.openid.net +* Provisional registration? No + +# Acknowledgements {#Acknowledgements} + +We would like to thank Richard Barnes, Paul Bastian, Vittorio Bertocci, Christian Bormann, John Bradley, Brian Campbell, Gabe Cohen, David Chadwick, Andrii Deinega, Giuseppe De Marco, Mark Dobrinic, Daniel Fett, Pedro Felix, George Fletcher, Timo Glasta, Mark Haine, Fabian Hauck, Roland Hedberg, Joseph Heenan, Alen Horvat, Andrew Hughes, Jacob Ideskog, Edmund Jay, Michael B. Jones, Tom Jones, Judith Kahrer, Takahiko Kawasaki, Niels Klomp, Ronald Koenig, Micha Kraus, Markus Kreusch, Philipp Lehwalder, Adam Lemmon, Dave Longley, David Luna, Daniel McGrogan, Jeremie Miller, Kenichi Nakamura, Rolson Quadras, Nat Sakimura, Sudesh Shetty, Oliver Terbu, Mike Varley, Arjen van Veen, David Waite, Jacob Ward for their valuable feedback and contributions to this specification. + +# Notices + +Copyright (c) 2023 The OpenID Foundation. + +The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF. + +The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that MAY cover technology that MAY be required to practice this specification. + +# Use Cases + +This is a non-exhaustive list of sample use cases. + +## 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. Upon successful authentication at the university and consent to the issuance of a digital diploma, the End-User is redirected back to the Wallet. Here, the End-User can verify the successful creation of the digital diploma. + +## 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. The employer requests the End-User to upload specific documents to the employee portal. After a few days, the End-User receives an email from the employer indicating that the employee Credential is ready to be claimed and provides instructions to scan a presented QR code for its retrieval. The End-User scans the QR code with the smartphone, which opens the Wallet. Meanwhile, the End-User has received a text message with a Transaction Code to the smartphone. After entering the Transaction Code in the Wallet for security reasons, the End-User confirms the Credential issuance, and receives the Credential into the Wallet. + +## Credential Offer - Cross-Device & Deferred {#use-case-3} + +The End-User intends to acquire a digital criminal record. This involves a visit to the local administration's office to request the official criminal record be issued as a digital Credential. After presenting the ID document, the End-User is prompted to scan a QR code using the Wallet and is informed that the issuance of the Credential will require some time, due to necessary background checks by the authority. + +While using the Wallet, the End-User notices an indication that the issuance of the digital record is in progress. After a few days, the End-User receives a notification from the Wallet indicating that the requested Credential was successfully issued. Upon opening the Wallet, the End-User is queried about the download of the Credential. After confirmation, the Wallet fetches and saves the new Credential. + +## 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 missing Credential and, upon End-User consent, sends the End-User to the Credential Issuer's End-User experience (Web site or app). Once authenticated and consent is provided for the issuance of the Credential into the Wallet, the End-User is redirected 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-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 selects the university of graduation and is subsequently redirected to the corresponding university's website or app. + +The End-User logs into the university, which identifies that the corresponding End-User account is not yet verified. Among various identification options, the End-User opts to present a Credential from the Wallet. The End-User is redirected back to the Wallet to consent to present the requested Credential(s) to the university. Following this, the End-User is redirected back to the university End-User experience. Based on the presented Credential, the university finalizes the End-User verification, retrieves End-User data from its database, and proposes to issue a diploma as a Verifiable Credential. + +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. + # Document History [[ To be removed from the final specification ]] -13 + * moved the annex with Credential format profiles to the top of all annexes * added a Notification Endpoint used by the Wallet to notify the Credential Issuer of certain events for issued Credentials * completed IANA registrations section * clarified description of a `mandatory` claim