RE: The DID service endpoint privacy challenge

Additional approaches:

  1.  do not publish a DID on a publicly readable register. Often, you do not need it.
  2.  if there is a need, use a single endpoint which others can use to initiate an exchange in which you and the other decide whether or not to set up a relationship (e.g. with peer DIDs). Such a service would need to start a process by which you can do anything you require before committing to setting up that relation (some people have no requirements, banks have KYC, I have something in between).

Rieks

From: Oliver Terbu <oliver.terbu@consensys.net>
Sent: maandag 29 juni 2020 11:30
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 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.