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

I completely agree with Drummond’s summary. That said, we need to respect
that government are the sovereigns here and figure out how to get their
digital infrastructure to blend or interoperate with our trust fabric
ideals. I’m not seeing that yet, but I bet there are plenty of people
working on this.

My point is that Arya and other participants could be doing more to chart
our paths to government trust such as digital notaries for example.

Adrian

On Fri, Jan 24, 2025 at 6:48 PM Drummond Reed <Drummond.Reed@gendigital.com>
wrote:

> Julien, just to be clear, while X.509-based public key infrastructure
> relies on “higher governmental authorities, by design or by obligation” —
> or at least certificate authorities (CAs) —decentralized identity
> infrastructure (starting with decentralized identifiers aka DIDs) is
> designed to enable many more trust roots of many kinds. In the Ayra Trust
> Network, every party identified by a DID and recognized by any
> Ayra-recognized trust registry can serve as a trust root—businesses, NGOs,
> communities, and individuals.
>
>
>
> In this approach to a “global trust fabric”, trust in a party will no
> longer need to be established by a single relationship with one other party
> (e.g., by one X.509 cert), but can be based on a whole set of verifiable
> trust relationships (as trust typically is in the physical world). Over
> time, that should make for a much more nuanced and resilient trust
> infrastructure.
>
>
>
> It’s all about democratizing trust in much the way that personal computers
> (and then smartphones) democratized computing and the Internet democratized
> networking.
>
>
>
> And it should work for all levels of assurance — that all depends on
> governance (which is where most of the game will be moving as we get the
> tech nailed down and interoperable).
>
>
>
> =Drummond
>
>
>
> *From: *Julien Fraichot <Julien.Fraichot@hyland.com>
> *Date: *Friday, January 24, 2025 at 6:17 AM
> *To: *W3C Credentials CG <public-credentials@w3.org>
> *Subject: *Re: Current solutions to prove an issuer is who they claim
> they are
>
> Thanks all for your inputs and perspectives.
>
>
>
> To sum up it seems there are 2 approaches to the problem:
>
> ·         Trust registries, within which multiple solutions seem to exist
>
> ·         Trust chains, similar to the DID/whois approach
>
> At the end, at least in this thread, they both seem to want to rely on
> higher governmental authorities, by design or by obligation. I guess there
> is a balance to strike depending on the use case, but if we are dealing
> with high value credentials (notary acts, diplomas, accreditation,
> licences, etc) it likely makes sense as this is a replication of what’s
> currently happening.
>
>
>
> If the issuance is for something more trivial, such a level of assurance
> is probably not needed.
>
>
>
>
>
> *From: *Samuel Rinnetmäki <samuel.rinnetmaki@findy.fi>
> *Date: *Friday, 24 January 2025 at 11:38
> *To: *W3C Credentials CG <public-credentials@w3.org>
> *Subject: *[EXTERNAL] [jfraichot@learningmachine.com] Re: Current
> solutions to prove an issuer is who they claim they are
>
> We have pondered about this also in Findynet. Our condensed view: European
> Union’s List of Trusted Lists model places the European Commission to the
> top of all trust, hindering global adoption and putting too much emphasis
> on member states as
>
> We have pondered about this also in Findynet.
>
>
>
> Our condensed view:
>
> ·         European Union’s List of Trusted Lists model places the
> European Commission to the top of all trust, hindering global adoption and
> putting too much emphasis on member states as intermediaries of trust; the
> trust is considered quite binary; the current implementation might have
> issues with scaling
>
> ·         EBSI platform is not generally available for anyone to simply
> adopt and use
>
> ·         ToIP’s Trust Registry Query Protocol is feature-wise a good
> proposal for our requirements, but quite young and still looking for
> adoption and momentum
>
> ·         OpenID Federation is a spec that’s available today (even though
> it is still in a draft); it's a protocol anyone can implement, no need to
> rely on any organization, technology, or platform (Ayra, EBSI, EU
> Commission, Findynet, GLEIF, Sovrin, …)
>
> ·         using verifiable credentials is kind of attractive (for the
> reasons Daniel Hardman presented), but there is no clear, widespread spec
> on how all issuers and the authorities supervising/accrediting
> those issuers should make the credentials available and how to query them
>
> ·         using traditional PKI (X.509 certificate chains with
> certificate authorities and revocation lists) is a well-established
> pattern, but issuing and managing certificates may not be something that
> all trust anchors and authorities in trust ecosystems are willing to do;
> the specifications for using certificates in digital credential ecosystems
> (ISO mDL, OpenID HAIP) seem to be written for a quite limited context, and
> yet another spec would need to be authored for wider use
>
> ·         W3C Verified Issuer/Verifier data model and DNS-based
> approaches are partial solutions and haven’t gained much traction
>
>
>
> For those reasons, we commissioned Sphereon to build an open-source
> implementation of OpenID Federation protocol last April. The implementation
> is ready, and other implementations exist.
>
>
>
> OpenID Federation is not specifically a trust registry protocol, but it
> can be used to issue statements that fulfil our requirements for a trust
> registry. In OpenID Federation, there is no need to make a distinction
> between a trust registry and a meta registry.
>
>
>
> Samuel
>
>
>
> *From: *Drummond Reed <Drummond.Reed@gendigital.com>
> *Date: *Friday, 24. January 2025 at 9.34
> *To: *steve capell <steve.capell@gmail.com>, Patrick St-Louis <
> patrick.st-louis@opsecid.ca>
> *Cc: *Alex Tweeddale <alex@cheqd.io>, Harrison <harrison@spokeo.com>,
> 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: *Re: Current solutions to prove an issuer is who they claim
> they are
>
> Steve, the ToIP Trust Registry Task Force has had that exact discussion
> and arrived at what we think is a good term (which happens to mirror what
> happened in the directory world):
>
>
>
> ·         *Trust registry*: answers authority queries about specific
> governed parties in a digital trust ecosystem (e.g., issuers, verifiers,
> auditors, certification bodies, etc.)
>
> ·         *Metaregistery*: trust registry that answers authority
> statements about other trust registries.
>
>
>
> We needed to be clear about this distinction because we want the Trust
> Registry Query Protocol (TRQP) to cover queries for both.
>
>
>
> =Drummond
>
>
>
> *From: *steve capell <steve.capell@gmail.com>
> *Date: *Thursday, January 23, 2025 at 3:31 PM
> *To: *Patrick St-Louis <patrick.st-louis@opsecid.ca>
> *Cc: *Alex Tweeddale <alex@cheqd.io>, Harrison <harrison@spokeo.com>,
> 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: *Re: Current solutions to prove an issuer is who they claim
> they are
>
> Hi Patrick,
>
>
>
> Yes that’s a good way to link a DID controller to an identity issued by an
> authoritative register.
>
>
>
> We probably need to find language that disambiguates
>
> “Trust registry” when referring to a specific authoritative register -
> such as BC Gov OrgBook
>
> “Trust registry” when referring to a list of trusted authoritative
> registers - such as the UN project.
>
>
>
> Suggestions?
>
>
>
> steve capell
>
> steve.capell@gmail.com
>
>
>
>
>
>
>
> On 24 Jan 2025, at 10:21 am, Patrick St-Louis <patrick.st-louis@opsecid.ca>
> wrote:
>
>
>
> Greetings,
>
>
>
> In the WebVH specification we make use the the linked-vp feature as a
> 'whois' mechanism for DIDs
> https://identity.foundation/didwebvh/#whois-linkedvp-service
> [identity.foundation]
> <https://urldefense.com/v3/__https:/identity.foundation/didwebvh/*whois-linkedvp-service__;Iw!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfmFdYoSh$>
>
> This 'whois' vp can hold any credentials issued to/about the did
> controller, such as a Digital Identity Anchor @Steve Capell
> <steve.capell@gosource.com.au> mentioned.
>
>
>
> This allows an issuer to disclose verifiable claims about themselves, made
> by other authorities.
>
>
>
> This is an alternative to trust registries that can be used in parallel,
> allowing the issuer to disclose relevant information about themselves.
>
>
>
> Regards,
>
> Patrick
>
>
>
> On Thu, Jan 23, 2025 at 5:47 PM Alex Tweeddale <alex@cheqd.io> wrote:
>
> Hi Steve,
>
>
>
> I would be very interested in participating in this working group,
> especially around the discussion of an authoritative entity register using
> DIDs.
>
>
>
> I’ll reach out directly,
>
>
>
> Alex
>
>
>
>
> On 24 Jan 2025, at 09:12, Steve Capell <steve.capell@gmail.com> wrote:
>
> 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 [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Auncefact.github.io*spec-untp*docs*specification*DigitalIdentityAnchor*&source=gmail-imap&ust=1738275141000000&usg=AOvVaw3BXtcMalB4K7ZQIff5ileS__;Ly8vLy8vLw!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfgWTPIH9$>
>
> uncefact.github.io [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Auncefact.github.io*spec-untp*docs*specification*DigitalIdentityAnchor*&source=gmail-imap&ust=1738275141000000&usg=AOvVaw3BXtcMalB4K7ZQIff5ileS__;Ly8vLy8vLw!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfgWTPIH9$>
>
>
>
> 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,
>
>
>
> [image: Image removed by sender.]
>
> *Harrison Tang*
> CEO
>
> [image: Image removed by sender.] LinkedIn  [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.linkedin.com*company*spokeo*&source=gmail-imap&ust=1738275141000000&usg=AOvVaw1t5nMoWcvFcRfbdDwVAdbF__;Ly8vLy8!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfgZqXNrp$>
>  •  [image: Image removed by sender.] Instagram  [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.instagram.com*spokeo*&source=gmail-imap&ust=1738275141000000&usg=AOvVaw33LU7M46zYwt4oJi4APWq9__;Ly8vLw!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfrETJjeH$>
>  •  [image: Image removed by sender.] Youtube [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Abit.ly*2oh8YPv&source=gmail-imap&ust=1738275141000000&usg=AOvVaw219X-28luId2bbxNHe6AKY__;Ly8v!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfq2DoDXj$>
>
>
>
>
>
> 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)
>
>
>
> <awesome-trust-registries.png>
>
> andorsk/awesome-trust-registries: curated list of trust regisry systems,
> vendors, and ecoystems [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Agithub.com*andorsk*awesome-trust-registries&source=gmail-imap&ust=1738275141000000&usg=AOvVaw1KfrDsTfA32lzBzWSv8teU__;Ly8vLw!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfriUpYGX$>
>
> github.com [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Agithub.com*andorsk*awesome-trust-registries&source=gmail-imap&ust=1738275141000000&usg=AOvVaw1KfrDsTfA32lzBzWSv8teU__;Ly8vLw!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfriUpYGX$>
>
>
>
>
>
> 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
> [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Adocs.cheqd.io*product*studio*trust-registries*verifiable-accreditation-trust-chain-model&source=gmail-imap&ust=1738275141000000&usg=AOvVaw3BcEeF4G-KbM6dan6Y8zNB__;Ly8vLy8v!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfv4_sb12$>
>
>
>
> 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
> [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Agithub.com*hyperledger*aries-rfcs*tree*main*concepts*0104-chained-credentials*26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw2E9qt2Z0d5uJOVVkYXWYh_&source=gmail-imap&ust=1738275141000000&usg=AOvVaw08TkPEOMYJlsfTbtvRIlP2__;Ly8vPyUvLy8vLy8vLyUlJSUlJQ!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfpHjVXRI$>
>
> ACDCs (KERI's mechanism for verifiable data graphs that includes
> credential use cases; see https://trustoverip.github.io/tswg-acdc-specification/
> [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Atrustoverip.github.io*tswg-acdc-specification**A26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw1KsRV7gV9d4L1L9m_IlG9W&source=gmail-imap&ust=1738275141000000&usg=AOvVaw0T44FkNwRfTtp4_HRpvsdx__;Ly8vPyUvLy8vJSUlJSUl!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDflsOqRNg$>)
> 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/ [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Adigitalcredentials.mit.edu**A26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw1OJtG3ha7e0xZZvXq4arq1&source=gmail-imap&ust=1738275141000000&usg=AOvVaw076JlqY_BWJ2FW59wMTHQj__;Ly8vPyUvLy8lJSUlJSU!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfkFBHS2F$>
> ) and Credential Engine (https://credentialengine.org/ [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Acredentialengine.org**A26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw2a6MdfFjhtsMjf6r3lPRzs&source=gmail-imap&ust=1738275141000000&usg=AOvVaw1yGCvu0jsJJ4AFBqXv0L46__;Ly8vPyUvLy8lJSUlJSU!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfhMJ1_wP$>
> ) 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 [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttp:**Alcw.app*26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw3Yr4jkJyG8dMil03lRW-fu&source=gmail-imap&ust=1738275141000000&usg=AOvVaw1Wv6tiRSgdOp8vtUSvr9tr__;Ly8vPyUvLyUlJSUlJQ!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDflSM-gXZ$>)
> and web verifier (https://verifierplus.org/ [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Averifierplus.org**A26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw14cvR3MShzF_xenDA-ZKwY&source=gmail-imap&ust=1738275141000000&usg=AOvVaw2yu56z0ZEw6lkQWw7lgbsf__;Ly8vPyUvLy8lJSUlJSU!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDflASnXJF$>)
> 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
> [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Ablog.dcconsortium.org*selecting-the-openid-federation-specification-for-the-dcc-and-credential-engine-issuer-registry-f9079f620472*26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw3b4m5hH_BlMxTM0CT04sUY&source=gmail-imap&ust=1738275141000000&usg=AOvVaw1WMr675fR0Rb0kehXdavGJ__;Ly8vPyUvLy8lJSUlJSU!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfpV7Pjnx$>
>
> 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
> [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Adocs.google.com*forms*d*e*1FAIpQLSczZ44izmA_H4Bg7NkOoUUn6s0mXVVo-yRALNNTYEKcyDcZNg*viewform*26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw1CZI9oh1xqmqgh-EOXeHMY&source=gmail-imap&ust=1738275141000000&usg=AOvVaw3U-sVAldVtTpGlHQkMbUmi__;Ly8vPyUvLy8vLy8vJSUlJSUl!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfgqwRsqE$>
>
> 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/
> [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Aayra.forum**A26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw0GbbRlw2KRk_K3qrUf30Mc&source=gmail-imap&ust=1738275141000000&usg=AOvVaw1dKKN3e7vQGpOgYEUclqhK__;Ly8vPyUvLy8lJSUlJSU!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfj2WllfN$>
> .
>
> 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 [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Adigitalcredentials.mit.edu*26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw21YwLGSQ37nSWY41g_Gu_a&source=gmail-imap&ust=1738275141000000&usg=AOvVaw37z-xb4_7H62MaHFhjr_sa__;Ly8vPyUvLyUlJSUlJQ!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfljPLXg2$>
> she/her
>
>
>
> Join the DCC mailing list [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Amit.us6.list-manage.com*subscribe*u*253Dad81d725159c1f322a0c54837*2526id*253D3621913fe4*26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw3KqG527bj0nggh-WH4UaUD&source=gmail-imap&ust=1738275141000000&usg=AOvVaw33Gp6lwvqY63YQlC-L6Uz4__;Ly8vPyUvLy8_JSUlJSUlJSUl!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDftirQCv0$>
> and follow us on LinkedIn [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Awww.linkedin.com*company*dccconsortium*26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw0gAo-zbWHPfGIXmZNK70Z9&source=gmail-imap&ust=1738275141000000&usg=AOvVaw2hnAnp3P4a6qGyADajiN6b__;Ly8vPyUvLy8vJSUlJSUl!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfhRCsXHB$>
> 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/ [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Awww.dmv.ca.gov*portal**A26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw0CrL7n61ey3cEYJLLmUt2S&source=gmail-imap&ust=1738275141000000&usg=AOvVaw2qrEDBjyEZhf-jZ6ATuN1M__;Ly8vPyUvLy8vJSUlJSUl!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfpQM__dV$>,
> you would have someone use https://www.dmv-california.org [google.com]
> <https://urldefense.com/v3/__https:/www.google.com/url?q=https:**Awww.google.com*url*q*3Dhttps:**Awww.dmv-california.org*26source*3Dgmail-imap*26ust*3D1738272876000000*26usg*3DAOvVaw0OdD1i81QAXeCIgtMbX8yw&source=gmail-imap&ust=1738275141000000&usg=AOvVaw22eu0Z9dr_Mihddskq_jnF__;Ly8vPyUvLyUlJSUlJQ!!C8mu0vCj!Z4KJt7MTIkqQTpdrEsl2a7AsP4KcR3zUlg6tSX4lMFm1MXmUVuGjetQwq0NxIneN9BGVl438u9QOx3Z-9uKQimLab1zDfg1reltP$>
> 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.
>
>
>
> ----------------------------------------- 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.
>