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.

Sign up for GitHub

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

Jump to bottom

Explicit reference should be added about binding the VC to the holder #789

Closed
swcurran opened this issue Aug 11, 2021 · 66 comments
Closed

Explicit reference should be added about binding the VC to the holder #789

swcurran opened this issue Aug 11, 2021 · 66 comments
Assignees
@awoie
Labels
holder-binding Issues related to holder binding pending close Close if no objection within 7 days

Comments

@swcurran
Copy link

The W3C V1.0 Data Model has little focus on the role of the holder, despite it's inclusion in Figure 1 of the spec. There is little normative text about the holder, and the data item "holder" is only in the JSON-LD example in the Appendix. Further, the view that "Anyone can hold any VC and prove it to a verifier" comes through loud and clear in the spec, with almost nothing about the idea of binding the VC to the Holder. We think that's a big issue -- that in many cases the verifier would really like cryptographic confidence of the binding of the VC to the holder -- that the issuer explicitly issued the VC to that holder. If the verifier trusts the issuer, that could include that the issuer had a reason to issue the VC to the bound holder.

As we in Aries have moved from using only Indy AnonCreds to adding support for the W3C standard, we've discovered that huge difference in the cryptographic trust model between the two. In the AnonCreds model, the holder is a cryptographic component of the Trust Triangle, while in the W3C VC model, it is not -- at least that is the takeaway from reading the spec. In AnonCreds, the Issuer MUST include in the verifiable credential a proof of the Holder on issuance, the Holder must prove that binding in the presentation, allowing the verifier cryptographic assurance that the presentation comes from the intended Holder. In the W3C VC data model, there is no such required binding to the Holder -- anyone can hold an issued VC. It may be that you can bind it to the holder (and we think many would) but that is at best implied in the spec. We think it should be explicit.

Taking it further, what if the emphasis of the spec. shifted to the holder (as presented in Figure 1), and the question of what the VC was about was left to the semantics of the VC defined by the issuer? In other words, reduce the emphasis on "subject" in the core spec (since subject is not part of Figure 1). Obviously, the holder = subject is easily handled, since the holder/subject is bound to the VC. However, the holder != subject is easily covered by the semantics of the issued VC. Where the holder is irrelevant, the holder binding is left off, allowing the VC to be held by any holder.

That view is probably a bridge too far in the VC 1.x spec. Adding a section about being explicit about a proof of the binding between the holder and VC would be a big help. We plan on proposing a PR to address this issue.

This issue arose from a discussion starting here on PR #788 , but is a separate issue from that PR. Other relevant comments on that PR are from @dlongley (here), @andrewhughes3000 (here), @msporny (here) and @agropper (here).
@mwherman2000
Copy link

mwherman2000 commented Aug 11, 2021 •
edited
Loading

Duplicate of #788 (comment) ...

@swcurran Given your world view Stephen, what are the Preconditions for an Actor Alice to be able to create a Verifiable Presentation VP from a Verifiable Credential VC?

For example, which (or all) of the following Preconditions are necessary for an Actor Alice to be able to create a Verifiable Presentation VP from a Verifiable Credential VC?

  1. Alice is an Actor
  2. Alice has a Public-Private Key Pair (KP)
  3. Alice is assigned a Holder Role (aka Alice's Holder Persona)
  4. As a Holder, Alice has an Agent A and A has a Wallet W (aka Credential Repository)
  5. Alice needs to hold Verifiable Credential VC in Alice's Wallet
  6. Alice has a personal Identifier I associated with Alice's Holder Persona (aka Holder Role) - typically a DID but not necessarily
  7. The credentialSubject id of VC has the same value as Alice's Identifier I
  8. VC needs to have a credential id (CI) with a non-empty value - typically a DID but not necessarily
  9. VC needs to have a Proof P that is based on Alice's Public-Private Key Pair KP
  10. P is Verifiable - based on Alice's Public Key that is associated with KP
  11. Anything else?

NOTE: Refresh this page. I've changed this posting at least 10 times.

@David-Chadwick
Copy link
Contributor

@swcurran Interestingly this is more or less the model we have implemented, where the subjectID is actually used as the proof of possession of the VC and the subject properties say what the VC is about. So if the Issuer gave the holder the VC, and the holder can prove possession of it, then the Verifier knows the correct entity is presenting the VC to it (regardless of the VC's actual contents).

@swcurran
Copy link
Author

@David-Chadwick -- thanks for the example. As I noted, Indy AnonCreds has the same model. I've heard of others doing what you are doing when using W3C VCs (e.g. BBS+). I think using subjectID for that is a workaround, and it makes way more sense to use holderID for proof of possession to establish that binding. By using subjectID for "proof of holder", it can't really be used for any subject not holder -- or subject not relevant -- use cases.

@David-Chadwick
Copy link
Contributor

If the subjectID is an ephemeral public key, then the verifier has no idea who the actual subject is (apart from the VC's properties). All the verifier knows is that the entity that signed the VP is the same entity that holds the public key in the VC subject ID field and that the Issuer knows who it gave the VC to (and obviously was entitled to have it). So it can be used for any subject not holder and subject not relevant use cases, because the subject is an ephemeral public key.

In one of our use case, a person presents the company's registration certificate from Companies House to the verifier. The verifier knows that whoever presented this VC is entitled to do so because Companies House issued the VC to them. This and other VCs' contents may tell the verifier what the relationship of this person is to the company (e.g. could be a director, secretary, or employee).

@kdenhartog kdenhartog added maintenance issues that may be considered part of the work of the maintenance group PossibleErratum WG should determine if this is Errata labels Aug 12, 2021
@kdenhartog
Copy link
Member

Labeling this as a possibleErratum now for the small non-normative suggestions you're going to put in a PR. Then we'll have to address the larger portions in a V2 at a later time.

@swcurran
Copy link
Author

@David-Chadwick -- what you say is the point I'm trying to make. If you use the subjectID field for the proof-of-holder, then except for "subject = holder", it can't be used for the actual subject of the VC. In your case, despite the subject being the company, the subjectID is a key held by the holder -- a director, secretary or employee. If instead the holderID was used for the proof-of-holder, then the subjectID would be available to identify the actual subject.

From that, my first question becomes -- is this what everyone is doing, and so the horse is out of the barn? Is it now common practice to use subjectID for "proof of holder" regardless of the VC and the subject?

My second question is where the concept of proving the holder is as designated by the issuer should go, both in the spec. and in the data model. This seems to be some tribal knowledge that this can and should happen, but it is not clear (to me at least) how that is supposed to work.

It can't go in the verifiable credential itself, since the VC is constructed by the issuer. Thus, I would think it would have to be in the verifiable presentation. There is a "holder" data item, but how would that be used to provide a proof from the holder that the issuer issued the credential to them?

@andrewhughes3000
Copy link

andrewhughes3000 commented Aug 12, 2021 via email

@agropper
Copy link

agropper commented Aug 12, 2021 via email

@andrewhughes3000
Copy link

andrewhughes3000 commented Aug 12, 2021 via email

@swcurran
Copy link
Author

@mwherman2000 -- regarding your list. It is hard to understand, but I'll try to set what I see as the flow. I'll assume that "Alice" is an agent she controls -- software that allows her to be issued VCs and prove VPs.

Alice wants a credential from an issuer Faber. As part of a protocol, she gives Faber a piece of data that only she can prove -- perhaps something associated with a private key she holds. Faber prepares the VC and includes in it the piece of data provided by Alice as a claim, signs the VC (including the "proof-of-holder" claim) and provides it to Alice, as the holder. The claims within the VC can be about anything -- Alice, or about something else. Later, Acme asks Alice for a prove that can be satisfied by the VC Alice holds from Faber. Alice prepares a VP derived from the VC from Faber. Along with (or in?) the VP is a proof of the piece of data that Faber embedded in the VC -- proving that Alice is the intended holder (hence -- authorized by the Issuer to present the claims).

In a paper driver's license, that is a picture of the person. In Indy AnonCreds, it is a blinded link secret that the holder proves in the presentation. It could be a DID with an associated key that the holder proves control over.

My concern is that I don't think how a mechanism like this could work is defined in the VC spec.

@agropper
Copy link

agropper commented Aug 12, 2021 via email

@mwherman2000
Copy link

mwherman2000 commented Aug 12, 2021 via email •
edited
Loading

@mwherman2000
Copy link

mwherman2000 commented Aug 12, 2021 •
edited
Loading

@swcurran

Background
In classic process analysis, a process step (desk procedure, task list, or statement of the work to be performs) includes 3 components:

  1. Entry criteria (preconditions for the process step to start)
  2. Desk procedure/task list/statement of the work to be performed
  3. Exit criteria (postconditions that must be met for the process step to end and transition to the next process step (subject to it's entry criteria).

Here's an illustration from https://www.researchgate.net/publication/242573971_Basic_Concepts_and_Techniques ...

image

Discussion

Stephen, back to your original question/comment, I thought you were highlighting the entry criteria (preconditions) necessary for an Actor to create and present a Verifiable Presentation VP to another party (e.g. an Actor in a Verifier role) ...assuming the underlying Verifiable Credential VC has been created, issued, and exists "somewhere".

As an example of these preconditions, the Actor Alice needed to belong to or possess the Holder role (i.e. the Actor has an Agent A and in turn A has a Wallet W), etc. The rest of the list of preconditions (quite detailed) is what I wrote down here: #788 (comment)

Does this connect with your thinking? In this thread, I was asking for your review of the list of 10 preconditions for completeness as well as outright errors for the scenario;

...entry criteria (preconditions) necessary for an Actor to create and present a Verifiable Presentation VP to another party (e.g. an Actor in a Verifier role) ...assuming the underlying Verifiable Credential VC has been created, issued, and exists "somewhere".

@dlongley
Copy link
Contributor

@agropper,

I can share a link secret or private key with anyone I want. If the reputation associated with the private key is semi-disposable, I can do that without much worry.

I agree and this touches on one of the important things that would need to be noted in any language added to the spec around this concept.

If the presentation is unlinkable, there isn't even a reputational aspect that could be used to discourage sharing (i.e., to enable "cheaters to get caught"). We'll need to understand whether a "bound VC" is intended to be unlinkably presented or not. There are several different ways a binding could be done and each of those ways have different security/privacy characteristics.

For example, if the same link secret is used where reputation is important for some presentations and not others, a remote API can be constructed that allows covert shared use of that link secret without having to share the link secret material itself. This enables use of such a link secret to be selectively shared without detection by the verifier. I agree that some form of identity proofing (e.g., biometrics) can be used to prevent this style of attack so as to ensure valuable reputation is at risk for attackers.

@dlongley
Copy link
Contributor

@mwherman2000,

I disagree… you can share your Driver’s License (or mDL) with anyone. It won’t be valid nor positively verifiable (as well as possibly illegal) but in theory as well as reality, you can choose to share virtually any (all?) credentials with anyone.

I think the disagreement is over the definition of "share". Perhaps "misuse" or "misuse with / without detection" would be better terminology. @agropper's point was that it is significantly more challenging to misuse a credential (without detection) where a verifier requires a binding biometric check than it is to misuse a credential (without detection) where the verifier does not have that requirement.

@David-Chadwick
Copy link
Contributor

@David-Chadwick -- what you say is the point I'm trying to make. If you use the subjectID field for the proof-of-holder, then except for "subject = holder", it can't be used for the actual subject of the VC. In your case, despite the subject being the company, the subjectID is a key held by the holder -- a director, secretary or employee. If instead the holderID was used for the proof-of-holder, then the subjectID would be available to identify the actual subject.

this is not necessary because the subject properties (i.e. claims) can both identify the subject (e.g. company name) and provide an identifier for the subject (e.g. company registration number).

So my feeling now is that subjectID should really become the proof of possession identifier.

From that, my first question becomes -- is this what everyone is doing, and so the horse is out of the barn? Is it now common practice to use subjectID for "proof of holder" regardless of the VC and the subject?

All I can say is that it is what we are doing. I cannot speak for any other implementors

My second question is where the concept of proving the holder is as designated by the issuer should go, both in the spec. and in the data model. This seems to be some tribal knowledge that this can and should happen, but it is not clear (to me at least) how that is supposed to work.

Again, the issuer can identify the holder in the claims by providing either its identity or identifier or both.
There is no restriction on the number or type of claims that can be included in a VC.

It can't go in the verifiable credential itself, since the VC is constructed by the issuer.

Thats precisely why it CAN go in the VC itself, because the issuer gave the VC to the holder (and not to the subject).

Thus, I would think it would have to be in the verifiable presentation. There is a "holder" data item, but how would that be used to provide a proof from the holder that the issuer issued the credential to them?

Simple. The issuer of the VP is the holder, and the holder is the subject ID of the VCs embedded in the VP. So it is trivial to check they are the same, especially if it is a public key or DID

@swcurran
Copy link
Author

@David-Chadwick -- sounds like we agree on the needs and reality (using subjectID to mean holderID), but differ on whether it matters.

Regards:

That's precisely why it CAN go in the VC itself, because the issuer gave the VC to the holder (and not to the subject).

What I meant was that the proof that the holder is presenting can't go in the VC. A piece of data can go into the VC from the issuer to indicate "this is the holder I issued this VC to" can go into the VC, but a proof from the holder binding it to that piece of data is also needed from the holder with the presentation.

@David-Chadwick
Copy link
Contributor

@David-Chadwick -- sounds like we agree on the needs and reality (using subjectID to mean holderID), but differ on whether it matters.

Why do we differ on whether it matters or not? Ideally the property should be labelled with its semantic meaning, so in this respect it does matter. But I am asserting that the claims themselves (and VC type) can enable the verify to determine the difference. In the case of a bearer credential, the property is missing entirely because mere possession of the VC is proof enough that you possess it. So no further proof is needed and it does not matter in this case what the property is called as it is not there.

Regards:

That's precisely why it CAN go in the VC itself, because the issuer gave the VC to the holder (and not to the subject).

What I meant was that the proof that the holder is presenting can't go in the VC. A piece of data can go into the VC from the issuer to indicate "this is the holder I issued this VC to" can go into the VC, but a proof from the holder binding it to that piece of data is also needed from the holder with the presentation.

Agreed

@kdenhartog
Copy link
Member

kdenhartog commented Aug 13, 2021 •
edited
Loading

@agropper,

I can share a link secret or private key with anyone I want. If the reputation associated with the private key is semi-disposable, I can do that without much worry.

I agree and this touches on one of the important things that would need to be noted in any language added to the spec around this concept.

If the presentation is unlinkable, there isn't even a reputational aspect that could be used to discourage sharing (i.e., to enable "cheaters to get caught"). We'll need to understand whether a "bound VC" is intended to be unlinkably presented or not. There are several different ways a binding could be done and each of those ways have different security/privacy characteristics.

For example, if the same link secret is used where reputation is important for some presentations and not others, a remote API can be constructed that allows covert shared use of that link secret without having to share the link secret material itself. This enables use of such a link secret to be selectively shared without detection by the verifier. I agree that some form of identity proofing (e.g., biometrics) can be used to prevent this style of attack so as to ensure valuable reputation is at risk for attackers.

@dlongley I agree with the premise here around reputation, but not the conclusion that the verifier can't detect it. There's been work to show that it's possible for a verifier to detect it without breaking the anonymity. So the point about having some form of skin in the game, I think is pertinent here, but I think the premise that a link secret doesn't support this is misleading. The key differentiating factor that I see between reputation based on a globally known identifier and an anonymous link secret is that a globally known identifier can be flagged and published so that ANY verifier could rely upon it without any additional complexity (a REALLY good thing when dealing with authorization logic), where as a link secret limits only the verifier who detects the reuse can rely upon it.

There's some caveats that could be used to work around this, but it requires a greater level of complexity in coordination between verifiers. This is done, by effectively building a coordinated federation of verifiers who register all the challenges and proofs that they request. With the link secret system the verifiers would have to coordinate challenge request information to prevent false positives from occurring and then on verification they also need to do the proof checking. None of this additional coordination complexity is necessary when the identifier is globally discoverable - which makes it much easier to scale.

So in summation, I'd say it is possible but the link secret system requires more complexity to achieve the same outcome, with the obvious tradeoff being that the additional complexity in the management of these coordinated challenge requests and proof verification is the holder is able to maintain their anonymity of the identifier.

@dlongley
Copy link
Contributor

@kdenhartog,

I agree with the premise here around reputation, but not the conclusion that the verifier can't detect it. There's been work to show that it's possible for a verifier to detect it without breaking the anonymity. So the point about having some form of skin in the game, I think is pertinent here, but I think the premise that a link secret doesn't support this is misleading.

The proposals from that paper were responded to in a publication here: https://ieeexplore.ieee.org/document/9031545

IIRC, that method effectively substitutes a Pedersen commitment for an El Gamal one, eliminating the perfect hiding property (you only get to choose one: "perfect hiding + computational binding" or "computational hiding + perfect binding"). So, while that may achieve the goal of a perfect binding, it also creates a scenario where it becomes much more likely that future computational attacks could probabilistically reveal the user's identity in a number of interactions that were supposed to be safe even into the future. This approach is therefore particularly problematic in systems where a single link secret is shared across many different identities. If some of the guarantees that make link secrets of interest to begin with are lost with this approach -- then I believe it's hard to say it's all that viable of a solution.

@kdenhartog
Copy link
Member

kdenhartog commented Aug 13, 2021 •
edited
Loading

then I believe it's hard to say it's all that viable of a solution.

That's a fair point, I had forgotten about that correlation issue that comes about with it. So, I agree it's not universally viable which means that each use case needs to evaluate if it is applicable for their needs. I can see how you've ended up on the conclusion that in that case it's probably best to not recommend it due to all of the additional complexity and the unclear responsibilities that allow for the use case to adversely impact the cryptographic guarantees which are dealt with at a completely different layer. If we were to put any recommendations around it, we'd definitely want to mention that caveat.

@swcurran
Copy link
Author

@dlongley -- and the paper you wrote/referenced above was rebutted here. There is disagreement.

My point in raising this issue is to call out that binding a VC to it's holder at issuance time, and verifying it on presentation is necessary in many use cases, is assumed by many to be possible with VCs, and yet is not clearly called out anywhere in the spec. In my reading of the spec, it would appear to be discouraged.

Related, but less fundamental to the VC model, is whether such a holder binding requires a unique identifier for the Holder be exposed, or if other approaches are possible. I personally think that it is worth pursuing an approach where simply presenting a VC does not require such an exposure and would not like the spec to forbid that approach. I gather you would not try to use such a feature, and that too should not be forbidden.

Is that a reasonable summary?

@dlongley
Copy link
Contributor

dlongley commented Aug 13, 2021 •
edited
Loading

@swcurran,

and the paper you wrote/referenced above was rebutted here. There is disagreement.

Yeah, the points the paper makes are largely misunderstood in that rebuttal. It also has an unseemly introduction that focuses on casting aspersions on the authors. I stand by the published paper.

You don't want to change your commitments from perfectly hiding to computationally hiding when you could instead reveal a use-case appropriate correlational/binding identifier. It's a bad idea to mislead people into thinking their secrets will stay safe indefinitely when obfuscated and handed over to the very party they don't want to see them. My advice is to never intentionally hand someone a computationally hidden secret that you never want them to know.

I will repeat that computationally hiding is not the same thing as perfect/statistical/unconditional hiding here -- since that point has been lost in the past. The IEEE paper was criticizing computationally hiding commitments (this very approach to solving the reputation/link secret reuse problem that we're discussing here in this issue and that the paper was written in response to). I only repeat this again because the rebuttal paper had a whole section on perfectly hiding commitments (the other kind of commitment) which was written with the perspective that the authors of the IEEE paper must just misunderstand them, but it was the rebuttal that was off target.

Now, of course, if you have to reveal a correlational identifier in a majority of use cases, one has to question whether it's worth creating a complex system of link secrets and credential definitions to avoid revealing one... just so one can claim that the system uses zero knowledge proofs (i.e., the proving system itself leaks no additional information beyond what is to be proved). Every benefit must be weighed against its drawbacks. This main point of practicality continues to be lost (or just rejected?) on some. There are all kinds of systems one can add or build off of that would be self-contained. But are they worth the cost if their benefits are largely lost or if they require new mitigations for the majority of use cases?

The argument the paper made was that it was not worth it; every attempt made to hide information just ended up requiring more information to be put back somehow to meet most use cases (and usually put back in a more complicated way). These are the sorts of things spec readers will want to know if we give any guidance here.

Thankfully, BBS+ dispenses with many of the aforementioned costs and provides for selective disclosure that can reveal what is needed to solve the trust and reputation problem -- without the overhead of the link secret approach. It is important to note that a correlational identifier of some sort still must be revealed/provided to get the kind of trust characteristics desired by verifiers in most "attribute-based credential" use cases. But you're not paying the same complexity and infrastructure cost in adopting BBS+ to get the desired selective disclosure, making the trade off palatable. I should add that I haven't yet done a deep dive on the BBS+ approach, but I am aware that it is a "slot in" in the existing VC ecosystem vs. requiring a whole separate ecosystem and supporting infrastructure to be created.

Related, but less fundamental to the VC model, is whether such a holder binding requires a unique identifier for the Holder be exposed, or if other approaches are possible. I personally think that it is worth pursuing an approach where simply presenting a VC does not require such an exposure and would not like the spec to forbid that approach. I gather you would not try to use such a feature, and that too should not be forbidden.

Is that a reasonable summary?

Yes. I have no problem with the spec discussing the benefits and drawbacks of any approach.

@kdenhartog
Copy link
Member

kdenhartog commented Aug 14, 2021 •
edited
Loading

My point in raising this issue is to call out that binding a VC to it's holder at issuance time, and verifying it on presentation is necessary in many use cases, is assumed by many to be possible with VCs, and yet is not clearly called out anywhere in the spec. In my reading of the spec, it would appear to be discouraged.

Yeah I've come to figure out that we're coupling the identifier in credentialSubject.id in a few different ways and it's caused confusion about it's purpose. I tried to explain that in this #790 (comment)

After writing that up, I'm thinking it would be useful to explicitly identify the credentialHolder in a separate part of the credential separate from the credentialSubject to better decouple these concepts. And in the case when subject == holder, they could share an identifier to convey that - and we'd probably need to figure out a way to make this align with ZKPs. Curious what peoples initial thoughts are on doing something like that (and @msporny was this discussed previously in the group).

@mwherman2000
Copy link

mwherman2000 commented Aug 14, 2021 •
edited
Loading

I think the disagreement is over the definition of "share".

Let's start with this first issue. Here's a working definition of share (that works for me):

The words partake and participate are common synonyms of share. While all three words mean "to have, get, or use in common with another or others," share usually implies that one as the original holder grants to another the partial use, enjoyment, or possession of a thing.
Reference: https://www.merriam-webster.com/thesaurus/share

@msporny
Copy link
Member

msporny commented Aug 14, 2021 •
edited by kdenhartog
Loading

I'm thinking it would be useful to explicitly identify the credentialHolder ... @msporny was this discussed previously in the group)

There was discussion about this and we decided to put the concept of "credentialHolder" in presentation: https://w3c.github.io/vc-data-model/#presentations-0

I'm also very supportive of clearing up @swcurran's concern in the specification:

@swcurran wrote:

My point in raising this issue is to call out that binding a VC to it's holder at issuance time, and verifying it on presentation is necessary in many use cases, is assumed by many to be possible with VCs, and yet is not clearly called out anywhere in the spec.

... and the most likely place to do this in the current spec is this section:

https://w3c.github.io/vc-data-model/#validation

... perhaps by adding a section called "Holder" and elaborating in there on all the ways you can do this sort of validation. I do think we need to do quite a bit of clean up on Appendix C Subject-Holder Relationships... because there is messy overlap between the two sections. I'll also note that some parts of this establishment gets into protocol, and talking too much about that in a normative way in the VC spec is problematic (as the spec then jumps into protocol, which the group wasn't chartered to do at the time (and will almost certainly not be re-chartered to do in the next 12 months or so).

So, we should address @swcurran's issue, probably in Appendix A. Validation, by adding a new section on Holder.

I would like @swcurran to take an action to write up some text so the Editors don't have to guess on what he would like clarified in the specification. I can certainly help (as will the other editors) put it into context in the specification.

@kdenhartog
Copy link
Member

I accidently edited @msporny original point rather than creating my own comment which is below. Going to have to revert his discussion point as well for coherence. Sorry about the confusion.

I'm thinking it would be useful to explicitly identify the credentialHolder ... @msporny was this discussed previously in the group)

There was discussion about this and we decided to put the concept of "credentialHolder" in presentation: https://w3c.github.io/vc-data-model/#presentations-0

Interesting point, I'm realizing now this may inadvertently not align with where we've been looking at things lately. In some cases, we've found it important for the verifier to know that the issuer did their due diligence in binding the credential to the subject. One of the most common ways this could be done today is through the use of an image, but I could imagine ways that this could be done with knowledge challenges as well. An example would be verifier asks for the birthday name to match the information on the credential. There's likely more ways to improve in the "what you know" and "what you are" authentication classes to improve subject binding more.

However, the thing I'm realizing is that the "what you have" authentication class is actually more specifically tied to holder bindings. In some cases, authenticating the holder is good enough to also authenticate the subject (this is the premise of webauthn after all). I think this conflation between subject binding and holder binding though combines with us not doing any upfront holder authentication and binding allows for a slight disconnect here. In the case of the holder property in the presentation this is almost always (in DID+VC use cases where holder = subject) being used in a way to check that the holder matches the subject of the credential AND that the presumption between holder binding being "good enough" for subject binding. These architecture couplings have been useful for the majority of the use cases so far, but I'm thinking these discussions that we should consider separating these things out.

In particular, as a verifier, there's likely a case where we'd like to be able to verify that the holder binding done at the time of issuance matches with the holder binding at the time of presentation. An example where this could be abused (and the reason it's important) is the following use case:

  1. ACME corp under the issuer DID did:example:acme issues credential A to Alice under holder did did:example:holder
  2. ACME University under the issuer DID did:example:uni issues credential B to Alice under the holder did did:example:holder
  3. Alice adds Bob's key to did:example:holder and gives credential A to Bob
  4. Verifier Corp asks Bob for a credential that matches credential A - so Bob gives credential A and uses the key added to did:example:holder

In this case, there was no holder binding that occurred during the issuance phase (even if subject binding did - e.g. Alice is claim x in credential A) allowing Alice to transfer the credential to Bob. By separating out the subject binding from holder binding and allowing for the issuer to assert this binding (and how they conducted the binding maybe?) we're allowing for the verifier to detect these concerns more explicitly.

@swcurran is this the thing that you're trying to highlight better?

I agree with @msporny here that having you write up an initial PR on the topic will help and afterwards we can work on figuring out what's the best way to handle it from there.

@David-Chadwick
Copy link
Contributor

@kdenhartog The example you provide of using DIDs to identify the holder, where arbitrary keys can be added to the DID document by the holder, shows the security vulnerability in this particular type of DIDs. Any number of users can collude in this way and break the entire system. One solution is to define a DID that is linked to one key, and one key only (which incidentally is what we have done in our implementation) to stop this type of collusion from happening. But of course this still does not stop multiple users from colluding and sharing the same key pair, especially if the private keys are held in software. So this argues for only holding private keys in hardware that cannot be shared (or is very inconvenient or costly to share).

@msporny
Copy link
Member

msporny commented Nov 30, 2022

@awoie wrote:

I can see two options:

  • the issuer provides some information in the VC itself (similar to nonTransferable but more flexible), e.g., a cryptographic identifier, claims, biometrics etc.
  • the holder (or presenter) provides some information in the VP (to give the verifier guidance on which binding mechanism was used, e.g., some additional proofs that link the presenter with the issuee such as a delegation object)

The first option feels like it would be less prone to attack than the 2nd option. The 2nd option feels like one might be able to construct an attack by mixing/matching additional proofs w/ a credential that it might not be tied to. Can't say more without seeing more details, but that's an initial gut reaction on how difficult defending the first option would be vs. the 2nd option.

The 1st option was what we were trying to accomplish with the evidence property. @jandrieu had suggested including a DIDAuth in evidence. Others had suggested including information related to a physical document that was checked, and a DIDAuth binding that was done (as two pieces of evidence). Just more info for the discussion, not saying we need to use the same mechanism yet.

@OR13
Copy link
Contributor

OR13 commented Nov 30, 2022

I'm a +1 for figuring out how to make holder binding use evidence.

Another use case for evidence is a platform authenticator or passkey reference...

In that case, the evidence represents an authentication that happened for the subject at the time of credential issuance.

This kind of thing can leak data in ways that impact user privacy, see this section of webauth:

https://www.w3.org/TR/webauthn-2/#sctn-non-correlatable-credentials

@David-Chadwick
Copy link
Contributor

Just to remind folks that in our recently completed NGI-Atlantic project (Next Generation SSI Protocols) we defined using the Evidence field to signal the strength of authentication (or LoA) by integrating both the NIST standard and the eIDAS standard values. I copy it below in case others might find it useful

 "evidence":[
      {
         "type":["https://eur-lex.europa.eu/eli/reg/2014/910/oj"],
         "description":"this is the URI of the eIDASv1 regulation. It will need updating to the URI of eIDASv2 when it is available",
         "loa":"low|substantial|high"
      },
      {
         "type":["https://doi.org/10.6028/NIST.SP.800-63-3"],
         "description":"this is the URI of the NIST Special Publication 800-63 scheme",
         "aal":"refers to the authentication process, has values 1, 2 or 3",
         "ial":"refers to the identity proofing process, has values 1,2 or 3",
         "fal":"(optional) refers to the strength of an assertion in a federated environment, used to communicate authentication and attribute information. Has values 1,2 or 3"
      }
    ]

@msporny
Copy link
Member

msporny commented Nov 30, 2022

we defined using the Evidence field to signal the strength of authentication (or LoA) by integrating both the NIST standard and the eIDAS standard values.

Yes, and that approach is aligned with the intention of the evidence property (though the markup provided looks a bit questionable... it's in the right ballpark). I expect that we might be able to do something there wrt. "holder binding".

@jandrieu
Copy link
Contributor

jandrieu commented Dec 1, 2022

The first option feels like it would be less prone to attack than the 2nd option.

The 2nd option is required and that has nothing to do with security. It has to do with semantics and business logic.

We currently have ambiguous semantics about what it means when a holder presents a credential. In some cases, we assert that you can check the signature and the subject ids to prove "holder binding". That's great as far as it goes (it is MUCH better than username/password binding), but that is a limited approach that fails known, documented use cases. See https://www.w3.org/TR/vc-use-cases/#citizenship-by-parentage

Until we add a mechanism for the holder to explicitly express their intention with regard to the act of presentation, none of this will be able to support the actual business rules that verifier/validators need to check.

That said, I concur with @OR13's suggestion

the evidence represents an authentication that happened for the subject at the time of credential issuance.

That is a perfectly good way for the issuer to document the level of authentication they achieved prior to issuing that specific credential.

Then we have to find a way for the holder to express WHY they are presenting the VC to the verifier and we should have both sides of the question well addressed.

@RieksJ
Copy link

RieksJ commented Dec 6, 2022

I can see how you could stuff a property in the evidence field that is the combination of an id property and an authenticator property as suggested by #760. The authenticator property might be extended to include a LoA field.

@OR13
Copy link
Contributor

OR13 commented Dec 6, 2022 •
edited
Loading

Perhaps we should take alignment with WebAuthN / FIDO to its own issue?

@awoie
Copy link
Contributor

awoie commented Dec 13, 2022 •
edited
Loading

There was a lot of good discussion and it feels like people generally think that we need to make room for "holder binding" in the VCDM.

Coming back to my proposed two options:

  1. the issuer provides some information in the VC itself (similar to nonTransferable but more flexible), e.g., a cryptographic identifier, claims, biometrics etc.
  2. the holder (or presenter) provides some information in the VP (to give the verifier guidance on which binding mechanism was used, e.g., some additional proofs that link the presenter with the issuee such as a delegation object)

Again, I want to emphasize that both options are not mutually exclusive in my mind and I believe everybody believes that both options (or holder binding) should be made optional in general.

IMO, option 1 is the more obvious choice which doesn't mean that we don't need option 2. If option 1 and option 2 are combined then for example, the issuer can say that the VC is bound to a number of binding methods, e.g., cryptographic identifier (such as a DID, or public key), and then in the VP the presenter would still need to provide guidance on what method should actually apply. For the sake of discussion, I believe it is easier to focus on option 1 first which could be an optional feature, and then let's have another discussion on option 2. IMO, option 2 is needed but it probably needs more discussion.

Regarding option 1, we will need to agree on the definition, data model and then obviously also add a section on privacy, vendor lock-in etc. considerations like described in #988.

Below, there are two proposals for option 1, A and B.

The proposals are the result of the discussions of the group that works on the Holder Binding paper that was initiated during RWOT. Final paper will be submitted soon, authors: Oliver Terbu, Paul Bastian, Snorre Lothar von Gohren Edwin, Rieks Joosten, Antonio Antonino, Nikos Fotiou, Zaïda Rivai, Stephen Curran, Ahamed Azeem.

A. Provisionally we can call it binding, the purpose of which is to enable parties (specifically those in the role of verifier), to determine which entity a particular identifier (i.e. credentialSubject.id) refers to when it is used in a VC or VP.

Example (usage of binding in credentialSubject):

{
   "credentialSubject":[
      {
         "id":"somevaliduri",
         "binding":[
            "<array of binding-elements>"
         ],
         "hasPassedExam":"SOL"
      }
   ]
}

Concrete binding examples (not a normative proposal -> can be added to registry later):

{
   "binding":[
      {
         "id":"somevaliduri",
         "type":"DidAuthenticationKeyBinding",
         "keyId":"did:example:deadbeefcafe#keys-3"
      },
      {
         "id":"somevaliduri",
         "type":"PassportBinding",
         "nationality":"NL",
         "passportNr":"012345678",
         "contentHash":"3338be69 ... 2398f392"
      },
      {
         "id":"somevaliduri",
         "type":"PersonalCharacteristicsBinding",
         "characteristics":[
            "scan on left hand",
            "grey hair",
            "female",
            "needs walking stick to walk",
            "speaks swahili"
         ]
      }
   ]
}

B. Alternatively, we can reuse the evidence property, which has the downside that it is less flexible.

Example (usage of binding in evidence):

{
   "credentialSubject":[
      {
         "id":"somevaliduri",
         "hasPassedExam":"SOL"
      }
   ],
   "evidence":[
      {
         "type":[
            "Binding",
            "<ConcreteBindingMethod>"
         ],
         "id": "somevaliduri"
      }
   ]
}

Concrete binding examples (not a normative proposal -> can be added to registry later):

{
   "credentialSubject":[
      {
         "id":"somevaliduri",
         "hasPassedExam":"SOL"
      }
   ],
   "evidence":[
      {
         "type":[
            "Binding",
            "DidKeyAuthenticationBinding"
         ],
         "id":"somevaliduri",
         "did":"did:example:123456"
      },
      {
         "type":[
            "Binding",
            "PassportBinding"
         ],
         "id":"somevaliduri",
         "nationality":"NL",
         "passportNr":"012345678",
         "contentHash":"3338be69 ... 2398f392"
      },
      {
         "type":[
            "Binding",
            "personalCharacteristics"
         ],
         "id":"somevaliduri",
         "characteristics":[
            "scan on left hand",
            "grey hair",
            "female",
            "needs walking stick to walk",
            "speaks swahili"
         ]
      }
   ]
}

Do people agree that we should focus on option 1 first?

Does A or B resonate better with people as concrete proposals for option 1?

@awoie
Copy link
Contributor

awoie commented Dec 13, 2022 •
edited
Loading

The above proposes the binding property to be specified as an array of elements that enable the identification and authentication of some entity, where each element consists of:

  • an (optional) id field, i.e. the identifier that refers to the entity that can be identified and authenticated by the contents of this binding-element. If the id property is not specified, then the binding-element can be used to identify and authenticate the entity to which the sibling-properties of binding are attributed.
  • a (required) type field, i.e. an identifier that specifies the method for identifying and authenticating the entity, using the key-value pairs (see following item).
  • a set of key-value pairs, where they keys are particular to the specified binding type, and the values will be used as the method specified in the type field specifies, so as to identify and/or authenticate the entity, as intended by the author of the binding property

A similar definition would apply to evidence.

@paulbastian
Copy link

paulbastian commented Dec 13, 2022 •
edited
Loading

As the proposals above are from the RWOT group on "Holder Binding", I would like to express my personal view that I believe the source of truth is the usually the issuer, and therefore the binding property should be stated in the VC and signed by the issuer.
Use cases where binding information is stated in the VP by the holder seem more complex and are unclear to me.
I would propose to separate the discussions on (holder) binding on these variants as the topic is already complex enough

@mwherman2000
Copy link

mwherman2000 commented Dec 13, 2022 •
edited
Loading

I would like to express my personal view that I believe the source of truth is the usually the issuer

Maybe "usually" but I believe more and more this will not be the case: the "source of the truth" will be a second party. First, at a minimum, let's agree the Issuer is the entity that attaches a verifiable proof to a VC. Then consider a commercial scenario where ABC Grocery wants to "issue" a Purchase Order Verifiable Credential to David's Cabbages (like the one below).

image

ABC Grocery is likely to enlist the Issuing services of a mutually trusted Izzy Issuer to take ABC Grocery's purchase order credential and embed it into a Verifiable Credential that Izzy Issuer signs (attaches a Proof). In this scenario, ABC Grocery is the "source of the truth" but is not the Issuer. Conversely, Izzy Issuer is the Issuer but not the "source of the trust". Izzy Issuer is an Issuer that ABC Grocery and David's Cabbages both trust; perhaps they are all members of the same trading consortium.

@jandrieu
Copy link
Contributor

I would like to express my personal view that I believe the source of truth is the usually the issuer, and therefore the binding property should be stated in the VC and signed by the issuer.

I agree that the issuer is the source of truth for the claims.

However, they cannot be the source of truth for the holder, because the actual holder at the point of presentation is not knowable. Fundamentally.

Imagining that the issuer is the source of truth for more than the attestation made in the claims will create forms of control that are inappropriate for this work.

So to the extent that verification depends on the holder being "approved" by the issuer, it is inappropriate.

To the extent that the issuer is either

  1. providing guidance about how the subject might be authenticated, or
  2. providing evidence or claims about how the issuer authenticated the user prior to issuance

Then we have usage that I can support.

The distinction made today on the call about the difference between verification and validation are vital to understanding the right way to factor the data model. What we need are more flexible ways to express expectations for validation, and in the VP, statements by the holder to support validation that satisfies a breadth of use cases, including the application for citizenship that is in the current use cases document.

@dlongley
Copy link
Contributor

To the extent that the issuer is either

  1. providing guidance about how the subject might be authenticated, or
  2. providing evidence or claims about how the issuer authenticated the user prior to issuance

Then we have usage that I can support.

+1 to this.

@RieksJ
Copy link

RieksJ commented Feb 7, 2023

To the extent that the issuer is either

providing guidance about how the subject might be authenticated, or
providing evidence or claims about how the issuer authenticated the user prior to issuance

I would rephrase that as

To the extent that the issuer is either

  1. providing guidance about how any subject (of any claim in a VC) might be authenticated, or
  2. providing evidence or claims about how the issuer has identified and/or authenticated such a subject prior to issuance.

Since the term 'user' is not defined, and there is no link specified to this 'user' and any of the subjects of claims in a VC. This is different in AnonCreds (assuming that 'user' would be the person requesting the issuance of a credential), but then, this is about VCs and not about AnonCreds.

Note that these assumptions of users (or holders) occur regularly outside the scope of the VCDM. For example, Dutch law about drivers licenses and passports say that the holder ('houder' in Dutch) of such documents ARE the subject to which the attributes in the document pertains (as with AnonCreds). VCDM explicitly states that this is not the case for VCs (which can hold multiple claims for different subjects). Also, VCDM has a different definition for 'holder' and that's ok - it happens all the time that a term means different things in different contexts. The point is that in a particular context (e.g.: VCDM) a term should only be used in the meaning as it is defined for that context. See also #902 (comment).

@RieksJ
Copy link

RieksJ commented Feb 7, 2023

What an issuer is for a VC is a holder for a VP. So It seems reasonable to assume that the same mechanisms that would enable a verifier to request data from claims/VCs that originate from a specific issuer, would similarly apply to enabling verifiers to request data from claims/VCs in a VP that is presented (issued) by a particular holder.

This could imply that apart from the holder's signature, it might add additional stuff in a presentation to enable verifiers to do this. That might, e.g., be in the form of a VC that contains a binding as proposed in this RWOT-11 paper.

@Sakurann Sakurann added ready for PR This issue is ready for a Pull Request to be created to resolve it and removed discuss labels Feb 16, 2023
@Sakurann
Copy link
Contributor

PR for #882 that we agreed to do during Miami F2F should cover this issue too.

awoie pushed a commit that referenced this issue Feb 27, 2023
fix: first stab on #789
c08f81a
@awoie awoie mentioned this issue Feb 27, 2023
Closed
3 tasks
@awoie
Copy link
Contributor

awoie commented Apr 25, 2023

IMO, this is a duplicate of #882 and can be closed, or the other way around.

@msporny
Copy link
Member

msporny commented Apr 25, 2023

IMO, this is a duplicate of #882 and can be closed, or the other way around.

If @swcurran agrees, we can close it. I agree that they're dupes.

Given that we have a PR under debate for the feature: #1054 -- we might hold off until we see what happens to that PR, or we might just de-dupe now. I'm fine w/ either.

@swcurran, thoughts?

@swcurran
Copy link
Author

I’m fine either way.

@msporny
Copy link
Member

msporny commented Apr 25, 2023

I’m fine either way.

Ok, I'll mark this as pending close due to the dupe (we're trying to clean up / close issues as we head into the Candidate Recommendation phase).

We'll close in a week unless there are objections.

The discussion will continue in #882 and #1054.

@msporny msporny added pending close Close if no objection within 7 days and removed ready for PR This issue is ready for a Pull Request to be created to resolve it labels Apr 25, 2023
@Sakurann
Copy link
Contributor

Sakurann commented May 2, 2023

closing since one week has passed

@Sakurann Sakurann closed this as completed May 2, 2023
@TallTed TallTed mentioned this issue Apr 3, 2024
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@awoie awoie

Labels
holder-binding Issues related to holder binding pending close Close if no objection within 7 days
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add confidence method to VCDM w3c/vc-data-model