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

I’m behind on this thread, but:


  1.  Julien and Harrison, indeed the whole CCG talk I’m going to give on Feb 4 will be about the Ayra Association<https://ayra.forum/> and the Ayra Trust Network. The whole reason Ayra exists is to help answer the kind of authority verification questions you are asking by using a global public utility (somewhat analogous to DNS) for querying trust registries. If you want an overview of the architecture, I recommend the Ayra white paper called The Ecosystem of Ecosystems Model for Decentralized Digital Trust Infrastructure<https://ayra.forum/ayra-ecosystem-of-ecosystems-whitepaper/>.
  2.  Steve, the Ayra team has been talking to all kinds of folks using (or planning to use) UNTP, so we’d love to connect soon and see if we can help.

Best,

=Drummond

From: steve capell <steve.capell@gmail.com>
Date: Thursday, January 23, 2025 at 2:13 PM
To: Harrison <harrison@spokeo.com>
Cc: Alex Tweeddale <alex@cheqd.io>, Daniel Hardman <daniel.hardman@gmail.com>, Kerri Lemoie <klemoie@mit.edu>, Wayne Chang <wayne@spruceid.com>, Julien Fraichot <Julien.Fraichot@hyland.com>, W3C Credentials CG <public-credentials@w3.org>
Subject: [EXT] Re: Current solutions to prove an issuer is who they claim they are
Sorry I meant to add a question - would anyone on this w3c list like to join the UN project working group?

Steven Capell
Mob: 0410 437854


On 24 Jan 2025, at 9:10 AM, Steve Capell <steve.capell@gmail.com> wrote:
This might be relevant

<un-crm-social-card.png>
Digital Identity Anchor | UN Transparency Protocol<https://uncefact.github.io/spec-untp/docs/specification/DigitalIdentityAnchor/>
uncefact.github.io<https://uncefact.github.io/spec-untp/docs/specification/DigitalIdentityAnchor/>

On top of that, we expect to launch a UN project soon to create a global trust list of authoritative register DIDs (and other metadata) - to answer that question of who trusts the issuer of the identity anchor ?

UN already does this in other contexts such as the ICAO PKD (the trust list of passport issuers)

Steven Capell
Mob: 0410 437854


On 24 Jan 2025, at 8:54 AM, Harrison <harrison@spokeo.com> wrote:

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,

[https://ci3.googleusercontent.com/mail-sig/AIorK4zbpOgJ2VNqSsQ0g_Q1-rSSQqnvaqW5IWx34tbIk3bje1CCz2c0P-9anaFwV2mD7Id2hXK9W_M]
Harrison Tang
CEO
[https://ci3.googleusercontent.com/mail-sig/AIorK4xOihysBkakpnNCV83lh5k-BA2nIdtnxjRf9OB1QpTR5DgL4DVZw9h42WORI1y1u3k-mET9llU] LinkedIn <https://www.linkedin.com/company/spokeo/>  •  [https://ci3.googleusercontent.com/mail-sig/AIorK4zJfa-OdgUgkoPHyeRnI_fsi4ggb2WAeUSgahHaYBdpNeHGDQ6FufGadPTmg4mD48alQ0B9hBY]  Instagram <https://www.instagram.com/spokeo/>  •  [https://ci3.googleusercontent.com/mail-sig/AIorK4zq91O6GESEVuzRSXj2X19kEjGocCNPO5VJ2HDdvdCmYWNSyIM0wVlTjsM8qsxJ4uZdPDxJ-9Y]  Youtube<https://bit.ly/2oh8YPv>


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

There is a list of different trust registry approaches found here (credit to Andor)

<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>


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<mailto: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<mailto: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<mailto:wayne@spruceid.com>>
Date: Thursday, January 23, 2025 at 12:26 PM
To: Julien Fraichot <Julien.Fraichot@hyland.com<mailto:Julien.Fraichot@hyland.com>>
Cc: W3C Credentials CG (Public List) <public-credentials@w3.org<mailto: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<mailto: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.