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

Yes, Daniel’s strip mining journalist and manu’s neighbour Jane smith are good examples of genuine decentralised trust questions where authoritative registries either don’t exist of serve little value.  Very similar to my example of how to trust claims of fair work practices in a cobalt mine or sugar cane farm.

So I think we are on the same page.  

I understand too that this community doesn’t want to see our decentralised architecture collapse back to a PKI model.  And that words like “centralised register” trigger an immune reaction ;). Especially when the words “centralised register” trigger thoughts of the CA land grab that happened with the most common form of PKI - browser CA root certificates. think this community is right to distance itself from that kind of technology-land-grab approach to trust.  
But perhaps we are doing a disservice to ourselves and our constituency when we equate that kind of technology rent seeking behaviour to well established national legal frameworks and the “registers” (in a business sense, not technical) that underpin them.  National (or state level) company registers, land registers, trademark register, and so on have existed for centuries and will continue to exist for centuries ahead because they provide essential economic and legal functions. Unlike a browser CA, they really are a root of trust - so long as the trust question is “I want proof that the issuer of that credential is really that registers company / trademark owner / land owner / etc”. These registers exist to protect the community and their legal rights, not to extract rent from them. 

If we, as a community, embrace those kinds of existing trust anchors and show them how they can add value to their registered members with VCs and DIDs then we will have amplified our message and will see real world uptake of VCs and DIDs accelerate beyond our wildest expectations - whilst still keeping true to our core purpose.  

And just to pre-empt a response along the lines of “you can always create a VP from your business registration VC”, I’ll refer back to my list of use cases earlier in this thread where the verifier has no direct relationship with the issuer or the subject. That pattern is also described here https://www.w3.org/TR/vc-data-model/#holder-acts-on-behalf-of-the-verifier-or-has-no-relationship-with-the-subject-issuer-or-verifier (a section from VCDM 1.1 that disappeared from VCDM 2.0). There are a huge number of real world use cases that fit exactly this pattern and are facilitated by cooperation with genuine national trust-anchor registers. 

Steven Capell
Mob: 0410 437854

> On 27 Jan 2025, at 3:47 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:
> 
> On Sat, Jan 25, 2025 at 11:18 PM Steve Capell <steve.capell@gmail.com> wrote:
>> Let me just offer an answer to “Why can't we just start with a list of DIDs that a verifier software trusts and configure it locally?
>> 
>> In many cases that could be perfectly satisfactory - but there are several important use case where it is not practical or scalable.
> 
> I agree with most everything you said, Steve. To clarify, I'm not
> saying that centralized registries are not useful. I'm saying that not
> focusing on the things that Daniel highlighted could end up putting us
> in the same place we are today (with centralization being the only
> real option). While centralized registries do solve a number of
> important use cases, they don't address many of the use cases that
> this community cares about.
> 
> What I don't want to see is us saying: Welp, X509 and the Certificate
> Authority approach solved these problems years ago, let's just re-use
> that ... because while it might be technically possible to deploy X509
> in a more decentralized way, I've never seen it work out in practice
> at scale. Centralization and high cost of operation define many X509
> deployments, there are all these certification requirements that kick
> in that ramp up the costs for running your PKI. Now, in a fair number
> of cases, that cost of operation and high bar is justified... but that
> limits entrants into any trust registry that adopts the same high bar.
> 
> Ultimately, you (or someone you trust) configure a piece of software
> to trust other pieces of software. Sure, that software will be able to
> point to centralized trust registries that have lists of DIDs...
> however, if you cannot also add to that list, and still have a high
> level of assurance, then we will have failed.
> 
> Some might say that this is analogous to adding a Certificate
> Authority to your browser list, and there is some truth to that.
> However, CAs tend to be too abstract for most people to grasp. "Do you
> want to trust StartCom certificates?" ... sure, I guess so?
> 
> Take that case, versus connecting with a neighbor: "Jane Smith who
> lives at 123 Main Street wants to connect with you. She has verified
> her name and address using a government issued ID card (centralized
> trust registry), do you want to add her to your address book?
> (decentralized identifier provided)."
> 
> The parentheticals show how I would hope we'd blend these trust
> registries... the first registry has high assurance over identity...
> the second registry addition could be a pairwise identifier (DID)
> between you and Jane. Some of this is old news to a number of us on
> the list, but some of the newer people to the community might not be
> aware of this distinction, which is why I raise it.
> 
> Yes, the world will have centralized trust registries, and local trust
> registries, operated by large and small organizations... but we should
> keep our eye on the prize, which is enabling individuals to be able to
> safely (and affordably) mix and match these trust registries, adding
> their own local trust registry to their software.
> 
> -- manu
> 
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> https://www.digitalbazaar.com/