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

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

ACDCs (KERI's mechanism for verifiable data graphs that includes credential
use cases; see https://trustoverip.github.io/tswg-acdc-specification/) 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/ ) and Credential Engine (
> https://credentialengine.org/ ) 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) and web
> verifier (https://verifierplus.org/) 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
>
> 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
>
> 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/.
>
> 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
> she/her
>
>
>
> Join the DCC mailing list
> <https://mit.us6.list-manage.com/subscribe?u=ad81d725159c1f322a0c54837&id=3621913fe4>
> and follow us on LinkedIn <https://www.linkedin.com/company/dccconsortium>
> 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/, you would have someone use
> https://www.dmv-california.org 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.
>
>