OpenID4VCI

OpenID4VCI copied to clipboard

          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 https://github.com/openid/OpenID4VCI/pull/65#pullrequestreview-1699358644

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.

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.

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)

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

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

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.

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?

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

needs a statement what can be achieved via credential instances (benefits/limitations), whether they are needed or not. Agreed to continue a discussion from there with the goal of fixing the terminology.

Here's a go at definitions for the three different concepts (hopefully if we can agree on the concepts we can figure out if the suggested names are right or not - I've used the currently suggested terms from Daniel's latest comment and have taken some of the text from Paul's comment above):

credential description: meta data solving technical interoperability, schema, display information, e.g. "birth certificate", "diploma", "driving license", "national id card". The issuer lists these in their metadata so that a wallet can determine what kinds of credentials a particular issuer can issue. An issuer may issue several credentials with the same description to a wallet, for example where a parent has multiple young children, they may wish to hold all their birth certificates in a single wallet.

credential dataset: A term represents the combination of a 'credential description' and a single dataset. For example 'driving license for Alice', 'birth certificate for <first child>', 'diploma for Alice's Electrical Engineering course'. The issuer provides an identifier for each 'credential dataset' to enable the wallet to request a a refresh of the 'credential dataset' in the event it expires or the dataset changes (for example, when someone's name changes).

credential instance/copies: An actual set of bytes passed from the issuer to the wallet. For some credential formats that allow selective disclosure of the claims within the dataset, verifier(s) can potentially collude to link different presentations of a credential allowing the verifier(s) to determine that the disclosed data relate to the same credential/user. In some cases this linkability can be avoided if the wallet holds multiple copies of each 'credential dataset' each associated with different proof keys such that each one is only presented once or only at one verifier, for example as described in the Unlinkability section of the SD JWT specification.

Isn't a "credential instance" what people commonly refer to as "a credential"? If not, how do they differ? To my understanding, a credential is a set of attested claims about a subject that are bound to a key controlled by a holder. With that terminology, a credential instance is just another credential. Doesn't a "credential copy" imply that there is an original that it copies?

I believe the objective is to enable the wallet to request and receive a set of credentials that it may use interchangeably. To use interchangeably means that the outcome in the current context is the same no matter which credential in the set the wallet uses. This implies that the credentials in the set present the same subject with the same dataset but they are still credentials on their own (and not a copy).

Any privacy enhancements (if there are any) are at the discretion of the credential itself, the wallet (e.g. via policies like one-time usage) or the user. Preferably, user privacy requirements were solved in credentials by design but considering with what we have now, we need to acknowledge that certain credentials have their limitations. A wallet may mitigate those limitations by requesting several credentials that it can use interchangeably (whether or not wallets are going to adopt that behavior is a different question). From a protocol point of view we should design the option at least imo. Of course, the more information users reveal about themselves the higher are the chances for verifiers to link their activities and data to an identity (it also depends on the kind of information they reveal). We won't be able to prevent linkability but we can make it harder by supporting issuance of credentials that can be used interchangeably (e.g. as single-use credentials with different proof keys).

I suggest to introduce the concept of "a set of credentials that may be used interchangeably" in addition to credential description and credential dataset. We can call the concept "interchangeable credentials". Other terms that came into my mind were "twin credentials" or "sibling credentials" because such credentials "look the same" and are related (as they can be used interchangeably) but are still individual credentials. (it's going to be a whole family of credentials ;) ). A credential remains "the actual set of bytes passed from the issuer to the wallet".

Thanks for your thoughts Judith!

Isn't a "credential instance" what people commonly refer to as "a credential"? If not, how do they differ?

It probably depends who you mean by "people". For people in our community, maybe they would view that as a credential. For people thinking from the end user point of view, they would view a set of "credential instances" as a single credential. i.e. if you have 10 "credential instances" of your driving license stored in your wallet, the wallet would show you have a single driving license credential. (As I think you guessed, I very deliberately almost entirely avoided using the term 'credential' unqualified in my descriptions to avoid this ambiguity - which was hard to do!)

"interchangeable credentials" - good suggestion, thanks. I probably slightly prefer 'instance', I think 'interchangeable' perhaps implies too much (as once you have used one of the set, that one is no longer 'interchangeable'.) Would be good to hear what others think. (Regardless I think 'interchangeable' would be a good word to use in the descriptions of the term.)

My thoughts after yesterdays call: There are currently three categrories of credentials:

• non-sd credentials, e.g. W3C style JWT-VC
• salted-hash-sd credentials, e.g. SD-JWT-VC and mdoc
• zkp-enabled-sd credentials, e.g. Anoncreds and W3C BBS+

We need the first two layers (credential_description and credential_dataset) for all of them, but require the instances/copies/twin credentials layer only for salted-hash-sd credentials. For non-sd credentials we gonna reveal all of our data anyway and therefore we are linkable by the data itself. For zkp-enabled-sd we don't need multiple instances/copies/twins because the nature of their cryptography allows unlinkability even by using a single one.

That said, we are building a feature for a certain category of credential. However, this type seems the most wanted from the community right now.

Thanks Paul. There actually may be a small subtly that makes 'credential instance' a useful term even when using non-sd or zkp credentials, and I've perhaps not captured this in my descriptions. If you think about the case where someone changes their name:

"credential dataset" - the dataset for, say, a driving license would be updated by the issuer, and the next refresh of the credential would return credential instance(s) with a new name.

"credential instance" - the wallet may at some point hold instances with both the old and the new name.

I think that actually gives rise to new complications that we've not necessarily considered because it's certainly not great if the wallet ends up with credential instances that have different data in them. I wonder how the mdl folks handle this case...

I think that actually gives rise to new complications that we've not necessarily considered because it's certainly not great if the wallet ends up with credential instances that have different data in them. I wonder how the mdl folks handle this case...

The characteristic of "different data in them" is a very important detail here imo. I think, that technically such credential instances (as in "binary data sent to the wallet") are not based on the same credential dataset because the dataset changed for one of them (by updating the name). In this case, I actually wouldn't consider those bits and pieces to be "credential instances" as they cannot be used interchangeable. Consequently, I also think that from an UX perspective, it is ok in this case to show them in the wallet as two separate credentials (as in "two different sets of binary data that can be used interchangeable"): an old credential and a new one.

However, if a new credential (as in binary data) was based on the same credential dataset as another credential (as in binary data), i.e. if they contain the same data but may have different expiration dates or holder bindings, then I would consider them to be "credential instances" at least for a period of time while both are valid because during a time window they may be used interchangeably.

With that said, I think how the wallet visualizes credential instances and whether or not it groups credential instances under "credential" is out of scope of the protocol. I have a hard time to define a credential in the current concept. I can grasp a credential instance because that's the binary data but what is it an instance of, what's the credential?

In the context of this protocol, I think defining a credential as "the binary data that the wallet stores" simplifies the terminology. Then there is no concept of a "credential instance" that is an instance of some credential, but there is the concept of a credential that is part of a set of credentials that share the same dataset and can be used interchangeably - whatever we want to call such a set in the spec. The wallet may want to display such a set as one entity and refer to it as a credential but that's pure UX which has its own terminology imo.

I'm slightly reluctant to ever use the term 'credential' standalone in the specification, but it's definitely an option if we clearly define it. I guess the problem isn't just the UX issue I raised but also that we're likely to see laws etc that may well use the term 'credential' in a different way, and our specification using such an overloaded term may reduce clarity.

I definitely agree 'different data in them' is an important detail. I think we need more clarification over how updating the data in a credential will work (as in the 'person has changed their name' case, but I'm sure that's not the only case). Currently the handle (protocol level identifier) for the dataset is I believe the only thing can be used to refresh a credential without the user being sent back to the issuer, so if a credential is to automatically update in the case of a changed name then we have to consider the data in the dataset as changeable. If we're not going to let the dataset be changeable, we may need to introduce one more identifier/term/concept.

we discussed on the editors call and brushed up definitions of the three layers:

1. what issuer supports (credential configuration?)
   • can contain protocol specific parameters
     • proof_types_supported, cryptographic_suites_supported, etc.
   • protocol independent properties
     • type, schema, display, etc.
2. what user authorizes
   • can be expressed using credential_identifier, combination of format/types depending on whether scopes or RAR is used
3. technical realization of what user authorized / data that actually gets stored by the wallet (should be called instances rather than copies)
   • when several of these "realizations" are getting issued at once, they must contain exactly the same content
   • however, data about the user can change over time (like address), so it is possible that when these "realizations" get refreshed, the actual values of the user claims change.

going back to the original discussion whether the concept of layer 3 is needed or not, I think the answer is "yes". because the distinction between layer 2 and 3 as described above is important to differentiate what the user authorized to issue from what the wallet stores for the cases when the value of the user claims changes over time in a refreshed credential, or when multiple instances of the same credential are being issued at once.

we discussed the latest proposal for layering and terminology in the WG call. The layering was well received, the terminology (esp credential dataset) still needs more work. We agreed we should file (and discuss) a PR for the enhanced and improved terminology (before even extending the spec to support issuance of multiple instances of the same credential). @danielfett will do it.

PR #155 merged