- From: steve capell <steve.capell@gmail.com>
- Date: Sat, 25 Jan 2025 18:11:20 +1100
- To: Drummond Reed <Drummond.Reed@gendigital.com>
- Cc: Adrian Gropper <agropper@healthurl.com>, Julien Fraichot <Julien.Fraichot@hyland.com>, W3C Credentials CG <public-credentials@w3.org>
- Message-Id: <BECE7EBE-B1AD-4988-B7A2-A830DAA268AB@gmail.com>
Lots of interesting posts on this topic that I’ve enjoyed reading. Here’s my thoughts and I’d welcome supporting or dissenting opinions. I think there are two very different kinds of “trust” that are being discussed each with different purpose and very different solution approach. Existing registers / simple hierarchical trust. The first is the kind that the UNTP digital identity anchor and global trust register seeks to address. This is simply about making digitally verifiable what is already a well established and governed set of processes run by some authority. Here I’m talking about national business registers, trademark registers, land registries, asset registers, and even product registers. These have been around for decades or even centuries. VC powered trust-chains such as proposed by UNTP digital identity anchor are simply making digitally verifiable what is already an existing and governed process. I think the linked-credential trust-chain solution is the only scalable way to do it because of the rate of change in the underlying register. It’s pretty simple for these existing registers to tag on a little digital capability to verify that a particular registered member genuinely controls a DID (did-auth) and then issue a credential that assets “the controller of this DID is also the owner of this trademark, or this asset, or that land parcel, or is an authorised officer of that business. There’s only a few thousand of this kind of register around the world and some kind of managed trust list of registrar DIDs (eg by the UN) is an optional convenience. I don’t see any need for complex technical architectures here. Just tag on the ability to verify DID control and issue credentials to registry members. Complex peer-to-peer networks of trust. But there’s another kind of trust that is entirely different, more difficult to scale, but very valuable if done right. That’s less about authoritative registers and more about a weight of peer-to-peer evidence of ethical participation. There’s no central authorities or simple hierarchy in this one. A malicious party can of course legitimately register a business with a national authority and then conduct illicit trade. Just because they can confirm that they really are a certain registered entity doesn’t mean you can trust their intent. Whereas when a business has 1000 positive assertions from a network of it’s customers and suppliers, many of which themselves have strong evidence of longstanding trustworthy behaviour - then you can probably trust that business to do the right thing. There is a serious need for this kind of trust architecture in sustainable supply chains and we haven’t given it enough focus at UNTP (yet). For example - if you want to be sure that particular actor (eg a sugar cane farm or a cobalt mine) has ethical employment practices, would you trust a certificate from an auditor that visits the site once every three years (on a predictable day when indentured workers are told to stay home)? Or would you trust some kind of verifiable score that is the result of hundreds or thousands of local people who work in the facility (or have friends / family that do) that all say that the employer has fair working practices? I don’t think these two models are mutually exclusive. It is often very important to verify that such-and-such really is a registered member of a given authoritative register. But there are lots of scenarios where you need a trust model that is the result of a kind of organic growth of reputable evidence of ethical behaviour. I think that solutions like the Arya network mentioned by Drummond could be very valuable for this second kind of network of trust but probably aren’t needed for the first kind of simple registration / hierarchy of trust. I think the steve capell steve.capell@gmail.com > On 25 Jan 2025, at 4:41 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 <mailto: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 <mailto:Julien.Fraichot@hyland.com>> > Date: Friday, January 24, 2025 at 6:17 AM > To: W3C Credentials CG <public-credentials@w3.org <mailto: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 <mailto:samuel.rinnetmaki@findy.fi>> > Date: Friday, 24 January 2025 at 11:38 > To: W3C Credentials CG <public-credentials@w3.org <mailto:public-credentials@w3.org>> > Subject: [EXTERNAL] [jfraichot@learningmachine.com <mailto: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 <mailto:Drummond.Reed@gendigital.com>> > Date: Friday, 24. January 2025 at 9.34 > To: steve capell <steve.capell@gmail.com <mailto:steve.capell@gmail.com>>, Patrick St-Louis <patrick.st-louis@opsecid.ca <mailto:patrick.st-louis@opsecid.ca>> > Cc: Alex Tweeddale <alex@cheqd.io <mailto:alex@cheqd.io>>, Harrison <harrison@spokeo.com <mailto:harrison@spokeo.com>>, Daniel Hardman <daniel.hardman@gmail.com <mailto:daniel.hardman@gmail.com>>, Kerri Lemoie <klemoie@mit.edu <mailto:klemoie@mit.edu>>, Wayne Chang <wayne@spruceid.com <mailto:wayne@spruceid.com>>, Julien Fraichot <Julien.Fraichot@hyland.com <mailto:Julien.Fraichot@hyland.com>>, W3C Credentials CG <public-credentials@w3.org <mailto: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 <mailto:steve.capell@gmail.com>> > Date: Thursday, January 23, 2025 at 3:31 PM > To: Patrick St-Louis <patrick.st-louis@opsecid.ca <mailto:patrick.st-louis@opsecid.ca>> > Cc: Alex Tweeddale <alex@cheqd.io <mailto:alex@cheqd.io>>, Harrison <harrison@spokeo.com <mailto:harrison@spokeo.com>>, Daniel Hardman <daniel.hardman@gmail.com <mailto:daniel.hardman@gmail.com>>, Kerri Lemoie <klemoie@mit.edu <mailto:klemoie@mit.edu>>, Wayne Chang <wayne@spruceid.com <mailto:wayne@spruceid.com>>, Julien Fraichot <Julien.Fraichot@hyland.com <mailto:Julien.Fraichot@hyland.com>>, W3C Credentials CG <public-credentials@w3.org <mailto: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 <mailto:steve.capell@gmail.com> > > > > > On 24 Jan 2025, at 10:21 am, Patrick St-Louis <patrick.st-louis@opsecid.ca <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <mailto: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 <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 [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 <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 [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 <mailto: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 <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/ [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.
Received on Saturday, 25 January 2025 07:11:42 UTC