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

Holder-Binding: Needs Privacy & Correlation, Centralization/Lock-in Considerations #988

Closed
ChristopherA opened this issue Nov 30, 2022 · 22 comments
Closed

Holder-Binding: Needs Privacy & Correlation, Centralization/Lock-in Considerations #988

ChristopherA opened this issue Nov 30, 2022 · 22 comments
Assignees
@awoie
Labels
blocked discuss holder-binding Issues related to holder binding pending close Close if no objection within 7 days

Comments

@ChristopherA
Copy link

I have a concern that some proposed holder-binding approaches may have unanticipated privacy & correlation issues and also that holder-binding may be an entree for parties to create centralization or lock-in, or worse, create human-rights issues.

I'd like to see any proposal for holder-binding to offer, in a clear and separate section, how their proposal addresses these concerns.
@awoie awoie added the holder-binding Issues related to holder binding label Nov 30, 2022
@nadalin
Copy link

nadalin commented Nov 30, 2022 via email

@jandrieu
Copy link
Contributor

jandrieu commented Dec 1, 2022

There's nothing wrong with parties that want to create centralization. There is nothing that says it has to be decentralized we should make this work for both without privacy concerns.

On the contrary, VCs were designed for decentralized use cases precisely because there are plenty of ways to solve these problems for centralized use cases and NONE that address the needs in a decentralized manner. It's trivial for a central player to define their own format, schema, and semantics. That's what big players do. That is a different problem than what we are here for.

The work of VCs is to provide a way to verify attestations without dependence on a trusted mediator, including overreliance on the issuer for anything other than checking to see if a VC remains in good standing, and even for that, we have designed solutions that specifically avoid the phone home problem common to centralized architectures.

So, I refute categorically that centralized solutions have any merit for driving the design decisions of this work.

More pragmatically, if it works in a decentralized manner, it can ALWAYS work for centralized players. So "centralized" players can use decentralized technology, but the inverse is not always true. People who need decentralized solutions cannot rely on centralized parties like IANA and the ITU and Facebook because for their use cases, such reliance would undermine the entire point of the innovation.

If you want to build centralized solutions with decentralized tech, go for it.

If you want to innovate to build centralized tech with similar properties, go for it. Somewhere else.

If you want to argue that a decentralized solution should adjust its design to better satisfy centralized players, please don't. That's not what this work is about.

@nadalin
Copy link

nadalin commented Dec 1, 2022 via email

@vongohren
Copy link

vongohren commented Dec 1, 2022 •
edited
Loading

So I see @ChristopherA suggestion as a fair concern. I assume we are all pointing to the holder binding work that is proposed by @awoie and that group? Including me to just put that on the table

If so, all I read into @ChristopherA proposal is basically that:

When someone creates a holder binding type, the document standard for that type have to adress these parameters, so it is clear for everyone, that using this holder binding type will need centralized ways of doing things. Basically that the standard to that says you can build whatever type you want also states that you need to input this information into the type document.

If this is not related to the holder binding work I earlier mentioned, then have a quick look at the presentation: https://docs.google.com/presentation/d/1k88h_41dcAdstXMzvfN7OR-mVbSUVbrp7FMnt3LqHok/edit#slide=id.p to see what I mean with types.

Paper coming soon :D @awoie, anything we can release early?

@dlongley
Copy link
Contributor

dlongley commented Dec 1, 2022

@nadalin,

Verifiable Credentials have been designed to handle decentralized use cases from the start. I suspect nearly everyone who worked on them in the first WG thought this was self-evident and understood it to be a major driving purpose behind the work.

Of course, this does not preclude centralized use cases, given the asymmetry of the two organizational methods. As @jandrieu said, decentralized solutions can work for centralized use cases, but the same is not always true in reverse. So, you're right that centralized use cases are certainly welcome, but where there is conflict, the design prioritizes decentralization because of this asymmetry.

@nadalin
Copy link

nadalin commented Dec 1, 2022 via email

@jandrieu
Copy link
Contributor

jandrieu commented Dec 6, 2022 •
edited
Loading

  • If you want to argue that a decentralized solution should adjust its design to better satisfy centralized players, please don't. That's not what this work is about.

WOW, This WG is open to all that meet the W3C requirements for joining, the WG can work on anything within the charters scope and what the WG agrees to do. There is nothing in the charter that says what we work on must be decentralized, I realize that may be what you want.

Yes, the WG is open as you say, and yes, it can work on anything the WG decides, within the scope of the charter.

So let's talk about the charter, starting with the opening statement on scope:

Building on the experience gained through implementation, deployment and usage of Verifiable Credentials (VCs), this Working Group will extend Verifiable Credential foundations with new standardized technologies to improve the use of this technology on the Web.

So let's talk about that experience, which at a minimum includes the VC 1.1 specification itself.

From the abstract:

This specification provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable.

It is well understood by those of us who contributed to that specification that cryptographic security and respecting privacy is achieve through decentralization. Rather than rely on a centralized authority, who might use a verification protocol to surveil the use of credentials by users, refuse certain cryptography, and restrict or prevent the use or verification, VCs use cryptography to verify authenticity without phoning home and completely under the control of the user.

Note also several of the innately decentralizing ecosystem characteristics distilled from the VC Use Cases document and presented directly in the specification itself:

  1. Issuers can issue verifiable credentials about any subject.
  2. Acting as issuer, holder, or verifier requires neither registration nor approval by any authority, as the trust involved is bilateral between parties.
  3. Verifiable presentations allow any verifier to verify the authenticity of verifiable credentials from any issuer.
  4. Holders can receive verifiable credentials from anyone.
  5. Holders can interact with any issuer and any verifier through any user agent.
  6. Holders can share verifiable presentations, which can then be verified without revealing the identity of the verifier to the issuer.
  7. Holders can store verifiable credentials in any location, without affecting their verifiability and without the issuer knowing anything about where they are stored or when they are accessed.
  8. Holders can present verifiable presentations to any verifier without affecting authenticity of the claims and without revealing that action to the issuer.
  9. A verifier can verify verifiable presentations from any holder, containing proofs of claims from any issuer.
  10. Verification should not depend on direct interactions between issuers and verifiers.
  11. Verification should not reveal the identity of the verifier to any issuer.
  12. The specification must provide a means for issuers to issue verifiable credentials that support selective disclosure, without requiring all conformant software to support that feature.
  13. The data model and serialization must be extendable with minimal coordination.
  14. Revocation by the issuer should not reveal any identifying information about the subject, the holder, the specific verifiable credential, or the verifier.

And that's just from the core spec itself.

What is contrary to the charter is willfully ignoring the experience gained through implementation, deployment and usage of Verifiable Credentials (VCs). As is intentionally undermining user-control, open-world cryptographic verification, and decentralization, rather than "extend[ing] Verifiable Credential foundations". You don't get to show up and claim the prior work doesn't exist, nor that it was created for different purposes than it was. There is ample evidence of exactly what that experience has been and what those foundations are.

Since you were an active commenter on the last spec prior to publication, I have to accept that you understand VCs and how they work. As such, your comments are disingenuous at best and willfully disrespectful and unethical at worst.

As such, I'll happily contextualize any assertions you make that, in fact, ignore that experience, such as your insistence that VCs are not inherently decentralized. They are. They were designed to be that way. Until and unless you can convince a consensus of this Working Group otherwise, they will continue to be defined that way.

@nadalin
Copy link

nadalin commented Dec 6, 2022 via email

@jandrieu
Copy link
Contributor

jandrieu commented Dec 6, 2022

Still nothing about decentralization in the charter, I realize that is what you want but its not there.

Now you're just being obtuse.

@nadalin
Copy link

nadalin commented Dec 6, 2022 via email

@jandrieu
Copy link
Contributor

jandrieu commented Dec 6, 2022

I quoted exactly where the charter explicitly defines the scope of work as building on experience to date. Then I quoted language directly from the specification that clarifies not just the experience to date, but the consensus of the group doing this work.

Together, that explains why I find your assertion that "There is nothing that says it has to be decentralized." to be not only in error, but intentionally disingenuous.

The entire work to date has been to make VCs that do not depend on overcentralization. The whole point has been to be decentralized. You can see that if you actually take the time to review the experience to date, as captured in the publications of the Working Group itself.

You may call that "my interpretation", but I stand by it as a representation of the actual consensus of this working group based on its own publications.

Your comment doesn't represent anything except your personal opinion.

@TallTed
Copy link
Member

TallTed commented Dec 7, 2022

@nadalin — Please take the extra minute on each email response you send to issues on GitHub, and edit the quoted material to which you are responding down to the bare essentials (which might be as few as zero lines) needed to understand your response. It helps NO-ONE, least of all you, to post a one-line reply to a hundred-line comment and include that entire hundred-line comment in your own reply message. TOFU ("text over, fullquote under") posting makes no sense when the entire thread, including the comment to which you're replying, is available up-window. This is not quite so bad when GitHub collapses that quoted material — so it's only visible if we click the button — but GitHub is not perfect at this collapse, as you can observe in this issue at #988 (comment) and #988 (comment). There are numerous examples in other issues and PRs.

@bumblefudge
Copy link

I'd like to see any proposal for holder-binding to offer, in a clear and separate section, how their proposal addresses these concerns.

Operationally, are you saying that the usual privacy & security considerations sections are inadequate to the extension-registry spec or are you asking for a separate section in the VC2 spec itself?

In either case, I haven't been contributing thus far to the RWOT group but I do feel strongly that this pattern is worth specifying (in large part because it will still happen if we don't specify it, and in a more footgunny way). I would gladly volunteer to help write and/or edit those clear and separate sections when the time comes as the other participants see fit.

@awoie awoie mentioned this issue Dec 13, 2022
Closed
@jandrieu
Copy link
Contributor

jandrieu commented Apr 4, 2023

@bumblefudge We discussed this today. Are you still interested in writing something up?

@iherman
Copy link
Member

iherman commented Apr 4, 2023

The issue was discussed in a meeting on 2023-04-04

  • no resolutions were taken
View the transcript

1.1. Holder-Binding: Needs Privacy & Correlation, Centralization/Lock-in Considerations (issue vc-data-model#988)

See github issue vc-data-model#988.

Kristina Yasuda: This is about holder binding and correlation..
… Anyone who wants to be assigned to this one?.

@awoie awoie self-assigned this Apr 5, 2023
@bumblefudge
Copy link

To clarify do you want a PR after #1054 is merged or before #1054 is merged?

@awoie
Copy link
Contributor

awoie commented Apr 12, 2023

We should say that the holder/subject should be able to satisfy the holder binding to prevent potential human rights and centralization issues. Basically, that there is a risk that issuers add holder binding methods that the holder/subject cannot satisfy by themselves.

We should also say that in the same way as with other claims about the subject, issuers have to be very careful with correlation risks and should be guided to use non-correlatable information in the claims they make about the subject if possible. @ChristopherA is there anything that you want to specifically call out in the privacy considerations section?

PR #1054 already says that verifiers don't have to use holder binding (or confirmation method) and can use any other claims from the VC instead to gain more confidence that the intended holder is on the other end of the transaction. @ChristopherA Does that work for you, or do want something more specific to be included in the text?

IMO, if @ChristopherA is fine with the above, we can start a draft a PR that adds language to the privacy considerations section @bumblefudge if you want to help and then we can merge that PR once PR #1054 gets merged.

@bumblefudge
Copy link

put me in, coach! I think waiting for #1054 to be finalized and merged would make it a lot simpler, if that's ok with the group

@awoie
Copy link
Contributor

awoie commented Apr 13, 2023

IMO, holder binding can also improve privacy by preventing unauthorized usage of the digital identity that is represented by the verifiable credential but obviously there is also risks related to privacy that have to be described.

@awoie
Copy link
Contributor

awoie commented Apr 25, 2023

This issue is blocked by the holder binding discussion.

@awoie awoie added the blocked label Apr 25, 2023
@brentzundel
Copy link
Member

With the direction that the group has elected to go (reserving confidenceMethod once a work item for it exists in the CCG, and otherwise dropping holder binding in the data model), I believe this issue should be closed.

Marking as pending close and will close in 7 days if no objections are raised.

@brentzundel brentzundel added the pending close Close if no objection within 7 days label Jun 21, 2023
@brentzundel
Copy link
Member

No objections raised to closing since marked pending close, closing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@awoie awoie

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

No branches or pull requests
10 participants
@ChristopherA @dlongley @jandrieu @iherman @vongohren @TallTed @nadalin @brentzundel @bumblefudge @awoie