Consider using OpenID4VCI and OpenID4VP

[Sakurann]

The document defines new scopes to be used with OAuth 2.0 to issue/present credentials.
From the past few years of experience in the community, that is not enough to extend OAuth 2.0 to VCs. Just to name a few limitations that will be faced when implementing OAuth 2.0 + scopes to support VCs:

• mutual metadata exchange becomes very different from usual OAuth, when one of the Entities is the Wallet (regardless of the deployment model)
• Trust model is also quite different because signature by the Holder/Wallet becomes different from the signature by the Provider of the Holder/Wallet SW, while those are the same in OAuth 2.0
• Especially for the issuance, the Holder/Wallet needs to provide key material and/or information about how those keys are managed so that the issuer can establish trust into what it is binding the issued credential to.
• For presentation, OAuth 2.0 alone does not have a syntax flexible enough that would allow verifiers to provide granular requirements which credentials they want the holder/wallet to present.

Which is why there has been work on OpenID for Verifiable Presentations (OpenID4VP) and OpenID for Verifiable Credential Issuance (OpenID4VCI) which is based on OAuth 2.0 and extends it nicely to support VC use-cases.

It would greatly help IMS implementers to be interoperable with the rest of the VC ecosystem if the current OAuth 2.0 + scopes approach has been extended to OpenID4VC. It would enable use cases where IMS VCs can be used with VCs from other verticals (employment, healthcare, gov, etc) over the same protocol. Otherwise, users will be subjected to two prompts to present VCs from different verticals if each of the vertical support separate protocol.