- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 18 Dec 2022 13:51:55 -0500
- To: Alan Karp <alanhkarp@gmail.com>
- Cc: W3C Credentials CG <public-credentials@w3.org>
On Sat, Dec 17, 2022 at 7:37 PM Alan Karp <alanhkarp@gmail.com> wrote: > That being said, my point stands. "Can I trust X to do Y?" has a different connotation than "How am I vulnerable if I ask X to do Y? In my experience the former gets people thinking about ways the request can fail, while the second gets them thinking about broader issues. Yes, I agree that the second question is more impactful than the first one when designing systems and trying to predict their outcomes. > Let me try again. The company Alice submits the VC representing her transcript to asks a verifier if it is valid. Asking the "trust" question makes people worry that the verifier might not validate a valid VC or that it will validate an invalid one. Asking the "vulnerability" question is more likely to get people worrying about other potential problems, such as the verifier releasing a list of who is asking to have whose transcript verified. Yes, understood. It's one of the reasons we tried to stay away from words like "trust" or "registry", as it took the conversations in a direction that tended to expand scope instead of focusing scope. The question of "vulnerability" really came up in the RWoT paper when we started talking about "Verifiable Verifier Lists" -- that is, lists of entities that might ask you to verify a particular VC. Namely, vulnerability to law enforcement (police), those that are expected to act on behalf of the law (retailers selling medicine or alcohol), or pretend to be law enforcement (criminals). For example, who should have the right to ask you to provide all the information in your digital passport? Should your digital wallet warn you when you're about to hand over your information to an entity that might make you more vulnerable than you'd expect? How do you convey that information (presumably, through a Verifiable Verifier List)? Who is supposed to convey that information? ... and then any "protection" naturally conflicts with an individual's agency -- you probably don't want a digital wallet to outright block the selective disclosure of your name on a passport with an entity that you already, out of band, know and trust. All that to say that "vulnerability" was a part of the discussion that led to the paper and the resulting specification, but we often ended up in the land of gray areas and unsure futures if we took the conversation too far. Vulnerability, like trust, is highly context dependent and it's unlikely that we'll create ONE technology (or strategy) to address most of the sticky questions. I do agree with you that it's a useful way to ask the question. In the meantime, we do have a concrete and focused need to share a list of issuers that an entity thinks are qualified to issue a particular type of verifiable credential. Generally speaking, that's what this particular work item is about. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/
Received on Sunday, 18 December 2022 18:52:43 UTC