RE: The DID service endpoint privacy challenge

@Adrian Gropper<mailto:agropper@healthurl.com>: I'm not up to speed on peer DIDs or txAuth, but it is my understanding that there is an agreement protocol where two digital agents can agree on a DID pair, each of them providing their DID/DIDdoc for the pair, which allows the agents to later recognize one another. If no additional info is exchanged/obtained, they wouldn't know who the other is. However, either party can use any means available to it to obtain such additional info and from that, assess who the other party is with what level of certainty/assurance. Such info can be made available e.g. through the DIF presentation-exchange protocol, OAuth, OIDC, email, SMS, etc., but not all are always appropriate.

From: Adrian Gropper <agropper@healthurl.com>
Sent: maandag 29 juni 2020 13:32
To: Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>
Cc: Oliver Terbu <oliver.terbu@consensys.net>; W3C DID Working Group <public-did-wg@w3.org>
Subject: 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<mailto: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<mailto:oliver.terbu@consensys.net>>
Sent: maandag 29 juni 2020 11:30
To: Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>>
Cc: W3C DID Working Group <public-did-wg@w3.org<mailto: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.