Making explicit the binding of the holder to a VC

[OR13]

See the long discussion on this PR #795

This issue opened to track discussion, and work towards a proposed set of changes or closed issue.

[RieksJ]

Let me first say that #795 is a bit too long to read (or I'm to lazy), so I haven't.

I like the diagram of #795 (comment), as it attempts to clearly distinguish between

• the party (named Hollace Holder) to which the credential is being issued, and
• the agent that supposedly acts on that party's behalf;
• the secure storage (wallet) (which I see as yet another agent, albeit that it has different functionality) that will hold the received credential.

I would describe the problem as follows. Binding a VC to (an identifier that identifies) the party, the agent or the wallet is all equivalent, if and only if it can be proved that (a) the agent acts on behalf of that party, (b) the agent uses that particular wallet, and (c) the wallet is owned/controlled by that party.

We need to establish ways by which these three assertions can be proved (perhaps with different levels of certainty). In general, this is not limited to creating cryptographic proofs, although we might want to limit the scope of this discussion to those (trust in the truth of such assertions can also be derived from knowledge about the kinds of tech implementations that are used, or any governance framework, etc., e.g. as in IDS)

Then, each such way may need support within VCs to convey the specifics from which the relying party can infer the trust it needs in a particular situation.

[decentralgabe]

Concept of a binding proof, perhaps? Not dissimilar to what we already have in the spec with a Verifiable Presentation. Maybe a subset of that.

[David-Chadwick]

I do not believe that the issuer can bind a VC to a holder, since the holder is a transient role that is held by anyone who currently happens to hold the VC. Rather the issuer can bind the VC to the issuee, it being the persistent entity that the issuer issued the VC to. Regardless of who the subsequent holder might be, the issuee never changes. So I would suggest that we change the title of this issue to "Making explicit the binding of the issuee to a VC"

[awoie]

I agree with @David-Chadwick. I think this issue is related to #731 and #942. In general I agree with @OR13 that this feature is important and I'm supportive of adding a mechanism like this to the VCDM 2.0.

[awoie]

IMO, this is also a duplicate of #789. I would continue all the discussions in #789.

[iherman]

The issue was discussed in a meeting on 2022-11-30

• no resolutions were taken

View the transcript

3. holder binding.

Kristina Yasuda: https://github.com/w3c/vc-data-model/issues?q=is%3Aopen+is%3Aissue+label%3Aholder-binding.

See github issue vc-data-model#789.

Oliver Terbu: There's a lot of interest in this binding type so verifier can run checks easier..
… we have two options: 1) include some info in the VC or in the VP or both; VC: biometrics, identifiers, etc. VP: additional proofs or other property.

See github issue vc-data-model#923.

Kerri Lemoie: Options described here: #789 (comment).

Oliver Terbu: listing issues.
… the question is should holder binding be added to the VC, VP or both?.

Kristina Yasuda: suggest poll.

Manu Sporny: db is supportive of discussing holder binding; evidence was suggested prior but it doesn't entirely address concerns in the issue..
… maybe a special topic call?.

Kristina Yasuda: https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/verfiable-credentials-holder-binding.md.

Manu Sporny: (to oliver) do you have enough info to put together a PR or do you need guidance from the WG?.

Ted Thibodeau Jr.: +1 the stuff referred to as "holder binding" is an application of business logic.

Joe Andrieu: there's nothing in the charter or spec that discuss control of VCs- use is out of scope. Control handling is a business decision to check..
… to add certainty to holder verification - define a claims vocab to describe privileges. Need a concrete way for a user to make a claim to claims..
… against adding any of this to the core data model..

David Chadwick: issuer can state facts: I am saying <this> about <subject> to <issuee>.

Joe Andrieu: +1 to fleshing out evidence types.

Orie Steele: in relation to evidence to holder binding -- opportunity to have evidence that describes holder and binding while also defending use of evidence property..

Manu Sporny: +1 to Oliver to create a PR -- understanding that it's probably going to get some push back for trying to do it via evidence -- but we do need to discuss this, so supportive of it..

Oliver Terbu: (to manu) needs more info but can create a PR based on discussions in issues and then take it from there..

Kristina Yasuda: yes - creating a pr is a good idea.

Christopher Allen: potential issues with privacy & correlation for parties to lock in people if this is in the core data model. would like to see some privacy considerations be clearly articulated. More comfortable with it in the VP than VC..

Orie Steele: ChristopherA why is this an issue for this WG? W3C already defined WebAuthN and platform authenticators use it..

Kristina Yasuda: please add those comments in oliver's pr..

---

[OR13]

Closing in favor of #789