Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
awoie opened this issue Jan 19, 2023 · 5 comments
Open

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

awoie opened this issue Jan 19, 2023 · 5 comments

Comments

@awoie
Copy link

awoie commented Jan 19, 2023

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
Copy link

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
Copy link
Member

iherman commented Feb 8, 2023

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

  • no resolutions were taken
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.

Kristina Yasuda: PR exists.

@jandrieu
Copy link
Collaborator

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
Copy link
Member

TallTed commented May 12, 2023

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
Copy link
Author

awoie commented May 15, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants