Re: [PROPOSED WORK ITEM] Verifiable Issuers and Verifiers

On Fri, Dec 16, 2022 at 7:48 PM Christopher Allen wrote:
> My concerns about trust registries are similar

Yes, we tried very hard to stay away from words like "trust" and
"authority" and anything that would suggest an unfavorable power
dynamic. As I mentioned in the response to Steve, anyone should be
able to create and share a Verifiable Issuer List (or Verifiable
Verifier List). It can be done publicly, within a group, or privately.
We were going for a solution that was decentralized and
permission-less. Opt'ing into these lists should be voluntary, and you
should be able to opt into multiple lists at the same time... even
ones that conflict with one another (North Korea will not have the
same Verifiable Issuer lists as South Korea, for example).

> 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.”

Yes, all of these concerns were front and center in the analysis we
did, which is why we didn't title the work "trust registry" -- we
expect that a "trust registry" is something else, with the same
concerns that you raise above.

> 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.

Yes, again, agreed. We tried to stay away from a name that would imply
that the list is anything more than just a list of issuers or
verifiers that are published to do a particular task. You may or may
not be ok with the entity publishing the list, and you have the
ability to configure your software to only include the lists that you
are willing to use during your issuance or verification processes.

> 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.

The Verifiable Issuer and Verifier data model supports the expression
of a list as a Verifiable Credential, which means that it can be put
up as a file on a website (with the presumption that publishing a file
on a website is a low enough bar today), or it can be provided during
a Verifiable Presentation (peer-to-peer).

> 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.

Yes, and this is exactly the rationale behind questioning whether
following the current Certificate Authority model with a centralized,
hierarchical distribution model was the best one to start with. A
Verifaible Issuer and Verifier list is just that -- it's not
hierarchical, anyone can publish them, and the contents are determined
by the entity that is publishing the list. You don't need permission
to create, share, or use these lists.

> I'd love to find an architecture where every party's "trust filters" are easily adaptable and also easily decentralized (not just distributed).

This was something that we discussed at depth and those goals are in
scope, AFAICT.

> 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.

Yep, no easy solution to that yet. Logged as issues for now:

https://github.com/msporny/verifiable-issuers-verifiers/issues/2
https://github.com/msporny/verifiable-issuers-verifiers/issues/3

> 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."

Thanks for the support, logged some issues above (which will be
automatically transferred to CCG if this becomes a work item).

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
https://www.digitalbazaar.com/

Received on Saturday, 17 December 2022 20:12:11 UTC