search

w3c / vc-use-cases

Verifiable Credentials Use Cases
https://w3c.github.io/vc-use-cases/
Other
50 stars 22 forks source link

Define use case(s) that requires holder binding #128

Open awoie opened 1 year ago

awoie commented 1 year ago

There is a number of issues in the VCDM that are talking about holder binding: https://github.com/w3c/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Aholder-binding. We should add use cases to make it more clear what people really require when they ask for holder binding.

peppelinux commented 1 year ago

In general, the holder binding is a property of a verifiable credential that contains verifiable evidence that the credential was issued to the same holder who is presenting it.

A simple example is the VC which contains the public key of the holder

During the presentation, the holder signs with his private key.

The presentation is signed by the holder, this contains the VC, issued by a trusted third party, and within the VC there is the public key to verify the signature of the presentation.

in this case the binding of the holder makes a mechanisms of proof of possession.

The public key can be included (JWK or other format) or referenced (did).

However, the public key, or its did, can be used to trace the user to different relying parties. For this reason it is necessary to consider that a Holder should have more than one private key and more of the same credential, each of which is bound to a different key.

Think of a user who decides to be traceable by a relying party, in this case the same credential will always be presented.

Otherwise it will present disposable credentials, ephemeral credentials, if and only if the RP requests an attested credential from a trusted third party. In the absence of this requirement, the holder can authenticate with a simple pseudonym, think of the SIOPv2 id token

consider that a user can be traced by the set of attributes contained in the VC, consider also that being able to make selective disclosure, or a completely anonymous presentation and without any released attribute, ephemeral VCs thanks to the holder binding offering a guarantee of legitimacy and authority of the Holder and at the same time the Holder binding cannot be exploited as a tracking vector, because both VC and public keys are always different

iherman commented 1 year ago

The issue was discussed in a meeting on 2023-02-07

View the transcript #### 1.2. Define use case(s) that requires holder binding (issue vc-use-cases#128) _See github issue [vc-use-cases#128](https://github.com/w3c/vc-use-cases/issues/128)._ > *Kristina Yasuda:* PR exists.
jandrieu commented 1 year ago

I think we have a number of use cases that require a notion of holder-binding, but we intentionally don't get into implementation or design details about how it's done.

For example F.1 Reuse know your customer https://w3c.github.io/vc-use-cases/#finance clearly requires some kind of mechanism for holder-binding or confidenceMethod.

@awoie Do you think we need more detail to illustrate the use? Or different examples?

TallTed commented 1 year ago

The description seems to require "authorized presenter", which I think is very distinct from "holder binding", and would be better as both title and descriptor, and there are a variety of ways the presenter might be authenticated by the verifier as the authorized presenting entity.

awoie commented 1 year ago

IMO, we would need to illustrate the use in more detail. The use case illustrates that the VC gets issued but it doesn't illustrate how it gets used. The usage should illustrate how Jane uses that digital credential online with "another bank". "Another bank" has to make sure that the digital credential is presented by Jane based on some information the issuer put into the VC, e.g., the public key of Jane's signature device.