RE: The DID service endpoint privacy challenge

Please make sure which privacy requirements we are actually talking about, see
https://medium.com/@christophera/the-four-kinds-of-privacy-bf4b0bf222ac

Note that also some organisations require privacy, e.g. an organisation of under-cover journalists.
Also: to what extent would ToR onion addresses qualify as service endpoint?


From: Oliver Terbu <oliver.terbu@consensys.net>
Sent: 29 June 2020 11:38
To: Adrian Gropper <agropper@healthurl.com>
Cc: W3C DID Working Group <public-did-wg@w3.org>
Subject: Re: The DID service endpoint privacy challenge

I also want to add that the privacy challenge depends also on the use case. A company that has a DID and wants to advertise their services is different from end users who want to share data with someone else and even here it depends on which persona the DID represents.

Thanks,
Oliver

On Mon, Jun 29, 2020 at 11:29 AM Oliver Terbu <oliver.terbu@consensys.net<mailto:oliver.terbu@consensys.net>> wrote:
I agree that there is a privacy challenge.

Three approaches:
1. The service endpoint should be as aggregated as possible which means the endpoint itself should not allow Eve to identify a single entity.
2. Don't use service endpoints in public DID Documents.
3. Propagate service endpoints using the `initial-value` DID parameter which is similar to 2.

If there must be one, then we could define a DID service discovery endpoint (similar to OpenID Connect<https://openid.net/specs/openid-connect-discovery-1_0.html>) that provides meta-data about all enabled service capabilities. But I would argue that this is not the best solution.

Thanks,
Oliver

On Mon, Jun 29, 2020 at 11:15 AM Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>> wrote:
I’m hoping to speed the privacy discussion across DID, auth, and SDS by introducing a challenge:



DiDs are a public and persistent identifier that will be indexed, correlated, analyzed and catalogued to create new opportunities for privacy and security mischief including inferences leading to discrimination, spam, and denial of service attacks. The mitigation of these attacks is rooted in the demarcation between the public DID Document and the private user agent that controls the DID, often secured by a biometric.



This demarcation is the service endpoint. If DIDs were normatively restricted to a single service endpoint privacy analysis would be greatly simplified. Allowing multiple service endpoints of the same type and of different types (authorization, storage, notification) makes privacy analysis of DIDs more difficult and unintended consequences more likely.



If there were only one service endpoint, what would it be and could it accommodate authentication, authorization, storage, and notification uses without undue limitation?



- Adrian
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.