Re: The DID service endpoint privacy challenge

@Adrian: a few people have discussed whether a similar mechanism to
sidetree can be used to convey the initial state of the DID Doc in a
specific DID query parameter (e.g., on DID exchanged). The main point here
is that this is not a common approach and it requires DID method
specification authors and implementers to support it. One of the main
challenges is to provide a secure transaction history and also to enable
changes to the DID Doc which are propagated automatically after the DID
exchange. `did:peer` might adopt `initial-value`.

On Mon, Jun 29, 2020 at 1:32 PM Adrian Gropper <agropper@healthurl.com>
wrote:

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