W3C home > Mailing lists > Public > public-credentials@w3.org > March 2022

Re: Cross border identity use case - which did methods?

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 7 Mar 2022 19:50:14 -0500
To: public-credentials@w3.org
Message-ID: <19dbd4ec-f2ae-9f41-02f3-178174b1e657@digitalbazaar.com>
On 3/6/22 3:14 PM, Steve Capell wrote:
> - is that because you want to avoid any identity correlation concerns?

As a general rule, yes.

> That’s understandable but what if the use case is specifically to allow 
> correlation of a did to a public identity ?

Warning: Controversial content follows...

Sure, that's a valid use case. That said, how is a DLT-based system supposed
to know the difference between a "public identity" and a "private identity".
That is, who holds the liability when someone inevitably abuses the service

Some lawyers I've talked to have said "the individual that wrote the record to
the DLT". Other lawyers have said "Well, it's complicated -- could the DLT
creators or non-profit that manages the code base or operations have prevented
that from happening? If so, then yes, they're liable."

The solution that we've found, that seems to work for everyone involved
regardless of where they fall on the topic above, is to allow for ONE tightly
controlled service description in a DID Document that specifies a public
interaction point where you can "Get more VCs...".

This might be a public website, a VC API exchange endpoint that requires
authn, or some DIDCommv2 endpoint. The key here is that the type and URL are
so tightly locked down that the possibility of any sort of PII being leaked is
far lower than the "wild west" that service endpoints represent today.

So, if we are to keep using service endpoints in DID Documents, the above
might be a good strategy that balances the ecosystem requirements around
discoverability and liability.


As an alternative, all the DID interactions we've found have the DID
controller transmitting VCs in the very first interactions they have. So, if
you want to know service endpoints associated w/ a DID, just ask when they do
a DID Auth to log in. If that service every stops responding, just ask for an
updated endpoint.


In any case, all that to say that there are multiple solutions to this
problem... but I'm unsure if many people entering the ecosystem today are even
aware of the problem (based on some really bad service description examples
I've seen linked from DID Method registrations)... and that's from the people
implementing DID Methods, much less the people using them!

-- manu

Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
News: Digital Bazaar Announces New Case Studies (2021)
Received on Tuesday, 8 March 2022 00:50:31 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:25:29 UTC