Re: [PROPOSED WORK ITEM] Verifiable Issuers and Verifiers

You are right; it'a a bad example for VCs.  I'm lurking on several
different discussions, and I keep getting mixed up which one I'm on. :(

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.

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

Alan Karp

On Sat, Dec 17, 2022 at 12:34 PM Manu Sporny <>

> On Sat, Dec 17, 2022 at 3:14 PM Alan Karp <> wrote:
> > To stick with your university degree example, say that Alice asks her
> school to send her transcript to a prospective employer.
> Out of scope. :P
> The Verifiable Issuer/Verifier spec focuses on producing and sharing
> lists of Issuers that issue *this* type of VC, or Verifiers that ask
> for *this* type of VC. We were concerned that attempting to do more
> would boil the ocean and/or put us onto the slippery slope that is
> "trust". I'm now regretting even including the "T" word in the
> description. :)
> Identity and Trust are words that are a lightning rod in a boiling ocean.
> :)
> In the same way we avoided calling the first working group the W3C
> Identity Working Group (and instead focused on Verifiable
> Credentials), we are trying to avoid the creation of a W3C Trust
> Registry Working Group (and instead are focusing on the sharing of
> lists of verifiers and issuers -- whether or not you trust those lists
> is up to you -- it's a decentralized, individual choice).
> > Your question is, "Can Alice trust the university to send the transcript
> to that company?"  The implied risk is that the university won't or perhaps
> will send it to the wrong company, what I referred to as mis-performance or
> mal-performance.  My question also considers the risk that her university
> will inform her current employer of her request.  In other words, she is
> vulnerable to actions that are independent of her request itself.
> Yep, all of that is out of scope, and not how Verifiable Credentials
> are meant to be sent from Issuer to Verifier. The university should
> hand the transcript to Alice, who can then do what she wants with it.
> Alice can then give the transcript to a Verifier of her choosing. That
> approach creates none of the problems you outline above (but, of
> course, may have its own problems).
> To hone in where Verifiable Issuer/Verifier Lists might be used in that
> process:
> 1. When Alice receives her transcript from the university, her digital
> wallet/portfolio software could check to make sure the issuer is on a
> Verifiable Issuer List and warn her if she's getting a transcript that
> might be flagged.
> 2. When a Verifier requests a transcript from Alice, her digital
> wallet/portfolio software could check to make sure the verifier is on
> a Verifiable Verifier List and warn her if she's getting ready to hand
> her transcript over to an "unknown verifier for the purposes of
> verifying a transcript".
> 3. When the Verifier gets the transcript from Alice, it could check to
> make sure the issuer is on a Verifiable Issuer List and flag it for
> manual processing if it is not an accredited Issuer.
> I will highlight that all three of the items above could be abused and
> could be used to tilt the market... BUT, it's also true that the lack
> of such lists will make it more difficult for the market to scale to
> many issuers (which we do want to happen). Lists of verifiers is
> fraught... the number of times I've used my passport as ID overseas in
> places where I really shouldn't have is in the double digits... so, I
> expect verifier lists used by digital wallets would be more of a
> warning than a "do not transmit"... much like our web browsers warn us
> about sites that do not have proper security certificates installed.
> > You could say that the word "trust" encompasses all of that, but I've
> found that using "vulnerable" leads people to think more broadly about
> risks.
> Yes, agreed, but as I said above "trust" is an overused and loaded
> word... we're trying to focus on something more concrete and precise.
> -- manu
> --
> Manu Sporny -
> Founder/CEO - Digital Bazaar, Inc.
> News: Digital Bazaar Announces New Case Studies (2021)

Received on Sunday, 18 December 2022 00:37:56 UTC