Re: [PROPOSED WORK ITEM] Verifiable Issuers and Verifiers

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 Saturday, 17 December 2022 20:34:23 UTC