Re: [EXT] Re: [PROPOSED WORK ITEM] Verifiable Issuers and Verifiers

Steve, if you are interested in chained credentials, you might want to check out the ACDC (Authentic Chained Data Container) Task Force<https://wiki.trustoverip.org/display/HOME/ACDC+%28Authentic+Chained+Data+Container%29+Task+Force> and the ACDC IETF Internet Draft<https://trustoverip.github.io/tswg-acdc-specification/draft-ssmith-acdc.html> in the Technology Stack Working Group of the ToIP Foundation<https://trustoverip.org/>.

GLEIF<https://www.gleif.org/en/> is using ACDC credentials for chaining vLEI (verifiable LEI) credentials for organizational identity. vLEI credentials bind a did:keri identifier with an LEI<https://en.wikipedia.org/wiki/Legal_Entity_Identifier> (Legal Entity Identifier). You can see the complete vLEI governance framework here<https://www.gleif.org/en/vlei/introducing-the-verifiable-lei-vlei>.

Also, the ToIP Foundation has launched the second generation of its Trust Registry Task Force<https://wiki.trustoverip.org/display/HOME/Trust+Registry+Task+Force> that is meeting twice a week on Thursdays (NA/EU and APAC time zones).

=Drummond

From: Steve Capell <steve.capell@gmail.com>
Date: Friday, December 16, 2022 at 4:52 PM
To: Christopher Allen <ChristopherA@lifewithalacrity.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, W3C Credentials CG <public-credentials@w3.org>
Subject: [EXT] Re: [PROPOSED WORK ITEM] Verifiable Issuers and Verifiers
Yes!

We simply cannot use registries or lists as they are both unmaintainable and often cannot be public because the totality of information in them is essentially commercially sensitive customer lists

Is there a separate work item on chained credentials and the linked semantics within them?  If not will this work item address that ? If not should I start a new work item ?

Kind regards
Steven Capell
Mob: 0410 437854


On 17 Dec 2022, at 11:48 am, Christopher Allen <ChristopherA@lifewithalacrity.com> wrote:





On Fri, Dec 16, 2022 at 2:54 PM Steve Capell <steve.capell@gmail.com<mailto:steve.capell@gmail.com>> wrote:
The thing that worries me in reading your proposal is the use of words like “list of trusted issuers”.  We will be addressing this problem not with lists but with chained credentials where the verifier follows the chain until it reaches a trust anchor that they can trust.  That’s because the lists are too big and fast changing and are themselves sensitive.

My concerns about trust registries are similar, and I've written about them recently in a blog post "Progressive Trust: A New Approach to Building Trust in Decentralized Systems" at https://www.blockchaincommons.com/musings/musings-progressive-trust/<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.blockchaincommons.com%2Fmusings%2Fmusings-progressive-trust%2F&data=05%7C01%7Cdrummond.reed%40gendigital.com%7C3f72ef14658b49f2b29108dadfc905e3%7C94986b1d466f4fc0ab4b5c725603deab%7C0%7C0%7C638068351723598772%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jJAxbXLqumuv8jNsBlb2vDgm5IiZDiwGMMEVm1KUguY%3D&reserved=0>

Trust registries may not be able to capture the dynamics of trust-building over time, which can be vital to building trust in complex or evolving systems. Further, trust registries can become outdated or irrelevant as requirements and details change for each party, resulting in gaps that make it difficult to determine the authenticity and reliability of new data with a privacy-breaking “phone home.”

Another important problem is that, to date, trust registries do not treat the risks of all parties equally, or focus on mitigating the risks of those parties with more power to influence the registry, or create a dependence that is likely to be an expensive barrier to entry or only benefits the few.

Even with highly-distributed trust registries, the costs to maintain them may be high enough that only the biggest orgs can offer them, leaving smaller organizations' requirements behind. Look at a current example: it currently requires a Google-class infrastructure to maintain the current DNS Certificate Transparency lists. There have been proposals to make it more distributed and less burdensome, but Google is not incentivized to do so.

I'd love to find an architecture where every party's "trust filters" are easily adaptable and also easily decentralized (not just distributed). But even with solutions for those first two problems, we still have some additional challenges to address, such as the risk surface of peers sharing trust registries, inadvertent "first mover" advantages of one party's trust anchors overwhelming others because they published first, etc.

P.S. I'm not arguing that this work should move forward as a CCG work item, it should — +1!  I'd just like this group to also address these challenges, even if only to document them as some type of "long-term requirement."

-- Christopher Allen