W3C home > Mailing lists > Public > public-did-wg@w3.org > August 2020

Re: DID WG Special Topic Call (Service Endpoints)

From: Oliver Terbu <oliver.terbu@consensys.net>
Date: Thu, 27 Aug 2020 20:03:57 +0200
Message-ID: <CALu3yZJwrG_jg=kvp3kUjmuR4W=Ow0A6jxoX-VyYeFSXo+VvYw@mail.gmail.com>
To: Daniel Hardman <daniel.hardman@evernym.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, W3C DID Working Group <public-did-wg@w3.org>
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>

> 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.
Received on Thursday, 27 August 2020 18:05:14 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:27:50 UTC