Re: [PROPOSED WORK ITEM] Verifiable Issuers and Verifiers

“How can I trust the issuer?” Is a question that arises in not a few bit in virtually every use case we are pursuing in cross border trade - so I feel a strong affinity to this work item 

The thing that worries me in reading your proposal is the use of words like “list of trusted issuers”.  We will be addressing this problem not with lists but with chained credentials where the verifier follows the chain until it reaches a trust anchor that they can trust.  That’s because the lists are too big and fast changing and are themselves sensitive.  For example 
- how can I trust that product conformity certificate that says that product x meets standard y?” With 1000’s of certifiers working across 1000’s of specific standard criteria, the list in advance option runs into millions and changes hourly.  Much better if the national accreditation authority issues a VC to a certifier (ie the conformity testing body) that said “we accredit you to test and certify against standards a, b, and c”.  Then the verifier of a certificate of conformity credential need to follow the chain to the accreditation credential and confirm that the claim criteria type is found in the list of accreditation criteria type.  A nice JSON-LD value proposition at the same type FWIW - I don’t know how to do that semantic matching reliably without json-ld 
- dozens of other similar examples exist 

So Manu - will your new work item be willing to consider standardised solutions for semantic matching of criteria across chained credentials ? If so then I’d LOVE to participate - and do whatever W3C membership stuff is necessary 

Cheers 

Steven Capell
Mob: 0410 437854

> On 17 Dec 2022, at 8:17 am, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> Hi all,
> 
> A number of us have been collaborating over the past couple of months
> via Rebooting the Web of Trust, the Internet Identity Workshop, and
> weekly calls to unify the way anyone can share lists of issuers or
> verifiers that perform a particular function in an ecosystem. This
> work item is designed to answer questions like: "How can I trust that
> this diploma is real?" or "Should I send my digital ID to this person
> that is claiming to be law enforcement?". A draft version of this
> industry survey work can be found here:
> 
> https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/verifiable-issuer-verifier-lists/verifiable-issuer-verifier-lists.pdf
> 
> We'd like to turn that paper into a W3C Credentials CG Work Item. The
> work item focuses on how a party or its agent can decide whether or
> not to engage with a counterparty in a transaction (that is: "Can I
> trust X to do Y?"). The purpose of this work is to enable a party to
> share a list of Verifiable Issuers and Verifiers in a way that is
> useful to a particular transaction. The very drafty specification can
> be found here (and will be migrated to CCG if the group adopts the
> work item):
> 
> https://msporny.github.io/verifiable-issuers-verifiers/
> 
> Please support the adoption of the work item in CCG by adding your
> support in a comment here:
> 
> https://github.com/w3c-ccg/community/issues/238
> 
> Work Item Leads: @hendersonweb and @msporny (CODEOWNERS)
> Work Item Authors: @tsabolov @Oskar-van-Deventer @shigeya @lineko
> @RieksJ (expect these folks to also be CODEOWNERS)
> 
>> Explain what you are trying to do using no jargon or acronyms.
> 
> In the Verifiable Credentials ecosystem, it is currently difficult to
> know if you can trust the issuer of a Verifiable Credential. It is
> also difficult to know if you should send a sensitive Verifiable
> Credential to a Verifier that is asking for sensitive information.
> This specification provides a way to share a list of Verifiable
> Issuers (Universities that are accredited to issue Accounting degrees)
> or a list of Verifiable Verifiers (National Border Protection Officers
> that are authorized to ask you for identification documents) to be
> shared such that entities can make decisions on who to trust during
> particular transactions involving Verifiable Credentials.
> 
>> How is it done today, and what are the limits of the current practice?
> 
> Today, Verifiable Credential software needs to be configured by a
> systems administrator or an individual to specify which parties they
> trust to issue certain credentials or to receive certain credentials.
> Since there can be thousands of issuers and many more verifiers, it
> would be helpful if there was a standard to create lists of "trusted
> parties" that people could use as a starting point to understand who
> they can trust for certain credentials.
> 
>> What is new in your approach and why do you think it will be successful?
> 
> Our approach started by performing a broad industry analysis of many
> of the initiatives in the space to gather commonalities among all of
> the initiatives and then attempted to put the commonalities into a
> consistent set of use cases, requirements, data model, and
> serialization formats. We have proponents from many of the initiatives
> directly involved in the analysis and the work and expect those
> contributors to continue to provide input into the work ensuring broad
> alignment among a global set of stakeholders in a variety of
> industries.
> 
>> How are you involving participants from multiple skill sets and global locations in this work item? (Skill sets: technical, design, product, marketing, anthropological, and UX. Global locations: the Americas, APAC, Europe, Middle East.)
> 
> We started the work at Rebooting the Web of Trust 11, which included
> participants from the Americas, Europe, and Japan and included work
> from a variety of global initiatives. We then circulated the work at
> the Internet Identity Workshop 35, which included participants from
> Australia (in addition to the previous regions). We expect to continue
> to engage at venues around the world as well as venues online with a
> diverse set of stakeholders (such as the CCG, ToIP, DIF, and other
> communities).
> 
>> What actions are you taking to make this work item accessible to a non-technical audience?
> 
> We are attempting to provide a gentle introduction to the topic via a
> non-technical introduction in the specification as well as
> non-technical use cases with imagery that is accessible to the general
> population. The people that contributed to the work come from
> academia, government, and private industry -- we are actively seeking
> more diverse inputs via forums such as RWoT, IIW, and the CCG. We plan
> to create presentation slide decks that outline the work in its
> conceptual form so that non-technical audiences may engage with the
> work. We are open to other mechanisms that could be used to improve
> the input into the document.
> 
> We look forward to discussing this potential work item on the mailing
> list as well as on a future call.
> 
> Please support the adoption of the work item in CCG by adding your
> support in a comment here:
> 
> https://github.com/w3c-ccg/community/issues/238
> 
> -- 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 Friday, 16 December 2022 22:53:51 UTC