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