Re: Current solutions to prove an issuer is who they claim they are

Hi Julien,

The problem of "Who and what to trust?" is what trust frameworks (i.e. a
set of rules, standards, and agreements that define how different entities
within an ecosystem establish trust with each other) are trying to solve.
There are a lot of trust frameworks out there that are built for
different use cases, and we happen to have Drummond Reed to talk about Ayra
(formerly known as Global Acceptance Network) at W3C CCG on Tuesday,
February 4, 2025.  I am sure that Drummond will have a lot of insights to
share in regards to your questions, so please join us then.

How do you get registered (aka accepted)?
> As a small new actor in a field, or an individual, isn’t the process a
> barrier of entry?
> How do you trust the goodwill and intentions of who signs off an entry
> into the registry?
> Who manages the registry?
> And if all of that is centralized, isn’t this just a glorified CA?
> If it’s decentralized, what’s the incentive to run a node/governance
> (cryptocurrency?)?


On a side note, I think "trust" is best defined as "reliance on each other
to achieve a mutually beneficial outcome" (based on Game Theory).  Because
different use cases and markets have slightly different success scenarios,
I think one needs different trust frameworks to solve different needs --
hence a variety of trust frameworks out there.

Sincerely,

*Harrison Tang*
CEO
 LinkedIn  <https://www.linkedin.com/company/spokeo/> •   Instagram
<https://www.instagram.com/spokeo/> •   Youtube <https://bit.ly/2oh8YPv>


On Thu, Jan 23, 2025 at 1:48 PM Alex Tweeddale <alex@cheqd.io> wrote:

> Hi Julien,
>
> There is a list of different trust registry approaches found here (credit
> to Andor)
>
> [image: awesome-trust-registries.png]
>
> andorsk/awesome-trust-registries: curated list of trust regisry systems,
> vendors, and ecoystems
> <https://github.com/andorsk/awesome-trust-registries>
> github.com <https://github.com/andorsk/awesome-trust-registries>
> <https://github.com/andorsk/awesome-trust-registries>
>
>
> We also offer a full comprehensive trust registry solution at cheqd, using
> DIDs and DLT for storing different organisational identifiers and
> verifiable credentials between DIDs for permissions/accreditations.
> https://docs.cheqd.io/product/studio/trust-registries/verifiable-accreditation-trust-chain-model
>
> Happy to have a chat as I’ve spent a lot of time on this topic.
>
> All the best,
>
> Alex
>
>
>
> On 24 Jan 2025, at 08:34, Daniel Hardman <daniel.hardman@gmail.com> wrote:
>
> 
> I agree that this is an interesting issue.
>
> I have always felt that the symmetry of using VCs to establish the bona
> fides of an issuer is attractive. Why should issuers and holders achieve
> trust differently? I understand that this creates a recursive "turtles all
> the way down" problem (who issued the issuer's credential?), but I prefer
> repeating the same mechanism at every layer until I get to some root of
> trust that doesn't need a credential (e.g., it's a national government that
> establishes its identity by fiat and announcement).
>
> Registries sort of offer an alternative, and I am not totally down on
> them. They are a pragmatic aid to adoption. But really, registries don't
> eliminate the recursive problem, because how do I know I'm talking to the
> real registry rather than a fake version of it? Somewhere, you have to pick
> a root identity that you trust for a different reason, whether it's a
> registry or the government example I posited. Between there and the
> proximate credential you're verifying, I like an approach that tolerates an
> arbitrary number of recursions using the same mechanism (credentials),
> rather than requiring a single step to a registry -- if it's pragmatically
> possible.
>
> Part of the reason why I prefer this approach (cite a credential that
> justifies trust in the proximate one, and repeat as needed until you get to
> a root of trust) is that it's a technique that also lends itself naturally
> to non-credential verifiable data use cases. Suppose I'm a journalist and I
> write an exposé about strip mining in a jungle. I cite my sources. But as a
> really good journalist, I have actually investigated whether my proximate
> sources are themselves credible, and I know that the bona fides of my
> direct sources (human, scientific sensors, satellite imaging, published
> academic papers) are backed up all the way back to solid roots of
> trust.There wouldn't be a trust registry for evidence from arbitrary
> parties cited in strip mining research, so the only way to trust the
> sources is to follow the trail back to a root. Or as a lawyer, I'm building
> a legal case, or as an auditor I'm assembling a carefully crafted report,
> etc, etc. These kinds of data are not credentials because what I'm citing
> isn't all about proving entitlement to privileges. And building a registry
> of all reliable sources is (so that the way to vet everything is just to
> check its existence in a registry) is impractical. Yet I still want
> essentially the same thing that is being asked for WRT credentials: a way
> to know if the creator of verifiable data can offer me any reason to accept
> what they assert as trustworthy.
>
> Chained credentials can be done with VCs, by including external references
> in a VC's schema. I wrote about the technique here:
> https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0104-chained-credentials
> <https://www.google.com/url?q=https://github.com/hyperledger/aries-rfcs/tree/main/concepts/0104-chained-credentials&source=gmail-imap&ust=1738272876000000&usg=AOvVaw2E9qt2Z0d5uJOVVkYXWYh_>
>
> ACDCs (KERI's mechanism for verifiable data graphs that includes
> credential use cases; see
> https://trustoverip.github.io/tswg-acdc-specification/
> <https://www.google.com/url?q=https://trustoverip.github.io/tswg-acdc-specification/&source=gmail-imap&ust=1738272876000000&usg=AOvVaw1KsRV7gV9d4L1L9m_IlG9W>)
> does the same thing, but more elegantly and with numerous improvements.
>
> I believe Christopher Allen's Gordian Envelope offers some primitives that
> might allow similar stuff, too.
>
> On Thu, Jan 23, 2025 at 11:07 AM Kerri Lemoie <klemoie@mit.edu> wrote:
>
>> Hi all,
>>
>>
>>
>> DCC (https://digitalcredentials.mit.edu/
>> <https://www.google.com/url?q=https://digitalcredentials.mit.edu/&source=gmail-imap&ust=1738272876000000&usg=AOvVaw1OJtG3ha7e0xZZvXq4arq1>
>> ) and Credential Engine (https://credentialengine.org/
>> <https://www.google.com/url?q=https://credentialengine.org/&source=gmail-imap&ust=1738272876000000&usg=AOvVaw2a6MdfFjhtsMjf6r3lPRzs>
>> ) have been doing a research project since early summer about registries
>> and their governance. The DCC will publish a registry for our members and
>> include it in our wallet (lcw.app
>> <https://www.google.com/url?q=http://lcw.app&source=gmail-imap&ust=1738272876000000&usg=AOvVaw3Yr4jkJyG8dMil03lRW-fu>)
>> and web verifier (https://verifierplus.org/
>> <https://www.google.com/url?q=https://verifierplus.org/&source=gmail-imap&ust=1738272876000000&usg=AOvVaw14cvR3MShzF_xenDA-ZKwY>)
>> that will stand as an open-source reference implementation. Credential
>> Engine is also exploring publishing a registry too. You can learn some
>> about our choices here:
>> https://blog.dcconsortium.org/selecting-the-openid-federation-specification-for-the-dcc-and-credential-engine-issuer-registry-f9079f620472
>> <https://www.google.com/url?q=https://blog.dcconsortium.org/selecting-the-openid-federation-specification-for-the-dcc-and-credential-engine-issuer-registry-f9079f620472&source=gmail-imap&ust=1738272876000000&usg=AOvVaw3b4m5hH_BlMxTM0CT04sUY>
>>
>> We will be having an advisory group meeting on Feb 5 where we plan to
>> provide a demo of the direction we’ve chosen. You can join the advisory
>> group here:
>> https://docs.google.com/forms/d/e/1FAIpQLSczZ44izmA_H4Bg7NkOoUUn6s0mXVVo-yRALNNTYEKcyDcZNg/viewform
>> <https://www.google.com/url?q=https://docs.google.com/forms/d/e/1FAIpQLSczZ44izmA_H4Bg7NkOoUUn6s0mXVVo-yRALNNTYEKcyDcZNg/viewform&source=gmail-imap&ust=1738272876000000&usg=AOvVaw1CZI9oh1xqmqgh-EOXeHMY>
>>
>> What we’ll be recommending is documented governance policies for each
>> registry that answers questions like the ones that Julien raised to inform
>> verifiers.  We’re also keeping an eye on and communicating with
>> https://ayra.forum/
>> <https://www.google.com/url?q=https://ayra.forum/&source=gmail-imap&ust=1738272876000000&usg=AOvVaw0GbbRlw2KRk_K3qrUf30Mc>
>> .
>>
>> We’ll likely bring this demo to CCG and VC-EDU at some point too.
>>
>>
>>
>> Best,
>>
>>
>>
>> K.
>>
>>
>>
>>
>>
>> ---
>>
>> Kerri Lemoie, PhD
>> Director – MIT, Digital Credentials Consortium
>> https://digitalcredentials.mit.edu
>> <https://www.google.com/url?q=https://digitalcredentials.mit.edu&source=gmail-imap&ust=1738272876000000&usg=AOvVaw21YwLGSQ37nSWY41g_Gu_a>
>> she/her
>>
>>
>>
>> Join the DCC mailing list
>> <https://www.google.com/url?q=https://mit.us6.list-manage.com/subscribe?u%3Dad81d725159c1f322a0c54837%26id%3D3621913fe4&source=gmail-imap&ust=1738272876000000&usg=AOvVaw3KqG527bj0nggh-WH4UaUD>
>> and follow us on LinkedIn
>> <https://www.google.com/url?q=https://www.linkedin.com/company/dccconsortium&source=gmail-imap&ust=1738272876000000&usg=AOvVaw0gAo-zbWHPfGIXmZNK70Z9>
>> for news & updates.
>>
>>
>>
>>
>>
>>
>>
>> *From: *Wayne Chang <wayne@spruceid.com>
>> *Date: *Thursday, January 23, 2025 at 12:26 PM
>> *To: *Julien Fraichot <Julien.Fraichot@hyland.com>
>> *Cc: *W3C Credentials CG (Public List) <public-credentials@w3.org>
>> *Subject: *Re: Current solutions to prove an issuer is who they claim
>> they are
>>
>> imo dns, blockchain, some kind of transparency log, sneakernet, website,
>> etc. are all valid approaches. the use case and required trust model are
>> the most important inputs to decide which combination is most suitable
>>
>>
>>
>> also what’s the going market rate for a brad pitt DID?
>>
>>
>>
>>
>>
>> On Thu, Jan 23, 2025 at 08:55 Julien Fraichot <Julien.Fraichot@hyland.com>
>> wrote:
>>
>> Hi CCG Community,
>>
>>
>>
>> I’m currently in the process of gathering information and practices
>> regarding improving trust in Controller Documents.
>>
>>
>>
>> I guess the main issue I’m trying to tackle is how to rule out a
>> malicious actor actively impersonating an official issuer. Think for
>> instance of someone who is able to set up a thorough infrastructure with
>> DIDs or Controller Documents and whatever mechanism in place to sanction
>> the validity of the public keys used (CEL, did:webvh, KERI, etc) but using
>> a clone domain similar as to what would be done in a  phishing attack (ie:
>> instead of https://www.dmv.ca.gov/portal/
>> <https://www.google.com/url?q=https://www.dmv.ca.gov/portal/&source=gmail-imap&ust=1738272876000000&usg=AOvVaw0CrL7n61ey3cEYJLLmUt2S>,
>> you would have someone use https://www.dmv-california.org
>> <https://www.google.com/url?q=https://www.dmv-california.org&source=gmail-imap&ust=1738272876000000&usg=AOvVaw0OdD1i81QAXeCIgtMbX8yw>
>> or similar to host any web based information and “spoof” an identity).
>>
>>
>>
>> I’m guessing I am not the only one working on such a matter so I’d like
>> to hear about things that I might have missed thus far. I have looked at
>> the solutions listed above, but to me they don’t suffice to address the use
>> case I’m exposing. And I think, generally speaking, DIDs can have a similar
>> weakness: you probably read about that French woman who got scammed by her
>> fake Brad Pitt boyfriend, the attacker could have presented a fake Brad
>> Pitt DID that wouldn’t have likely triggered any alarm.
>>
>>
>>
>> I know trust registries can be used but several issues can arise:
>>
>>    - How do you get registered (aka accepted)?
>>    - As a small new actor in a field, or an individual, isn’t the
>>    process a barrier of entry?
>>    - How do you trust the goodwill and intentions of who signs off an
>>    entry into the registry?
>>    - Who manages the registry?
>>    - And if all of that is centralized, isn’t this just a glorified CA?
>>    - If it’s decentralized, what’s the incentive to run a
>>    node/governance (cryptocurrency?)?
>>
>>
>>
>> Witnesses are also an option, but again, how do you trust the network of
>> witnesses. Scammers could very well set up their own network of witnesses
>> and point to each other.
>>
>>
>>
>> Is there some work going on at this level, protecting the end human user
>> against their own naivety?
>>
>>
>>
>> Thanks for your input
>>
>>
>>
>> --
>>
>>
>>
>> Julien Fraichot
>>
>> Developer – Hyland Credentials
>>
>>
>>
>> ----------------------------------------- Please consider the environment
>> before printing this e-mail -----------------------------------------
>>
>> CONFIDENTIALITY NOTICE: This message and any attached documents may
>> contain confidential information from Hyland Software, Inc. The information
>> is intended only for the use of the individual or entity named above. If
>> the reader of this message is not the intended recipient, or an employee or
>> agent responsible for the delivery of this message to the intended
>> recipient, the reader is hereby notified that any dissemination,
>> distribution or copying of this message or of any attached documents, or
>> the taking of any action or omission to take any action in reliance on the
>> contents of this message or of any attached documents, is strictly
>> prohibited. If you have received this communication in error, please notify
>> the sender immediately by e-mail or telephone, at +1 (440) 788-5000, and
>> delete the original message immediately. Thank you.
>>
>>