Concept and naming of credential_supported / credential / credential_instance

[paulbastian]

          I think this is a great improvement to the spec.

A few questions remain for me:

• Could we use this to solve the questions whether the Wallet needs to call Credential Endpoint or Batch Credential Endpoint?
• [...]

I also have the feeling that the terminology is not right here yet. I see three levels to distinguish:

1. different credential types, each corresponds to one credentials_supported section in the Issuer metadata, e.g. birth certificate and diploma
2. different credentials (here called instances in this PR), each the same credentials_supported but with different claims data, e.g. my bachelor degree and my master degree
3. different instances of the same credential (this I would call instances instead), these are only used for unlinkability purposes

We don't need to solve everything in this PR however, so I' fine if we know how to proceed with these questions in the future

Originally posted by @paulbastian in #65 (review)

[Sakurann]

The issue title was a little confusing to me. For now we agreed to move forward by renaming c_instane_identifier to credential_identifier - is this issue about keep bikeshedding this? or is this issue about issuing multiple credentials of the same type but different content vs issuing copies of the same credential. @danielfett elaborated it very well in his issue-comment here:

---

So the relationship currently described is the in any issuance process, multiple "types" of credentials can be issued (*), and for each "type" there can be multiple instances. An instance is described as "contains different claim values or different subset of claims within the claimset identified by the Credential type"

(issuance process) --- 1:n --- (credential definition*) --- 1:m --- (credential instance)

How is the relationship to batch issuance for unlinkability as suggested in SD-JWT? Is this already covered or should there be a separate mechanism for that? I.e., to have something like this for k copies of the same credential:

(issuance process) --- 1:n --- (credential definition*) --- 1:m --- (credential instance) --- 1:k --- (credential instance copy)

(*) entry in the credentials_supported Credential Issuer metadata - I added a comment suggesting to find a good term for this to use instead of credential type.

[jogu]

I think it'd be good to try and add some of the stuff from Daniel's comment into the spec so we have a clearer definition.

I think we need to do a pass through to try and clean up terminology too (once https://github.com/openid/OpenID4VCI/pull/65/files and maybe others are merged), we have text that mentions "Credential Instance identifier" and I think means the credential_identifiers parameter, and it's not obvious these are the same things.

[paulbastian]

I like the term credential_definitions, should we use this in the Issuer Metadata instead of credentials_supported after the breaking change in #86 ?
My proposal:
(issuance process) --- 1:n --- (credential definition) --- 1:m --- (credential) --- 1:k --- (credential instance)

[Sakurann]

i like credentials_metadata if we are replacing credentials_supported or credentials_metadata_supported.

but i really think this issue is about how to enable issuing copies of the credentials, regardless if those are copies of credentials with different metadata/definitions or the credentials with the same metadata/definition but different content/claimset. which makes this issue somewhat related to the issue #36

[paulbastian]

Concerning the credential instance copies, I think we have to decide first whether the Issuer or the Wallet decides if copies will be issued on the number

[paulbastian]

So my thoughts on this - just a draft ;)

layer 1 : credential definition -> meta data solving technical interoperability, schema, display information, e.g. birth certificate and diploma
layer 2 : credential instance -> actual data, instantiation of credential_definition, e.g. birth certificate for son, daughter
layer 3 : credential instance copies -> same credential instance (and contained claim data) with different cryptographic data

Credential Offer -> Layer 1 only
Auth Request -> Layer 1
Auth Response -> n/a
Token Request -> n/a
Token Response -> Layer 2?
Credential Request -> Layer 1 + 2? + 3
Credential Request -> Layer 1 + 2 + 3

I assume, but please correct me:
credentials_supported from Issuer metadata -> matches Layer 1
scope -> matches to Layer 1?
authorization details -> matches Layer 1+2
credential_identifier -> matches Layer 2
format -> Layer 1

The questions that result from this thought experiment - they might be wrong if my assumptions are incorrect
Why you cannot use credential_identifier without authorization_details right now?
Why do we have format and credential_identifier in Credential Request?
Why does Credential Response contain format?

Credential Request could in my view include an map of objects, mapping credential_identifier to an array of proofs.
Credential Response could return a map of credential_identifier to array of credentials, each index mapping to a proof given in Crednetial Request. This makes Batch Endpoint obsolete.

[Sakurann]

first, on naming, I thought we decided not to use credential instance and a line layer 2 : credential instance -> actual data make me think, maybe we can call this concept credential content/credential data?

[Sakurann]

based on the whiteboarding during IETF, Looks like the following actions would resolve this:

• renaming credential_identifier to credential_dataset_identifier (normative) @Sakurann
• describe three different concepts credential description, credential dataset, credential instance/copies in the specification (non-normative). @danielfett