Re: DID WG Special Topic Call (Service Endpoints)

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