W3C home > Mailing lists > Public > public-did-wg@w3.org > June 2020

Re: The DID service endpoint privacy challenge

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 29 Jun 2020 09:52:28 -0400
To: public-did-wg@w3.org
Message-ID: <4bccca3b-320d-7349-599a-a6e3c3e01063@digitalbazaar.com>
On 6/29/20 5:14 AM, Adrian Gropper wrote:
> If there were only one service endpoint, what would it be and could it
> accommodate authentication, authorization, storage, and notification
> uses without undue limitation? 

I believe that this is where Digital Bazaar currently is... that service
endpoints advertised in the DID Document are an anti-pattern... we can
already see that developers without a background in privacy engineering
are unwittingly abusing the field.

In the simplest case, it creates large challenges wrt. GDPR and the
organizations creating software for or running verifiable credential

In many other use cases, it invites abuse (direct link to your personal
Identity Hub, web page, email, being some of them).

The solution is probably to place a pointer in a DID Document that
effectively states: "You can find more information about the DID Subject
over here ---> X"... and then to point to somewhere that a caller can
see public information in a way that is GDPR compliant (e.g., a list of
Verifiable Credentials), or for more advanced use cases, where the
caller can authenticate in order to get information that is intended for
only a subset of individuals (again, protecting privacy by default).

Would anyone object if we took service endpoints in this direction?
Effectively, we'd replace them with a "seeAlso" or "moreInformation"
link pointing to a list of Verifiable Credentials that would provide
information relating to identity hubs, personal data stores, web pages,
contact information, and other privacy-sensitive material.

-- manu

Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
Received on Monday, 29 June 2020 13:52:42 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:27:50 UTC