RE: The DID service endpoint privacy challenge

Perhaps we should (even more) clearly distinguish between a public DID – and specify that any service endpoint specified in the associated document SHOULD only accept requests if the response message only contains public data, and similarly that private/peer DIDs MAY accept requests that result in responses that MAY contain private/personal data.

Rieks

From: Oliver Terbu <oliver.terbu@consensys.net>
Sent: maandag 29 juni 2020 16:11
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: W3C DID Working Group <public-did-wg@w3.org>
Subject: Re: The DID service endpoint privacy challenge

@Manu: Could you provide an example for "X"? If X == some.agency.com/users/my-user-id/more-info<http://some.agency.com/users/my-user-id/more-info>, then you would get no benefit.
I do think that service endpoints can be extremely useful for public DIDs of companies. So, I don't know if this counts as an objection because I feel that we are more or less on the same page because I do believe that service endpoints should be avoided for end users if there is no way to fully anonymise the data that is stored on an immutable storage medium.

I'm happy we are having this discussion.

On Mon, Jun 29, 2020 at 3:52 PM Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> 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.

-- manu

--
Manu Sporny - https://www.linkedin.com/in/manusporny/

Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.