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

On Fri, Jan 24, 2025 at 9:44 AM Drummond Reed <Drummond.Reed@gendigital.com>
wrote:

>
>
> And Ayra infrastructure will be perfect for digital notaries. In fact IMHO
> it would be ideal to set up an Ayra-recognized ecosystem of ecosystems for
> digital notaries. In the ecosystem of ecosystems pattern (described in this
> Ayra white paper
> <https://ayra.forum/ayra-ecosystem-of-ecosystems-whitepaper/>), the
> stakeholders in that ecosystem of ecosystems could set up a metaregistry
> that can point to all of the other trust registries for digital notaries in
> the world. That way anyone could verify that a person or company was an
> authorized/certified digital notary in seconds.
>

One of the things I like about DIDs is that nobody can invalidate my
identifier, as Google can do with my email address or a trust registry can
do with VCs I issue.  I think this ecosystem of ecosystems will allow me to
register at several trust registries as protection against any one of them
deciding it doesn't like me.  I lose that protection as soon as there is a
single root, such as a government or unique metaregistry.

--------------
Alan Karp


On Fri, Jan 24, 2025 at 9:44 AM Drummond Reed <Drummond.Reed@gendigital.com>
wrote:

> Adrian, Ayra is working with governments right now. Our first webinar last
> September was with the Bhutan National Digital Identity (NDI) team. We just
> did another post-Davos webinar a few hours ago that included one of the
> leaders of the Swiss E-ID team.
>
>
>
> And Ayra infrastructure will be perfect for digital notaries. In fact IMHO
> it would be ideal to set up an Ayra-recognized ecosystem of ecosystems for
> digital notaries. In the ecosystem of ecosystems pattern (described in this
> Ayra white paper
> <https://ayra.forum/ayra-ecosystem-of-ecosystems-whitepaper/>), the
> stakeholders in that ecosystem of ecosystems could set up a metaregistry
> that can point to all of the other trust registries for digital notaries in
> the world. That way anyone could verify that a person or company was an
> authorized/certified digital notary in seconds.
>
>
>
> =Drummond
>
>
>
> *From: *Adrian Gropper <agropper@healthurl.com>
> *Date: *Friday, January 24, 2025 at 9:19 AM
> *To: *Drummond Reed <Drummond.Reed@gendigital.com>
> *Cc: *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
>
> 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,
>
>
>
> *Error! Filename not specified.*
>
> *Harrison Tang*
> CEO
>
> *Error! Filename not specified.* 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$>
>  •  *Error! Filename not specified.* 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$>
>  •  *Error! Filename not specified.* 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.
>
>