VCI: Adding a credential identifier (issue #1923)

[Update 08-24-2023] decided that since identifier should rather be dynamically generated by the issuer, returning it from the token endpoint and wallet including it in the credential request is sufficient (already reflected in the PR). if there is a need to change the display information, that could be included in the credential itself (still need to apply the changes to the PR).

Problem (Issue #1923):

• Communicating issuance of credentials that are same format/type, but different content.

Changes and rationale:

• credential offer: issuer can communicate that it is offering to issue multiple credentials of a same format/type

  • new identifiers parameter (array) can be included when the credentials array entry is an object

  • identifier credential issuer metadata parameter (see below) can be used as the value when the credentials array entry is a string

• Authorization Request: wallet can indicate that it is requesting issuance of a specific credential beyond format/type (either the wallet got the information from the credential offer or discovered from the credential issuer metadata).

  • authorization_details: new identifiers parameter (array)

  • scope: using identifier credential issuer metadata parameter (see below) as the scope value

• token response: Issuer can communicate a specific credential for which the Access token is valid for

  • new identifiers parameter (array)

• Credential Issuer metadata: issuer can indicate that it can issue multiple credentials of a same format/type that can also have different display information (logo, etc.):

  • new identifier parameter (string) within the display object in the credentials_supported parameter

  • removed scope parameter in the credentials_supported parameter

  • if a different display is not needed: display object can only include name and identifier parameters (so we might want to consider renaming display to something else.)

• authorization response, token request, credential response are not changed: if the wallet communicated specific identifiers in the authorization request, the AS indicates whether Access Token is valid for the requested credential identifiers or not. if the credential request contained an identifier and credential was successfully issued, the wallet will know it is a credential of that identifier.

things to pay attention to:

• mandating an identifier parameter might address issue #1922 too, and I tried initially, but the more I thought about it, it seemed like a better way to solve a problem raised in #1922 is to remove credentialSubject from authorization request entirely IMO, so I have not made this change.

  • update 8/24/2023, agreed that the change kristina proposed in #1922 should probably work

• might benefit from an implementation considerations section that explains how credentials of the same format/type, but different content can be issued.

• might need new error descriptions?

I tried to think through but I might have missed something..