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

Re: DID WG Special Topic Call (Service Endpoints)

From: Daniel Hardman <daniel.hardman@evernym.com>
Date: Thu, 27 Aug 2020 10:08:36 -0600
Message-ID: <CAFBYrUoGH0nP-cDj2b39+X7Cjknpxau1w7eJh1UzCq0+vJu=kA@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: W3C DID Working Group <public-did-wg@w3.org>
> 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 16:09:00 UTC

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