[PROPOSED WORK ITEM] Verifiable Issuers and Verifiers

msporny commented 1 year ago

Abstract

This work focuses on how a party or its agent can decide whether or not to engage with a counterparty in a transaction. 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. This work item is designed to answer questions like: "How can I trust that this Diploma is real?" or "Should I send my digital passport to this entity that is claiming to be law enforcement?"

https://msporny.github.io/verifiable-issuers-verifiers/

List Owners

Work Item Leads: @hendersonweb and @msporny (CODEOWNERS) Work Item Authors: @tsabolov @Oskar-van-Deventer @shigeya @lineko @RieksJ (expect these folks to also be CODEOWNERS)

Work Item Questions

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 for a list of Verifiable Issuers (Universities that are accredited to issue Accounting degrees) or a list of Verifiable Verifiers (National Border Protection Officers) to be published 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 all 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 as well as non-technical use cases with imagery that is accessible to the general population. We plan to create presentation slide decks that outline the work in its conceptual form. We are open to other mechanisms that could be used to make the product

mprorock commented 1 year ago

+1 makes a lot of sense to me, and has broad support (including from us with chair hat off). We will make sure this gets on the agenda for approval at the next CCG meeting unless @msporny or others think there would be a good reason to escalate sooner on list or similar

msporny commented 1 year ago

We will make sure this gets on the agenda for approval at the next CCG meeting unless @msporny or others think there would be a good reason to escalate sooner on list or similar

No need to escalate, this spec can progress at a slower, more natural pace given all the other higher priorities happening in the ecosystem right now (CCG specs transitioning to VCWG, for example).

David-Chadwick commented 1 year ago

I support this work.

PatStLouis commented 1 year ago

+1 I support this work. A few questions I have to kickstart discussions, not meant to have definitive answers:

Would this introduce a centralized source of authority, i.e. a trust registry?
Which body would provide/maintain such a list?
Would "verified" issuers/verifiers carry a verified mechanism or would this verification need to be achieved by the holder against an external system?

To add another layer of details, in Canada there's been a small effort to explore maintaining such a trust registry under CIRA.

Oskar-van-Deventer commented 1 year ago

Would this introduce a centralized source of authority, i.e. a trust registry? No. A Verifier could self-sovereignly decide whether to maintain its own list, use a third-party list, or other. Anybody (individual or organisation) can maintain and publish such a list. Providing the capability/standards to publish lists of Verifiable Issuers and Verifiers does not imply centralisation. There could be many lists: complementary, overlapping, competing, ...
Which body would provide/maintain such a list? “Assurance Community” would be an appropriate term for such a role. This is a group of people or organisations that have procedures and governance in place to maintain and publish such a list.
Would "verified" issuers/verifiers carry a verified mechanism or would this verification need to be achieved by the holder against an external system? The list, or entries from the list could also be made available as verifiable credential.

Oskar

From: Patrick St-Louis @.> Sent: maandag 19 december 2022 15:17 To: w3c-ccg/community @.> Cc: Deventer, M.O. (Oskar) van @.>; Mention @.> Subject: Re: [w3c-ccg/community] [PROPOSED WORK ITEM] Verifiable Issuers and Verifiers (Issue #238)

+1 I support this work. A few questions I have to kickstart discussions, not meant to have definitive answers:

Would this introduce a centralized source of authority, i.e. a trust registry?
Which body would provide/maintain such a list?
Would "verified" issuers/verifiers carry a verified mechanism or would this verification need to be achieved by the holder against an external system?

To add another layer of details, in Canada there's been a small effort to explore maintaining such a trust registry under CIRA.

— Reply to this email directly, view it on GitHubhttps://github.com/w3c-ccg/community/issues/238#issuecomment-1357740464, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AK7ZHVET6L5DPOSB6JQCUV3WOBU5RANCNFSM6AAAAAATBOL4ZM. You are receiving this because you were mentioned.Message ID: @.**@.>> This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

vongohren commented 1 year ago

I support this work as it makes lots of sense to me, and my company Diwala!

mavarley commented 1 year ago

I support this work. Thanks for kicking it off!

mkhraisha commented 1 year ago

Looking forward to this work item!

man4prez commented 1 year ago

+1

TallTed commented 1 year ago

As with much work of the Credentials CG ("the" CCG), I think this is likely to be of interest to members of the Credibility CG ("the other" CCG).

I think raising it to their attention will be better done by one or more of the Leads and/or Authors, who are likely to have better answers than I to followup questions.

msporny commented 1 year ago

I think raising it to their attention will be better done by one or more of the Leads and/or Authors, who are likely to have better answers than I to followup questions.

Yes, agreed. We will do that. Please ping us if we don't do this in the next 3 months (but we will do our best to do it).

mprorock commented 1 year ago

Proposal run on 01/03/23: wide support to adopt as a work item - @msporny would you like to transfer repo or create a new one

paulfdietrich commented 1 year ago

Manu. Super interested here, but I want to share a use case from our GS1 federation (probably heard me say this at IIW). Our global office issues country prefixes to our country organizations. Country organization use these prefixes to issue company prefixes (rooted in their country prefix) to supply chain members to use to issue identifiers like GTINs and GLNs.

This sounds like a good use for your trust lists, where the global office might issue a trust list with the somewhat limited (120 or so) country organizations authorized to issue these company prefixes.

However, this doesn't prevent country 1 from issuing a company prefix from the prefix of country 2. So perhaps that means that this trust list concept would not be useful when there are restrictions around what credentials a "trusted" party is allowed to issue.

One could same the same about one state like California issuing a drivers license from Nevada.

I wonder if this type of feature would be in or out of scope from this group. Don't intend to slow this down, just want to understand the scope.

msporny commented 1 year ago

@msporny would you like to transfer repo or create a new one

I'll transfer the repo, thanks!

msporny commented 1 year ago

@paulfdietrich wrote:

This sounds like a good use for your trust lists, where the global office might issue a trust list with the somewhat limited (120 or so) country organizations authorized to issue these company prefixes... However, this doesn't prevent country 1 from issuing a company prefix from the prefix of country 2. ... I wonder if this type of feature would be in or out of scope from this group.

Yes, definitely in scope and is something we contemplated via a "credential schema" that can constrain an issuer to issuing a credential to a particular subdomain (such as a country, city, region, department, etc.). Note the example in the current specification here:

https://msporny.github.io/verifiable-issuers-verifiers/#verifiable-credential

Specifically, the authorizedToIssue.credentialSchema property... which constrains the credentialSubject.state to UA... the state of Utopia :P

All that to say, very much in scope and we've taken a pass at trying to do something that's fairly "programmable"... but are, of course, concerned about how programmable that mechanism is. What would help us power through that decision are real use cases, such as GS1's, to influence the final solution we end up standardizing. Please help us mould the specification into something that'll work for you and the traceability folks. :)

Oskar-van-Deventer commented 1 year ago

As for scoping, we may want to document features per release, and their requirements. -Release 1: Minimal Viable Verifiable-Issuers-and-Verifiers List. -Release 2: Additional features that make the solution more scalable, automatable/programmable and widely usable.

The RWOT paper, made available here to W3C-CCG as Draft Community Group Report "Verifiable Issuers and Verifiers v0.1" aims at Release 1. a) Identification of Verifiable Issuers and Verifiers. That is, being able to verify whether an Issuer or Verifier is on a list. b) Making the list (or parts of it) available as a Verifiable Credential. That is, being able to verify that the list (or part of it) is authentic/genuine. c) Metadata that scopes a particular Issuer or Verifier on a list, e.g. "authorizedToIssue a UniversityDegreeCredential with the following credentialSchema ...". d) A few more features, see the draft.

Additional features could add value to the solution. -Support of GS1-type organisation metadata, for Issuers and Verifiers that happen to be GS1-identified organisations. -Metadata that scopes a particular list as a whole. -Automated enforcement ("Verifiable-Verifier List says no"), and certification of implementations of such. -Any bootstrapping, roll-over and other CRUD aspects that aren't yet covered by VC-ifyng the list. -Possible recursion: Verifiable Verifiable-Issuers-and-Verifiers-List List. -More features, t.b.d.

What are the features that would be essential for release 1, and which could be left to release 2 or later?

Oskar

msporny commented 1 year ago

What are the features that would be essential for release 1, and which could be left to release 2 or later?

The way this is typically handled is by creating an issue on the repository for the specification and then the Organizers/Editors will triage all the issues to determine priority.

msporny commented 1 year ago

This was adopted a while ago: https://github.com/w3c-ccg/verifiable-issuers-verifiers

Chairs, can we close this issue? /cc @kwlinson @man4prez @mprorock

wip-abramson commented 8 months ago

Closing this as per comment above

w3c-ccg / community