Re: The DID service endpoint privacy challenge

On 6/29/20 9:52 AM, Manu Sporny wrote:
> 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
> registries.
> 
> 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.

I think it's also important to remember that if you want to "discover" a
service endpoint from a DID Document, you first needed to have
"discovered" the DID. How did that happen? In many cases, you had to ask
for it from the DID controller; in which case you often would have to
tools to also ask for this "seeAlso"/"moreInformation" service endpoint
-- and for authorization to read specific information from it as well.

I think that service endpoints that are directly advertised in DID
Documents only make sense for "public" or "social" DIDs. Even then,
particularly for DID methods that use DLTs that do not easily support
deletion, service endpoint information should be expressed elsewhere.
This points to a need for other decentralized registry services that
allow for both discovery and deletion. These services would not need to
be DID-method specific.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Monday, 29 June 2020 14:28:30 UTC