Add a way for previewing credential data

Issue #1953 resolved
Timo Glastra created an issue

An issue we’ve ran into when implementing the client / wallet side of the OID4VCI specification is that a credential offer doesn’t include any specific values of the credential that will be issued.

In our wallet we would like to show the user a preview of the credential that will be issued, especially as without display metadata it’s quite hard to show to the user what type of credential will be issued to them.

Something we’ve now resulted to doing (and something encountered in other implementations) is to request the credential by default, and not store it in the wallet if the user declines. This means the user get’s a full preview of the credential (as it’s already issued), but it has a few downsides:

  • The did / cryptographic binding method is already shared. This is fine for ephemeral / single use dids
  • The issuer thinks the credential has been issued, but in fact it’s just shown as a preview. The actual decision of whether to store the credential comes afterwards.

Now my question is: Is this an valid use of this spec, to request the credential immediately and optionally store it afterwards? If not, what would be a good approach to show the user the type of credential that will be issued (with values)?

Comments (6)

  1. Kristina Yasuda

    credential offer contains credential_issuer and credentials parameter that can be used by the wallet to obtain information about the claims and display information of the credential to be issued.

    1. wallet obtains credential issuer metadata file using credential_issued parameter as defined in metadata retrieval section
    2. wallet uses information in the credentials parameter to look up the credential that the issuer is offering to issue (either a scope value or the format/type combination - PR #520 changes an id parameter to a scope parameter)
    3. wallet uses display and credentialSubject parameters (parameters can vary depending on the credential format) in the credentials_supported issuer metadata file to display to the user the credential that is being offered.

    hope this is clearer

  2. Timo Glastra reporter

    Thanks for the answer. My question has not fully been answered yet. What I’m suggesting is a way to preview the actual contents of the credential (so name = Timo, not that the credential contains an attribute name).

    And as an alternative question, my question is whether the workaround we (and e.g. Sphereon have imlemented) is valid:

    Is this an valid use of this spec, to request the credential immediately and optionally store it afterwards? If not, what would be a good approach to show the user the type of credential that will be issued (with values)?

  3. Kristina Yasuda

    This has come up before. and the WG has decided not to have a preview with the actual content because there are security concerns of an issuer sending an unsigned user data, not bound to a user-controlled key material in something like a credential offer which cannot be trusted (see here: https://openid.bitbucket.io/connect/openid-4-verifiable-credential-issuance-1_0.html#name-credential-offer-2)

    why a preview without user claims (that you can get using issuer metadata) is not sufficient to display to the user to get the user consent? (assuming that the purpose of a preview is to get consent?)

  4. Log in to comment