[oidc4vci] Removing presentation exchange as the data model for provider metadata publishing around credential issuance

[Tobias Looker]

Presentation exchange is a highly comprehensive specification that offers many options around describing stuff like a credential manifest. However I think when it comes to defining the metadata a provider must publish in order to promote the ability for a client to discover what credential they offer, there are simpler syntax choices we could elect to explore that do not depend on P.E. As an example I can see a simplified openid metadata entry for expressing support for credential issuance being something along the lines of the following

{
.....
"credentials_supported": [
  {
    "name": "Basic Credential" // For basic rendering in a credential offer
    "type": "credential_type_1",
    "claims": [
      "first_name",
      "last_name",
      "date_of_birth"
    ]
  }
],
"credential_endpoint": "..."
"credential_formats_supported": ["w3cvc-jsonld","jwt"]
}

‌

[Kristina Yasuda]

Are you proposing to remove only presentation exchange piece in the credential manifest or support for the credential manifest entirely?

If the former, it makes sense since PE part in CM is not needed right away due to the lack of use-cases to submit a VC as an input for the issuance of another VC.

If the latter, how would the Issuer communicate details of how to display a VC in the wallet? For example, if Xbox is issuing a VC, it would absolutely want it to be displayed in green, and not in blue or red which are playstation/Nintendo colors. Since the issuer does not control the wallet in most of the cases, it somehow needs to communicate this information to the wallet.

If this information is to be included in a proposed “credential_supported“ metadata, would it not be easier to include credential_manifest itself in the metadata? Is there a use-case where the Issuer does not need to communicate design/display of a VC in the user’s wallet?

[Tobias Looker]

Im arguing for both, I think that any information that is pertinent around how to display a credential could be defined within the credentials_supported array object meaning there is 1 place for display information rather than two.

[Kristina Yasuda]

The initial logic was to use credential_manifest instead of reinventing the wheel. If implementors think credential_manifest is too complicated, we could specify a minimum profile in this specification, but I would not want to recreate things in "credentials_supported" claim. credential_manifest does have all the necessary components the issuer want to tell the wallet about the VC that is to be issued.

[Kristina Yasuda]

Has been removed