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