Re: [Agenda] W3C CCG 3/7/23 - Lists of Verifiable Issuers and Verifiers

Steve wrote:

> the intrinsic value of a TTP is that they build contextual trust in
> themselves as an institution (via governance, reputation, audits, etc.) on
> one side and then expose themselves to reputational risk on the other side
> by certifying that only the select entities they have vetted belong on the
> list.


If this is correct, then the system is intended to do more than just
"enable a party to share a list of *Verifiable* Issuers and Verifiers,"
which was the only purpose mentioned in the presentation. You seem to be
suggesting that, in addition to providing the list, the TTP would be held
responsible for having made some claim about the credibility or correctness
of the information contained within each list entry. If that is the case,
then it would be useful to call this out explicitly. Perhaps we should talk
of "*Verified* Issuers and Verifiers," rather than "Verifiable" entities.
Certainly, if entry vetting requires non-trivial resources, lists are
unlikely to include millions of entries, but they might still be "large."

Also, a question: Would either, or both, of the entries and lists have
"Time To Live (TTL)" values that indicated for how long these things should
be trusted?

bob wyman

On Tue, Mar 7, 2023 at 6:23 PM <steve.e.magennis@gmail.com> wrote:

> My $0.02
>
>
>
> IMO, the intrinsic value of a TTP is that they build contextual trust in
> themselves as an institution (via governance, reputation, audits, etc.) on
> one side and then expose themselves to reputational risk on the other side
> by certifying that only the select entities they have vetted belong on the
> list. If the TTP list were ‘self-serve,’ were not keep current or had
> superficial criteria for membership, then the value a TTP could provide
> would not be a whole lot better than random chance when it comes to trying
> to make a trust decision without first knowing the other party.
>
>
>
> I think there must be some demonstrable relationship between the number of
> entities on a trusted list and the difficulty of maintaining the quality of
> the list to the point where a 100m item list inherently can’t provide much
> in the way of trust insurance because it would take an army of people (yes,
> fewer if a lot of automation could be applied effectively) to vet
> everything and ensure reasonable currency. Three items on a trust list
> would be pretty easy for one person to perform white glove checks on each
> of the parties and make updates to the list in a timely fashion. So
> somewhere between 3 and 100m there is a point of diminishing value for
> lists. A good stats person could probably model this (with error bars!) and
> tell us what the cutover point looks like.
>
>
>
> I think Bob’s use case where anyone can certify the trustworthiness of
> anyone else is interesting. This feels more like a social reputation system
> where it is more about how many people (who will likely *never* be known
> by the verifier) an individual can get to certify the trustworthiness of
> themselves. The idea that if someone is able to get enough people to say
> they are (contextually) trustworthy, then they likely are.  I don’t think a
> TTP has a good role to play in this model, or is even that important.
>
>
>
> -S
>
>
>
>
>
> *From:* David Chadwick <d.w.chadwick@truetrust.co.uk>
> *Sent:* Tuesday, March 7, 2023 11:36 AM
> *To:* public-credentials@w3.org
> *Subject:* Re: [Agenda] W3C CCG 3/7/23 - Lists of Verifiable Issuers and
> Verifiers
>
>
>
> Hi Bob
>
> I actually do not think your use case is one that is suitable for a list
> of trusted issuers (or verifiers) as described by Isaac.
>
> First, who would issue this list? Each list has to have a TTP that issues
> it. I do not know who it would be for your use case.
>
> Secondly if this list contains the id of every social web user it is
> pretty well next to useless from a trust perspective since a large
> proportion of the world's population will be on it - and what can they all
> be trusted for?
>
> If you consider the web PKI, which is truly global in scale, then there
> are probably only about 500 root CAs in the world, which would equate to
> 500 trusted lists, and these are sufficient to hold the identities of every
> public TLS web site in the world. So web PKI has demonstrated that trusted
> lists are scalable to global proportions.
>
> In the model described by Isaac, I do not expect issuers to be transient
> entities, but rather longer lived entities, such as universities,
> hospitals, governments, commercial companies etc. Thus the lifetime of a
> list should be long enough for most practical purposes.
>
> Kind regards
>
> David
>
> On 08/03/2023 07:30, Bob Wyman wrote:
>
> Isaac,
>
> Thanks for your interesting proposal and presentation.
>
>
>
> As stated during the meeting, I am concerned that list size may be an
> issue and I'm wondering if you could provide your thoughts on the
> implications of list size on the useful scope of your approach. It seems to
> me that use of a list having 10 members would present a very different set
> of issues than one that had 10's of millions of members.
>
>
>
> If I understand things correctly, it seems to me that a very large list
> might be needed to support a population of self-sovereign social web users
> who may each independently issue VC's attesting to the "credibility" of
> other social web users. (e.g. Bob issues a VC saying he considers Alice to
> be credible when she speaks about issues related to current nuclear fusion
> research.) I assume that each of the users will have their own domain and
> that they generally wish to minimize reliance on centralized facilities.
>
>
>
> If a list becomes very large, its rate of change might ensure that no
> snapshot of the list could be valid for more than a very short period of
> time. Also, making copies of any snapshot, in order to use it, might be
> burdensome for both its maintainers and its users.
>
>
>
> Note: I do understand Manu's statement in chat that one benefit of a
> list-based approach is that an external party is somewhat thwarted
> in discovering which member of the list is the subject of one's interest.
> This is a useful privacy benefit, but I'm wondering how it can be
> maintained at scale.
>
>
>
> But, perhaps there is some detail that I haven't understood...
>
>
>
> bob wyman
>
>
>
>
>
> On Tue, Mar 7, 2023 at 4:57 AM Johnson Jeyakumar, Isaac Henderson <
> Isaac-Henderson.Johnson-Jeyakumar@iao.fraunhofer.de> wrote:
>
> Hello everyone,
>
>
>
> I have attached the presentation slides for tomorrow’s call along with
> this e-mail.
>
>
>
> Looking forward to great discussions tomorrow.
>
>
>
> Thanks.
>
>
>
> Best Regards,
>
> Isaac Henderson
>
>
>
> *From:* Harrison <harrison@spokeo.com>
> *Sent:* Thursday, March 2, 2023 11:10 PM
> *To:* W3C Credentials CG (Public List) <public-credentials@w3.org>
> *Subject:* [Agenda] W3C CCG 3/7/23 - Lists of Verifiable Issuers and
> Verifiers
>
>
>
> *Main Agenda:  Lists of Verifiable Issuers and Verifiers*
>
>
>
> We are glad to invite Isaac Henderson
> <https://www.linkedin.com/in/isaac-henderson-76171a68/>, Manu Sporny
> <https://www.linkedin.com/in/manusporny/>, Line Kofoed
> <https://www.linkedin.com/in/line-kofoed/>, Konstantin Tsabolov
> <https://www.linkedin.com/in/konstantin-tsabolov/>,and Oskar van Deventer
> <https://www.linkedin.com/in/m-oskar-van-deventer-7478121b/> to present
> and lead the discussion on "Lists of Verifiable Issuers and Verifiers" at
> W3C CCG next Tuesday 3/7/23.  This work on Verifiable Issuers and Verifiers
> focuses on how a party or its agent can decide whether or not to engage
> with a counterparty in a transaction, and it answers questions like "Is
> that diploma from a recognized university?", or "Should the wallet block an
> unauthorized Verifier?", or "Can I trust X to do Y?".  You can learn more
> about it here:
> https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/draft-documents/verifiable-issuer-verifier-lists/verifiable-issuer-verifier-lists.pdf.
> Look forward to the presentation and discussion!
>
>
> --
>
> Time: Tuesday 3/7/23 at 9am PT, 12pm noon ET, 5pm GMT, 6pm CET for 55 min.
>
> https://www.timeanddate.com/worldclock/converter.html?iso=20220215T170000&p1=tz_pt&p2=tz_et&p3=tz_cet&p4=tz_gmt&p5=tz_nzdt&p6=tz_nzst
>
> Jitsi Teleconf:
>       https://meet.w3c-ccg.org/weekly
>
> Text Chat:
>       http://irc.w3.org/?channels=ccg
>       irc://irc.w3.org:6665/#ccg
>
> Voice:
>      US phone: tel:+1.602.932.2243;1 <+1.602.932.2243;1>
>
> Agenda:
> 1. Code of Ethics & Professional Conduct Reminder:
> https://www.w3.org/Consortium/cepc/
> 2. IP Note:
>     a. Anyone can participate in these calls. However, all substantive
> contributors to any CCG Work Items must be members of the CCG with full IPR
> agreements signed. https://www.w3.org/community/credentials/join
>     b. Ensure you have a W3 account: https://www.w3.org/accounts/request
>     c. W3C Community Contributor License Agreement (CLA):
> https://www.w3.org/community/about/agreements/cla/
> 3. Call Notes:
>     a. Meeting minutes and audio recordings:
> https://w3c-ccg.github.io/meetings/
>     b. We use Jitsi chat (linked with IRC at
> http://irc.w3.org/?channels=ccg or http://irc.w3.org:6665/#ccg) to queue
> speakers during the call as well as to take minutes.
>     c. In IRC type “q+” to add yourself to the queue, with an optional
> reminder, e.g., “q+ to mention something”. The “to” is required.
> 4. Introductions & Reintroductions
> 5. Announcements & Reminders: https://w3c-ccg.github.io/announcements/
> 6. Work Items:
>
> https://github.com/w3c-ccg/community/issues?q=is%3Aopen+is%3Aissue+label%3A%22action%3A+review+next%22
> 7. Main Agenda
> 8. Discussions
>
> Upcoming Meetings: https://www.w3.org/groups/cg/credentials/calendar
>
> Thanks,
>
>
>
> --
>
> [image: Image removed by sender.]
>
> *Harrison Tang*
> CEO
>
> [image: Image removed by sender.]
> <https://www.linkedin.com/in/theceodad/>LinkedIn
> <https://www.linkedin.com/in/theceodad/>
> <https://www.linkedin.com/in/theceodad/> •  [image: Image removed by
> sender.]  <https://twitter.com/TheCEODad>Twitter
> <https://twitter.com/TheCEODad>  •  [image: Image removed by sender.]
> <https://www.tiktok.com/@tang_toks> Tiktok
> <https://www.tiktok.com/@tang_toks>  •  [image: Image removed by sender.]
> <https://www.facebook.com/TheCEODad> Facebook
> <https://www.facebook.com/TheCEODad/>
>
>
>
>