- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Mon, 7 Mar 2022 19:50:14 -0500
- To: public-credentials@w3.org
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 description? 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) https://www.digitalbazaar.com/
Received on Tuesday, 8 March 2022 00:50:31 UTC