Re: The DID service endpoint privacy challenge

@Oliver, can you describe or post a link to #3 (initial-value)?

@Rieks. could we do #5 by combining TxAuth with peer DIDs?

- Adrian

On Mon, Jun 29, 2020 at 5:59 AM Joosten, H.J.M. (Rieks) <
rieks.joosten@tno.nl> wrote:

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