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

Re: The DID service endpoint privacy challenge

From: Oliver Terbu <oliver.terbu@consensys.net>
Date: Mon, 29 Jun 2020 11:29:37 +0200
Message-ID: <CALu3yZ+MJoWS16q1mM69SUopHd-+Bx4Yn6MbO+t=hg0rhSDQMA@mail.gmail.com>
To: Adrian Gropper <agropper@healthurl.com>
Cc: W3C DID Working Group <public-did-wg@w3.org>
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.


On Mon, Jun 29, 2020 at 11:15 AM Adrian Gropper <agropper@healthurl.com>

> 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
Received on Monday, 29 June 2020 09:30:02 UTC

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