Re: DID WG Special Topic Call (Service Endpoints)

People that rely on service endpoints and who do problematic things will
continue using service endpoints and doing problematic things by defining
their own @context and their own service endpoint property. Removing
service endpoints from the specification would just move the problem to an
area where we cannot provide privacy guidance. For that reason, I vote for
keeping service endpoints and for providing extra language for GDPR
guidance. Specifically, the how-to-reach-me use case is very crucial for a
lot of people. I don't see any GDPR-related issues with institutional DIDs.

On Thu, Aug 27, 2020 at 6:09 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

> Yes, agreed, I expect this will be the most undesirable option to most.
>> The counter-point is that everyone *is* doing some form of DID Auth now,
>> and even if it's not officially standardized, we are able to get VCs
>> from point A to point B today.
>>
>
> How do you get VCs from A to B if you don't know how to contact B?
>
> Ah, but the current proposals don't have herd privacy at all. The
>> service endpoints can be anything and most of the examples in the spec
>> today have unique identifiers (correlatable identifiers) at the service
>> endpoints.
>>
>
> The design of DIDComm depends on service endpoints, and these endpoints do
> not have unique identifiers in them; rather, DIDComm carries the unique
> identifiers inside its message envelopes in a privacy-preserving way. They
> are GDPR-compliant. Eliminating this feature from the spec just
> disrupts/marginalizes Aries and DIDComm and eliminates some of their
> supported use cases without improving their privacy postures.
>
>
>>
>> That's what this proposal is about:
>>
>> > PROPOSAL: Define a Service Endpoint for a GDPR-compliant
>> > service that supports Right to be Forgotten and is under the
>> > control of the DID controller.
>>
>> It's about specifying a mechanism/protocol that provides for herd
>> privacy and that's recommended instead of the easily correlatable stuff
>> we're telling people to do today (via existing spec text).
>>
>> The issue isn't with service endpoints that are supposed to be public...
>> use correlatable identifiers for that, no problem. The problem is with a
>> number of conversations we've overheard where DID Method developers
>> don't understand why you wouldn't want to put a unique identifier in the
>> service endpoint URL.
>>
>
> Agreed. That's a conceptual problem. But it's not a deficiency with the
> spec; it's a problem with an unwise impl.
>
>
>> We could prevent this by, for example, noting that a bare DNS domain
>> should be used with no path or query components. We can create normative
>> spec text around that and recommend its usage. If we say nothing, or
>> lightly suggest the right thing to do, we're concerned that we'll get a
>> whole bunch of correlatable identifiers on private individuals,
>> published on ledgers forever, in the ecosystem.
>>
>
> I'm supportive of the GDPR requirement proposal and of the extra language
> to provide guidance.
>