Re: DID WG Special Topic Call (Service Endpoints)

On 8/27/20 11:38 AM, Daniel Hardman wrote:
>     PROPOSAL: Remove Service Endpoints from the specification and rely on
>     Verifiable Credentials (e.g., transmitted during DID Auth) to
>     communicate Service Endpoints.
> 
> I may not understand this proposal fully or correctly. However, my gut
> reaction is to be concerned about the implication that we must do DID
> Auth before we could know how to talk to a DID controller. That feels
> *very* undesirable to me. We aren't even clear about how to do DID auth
> (there have been a variety of approaches to it over the past 3 years,
> and I'm not aware of any of them being standardized). 

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.

> The privacy rationale also doesn't resonate with me. For institutions,
> service endpoint privacy doesn't matter much, and for individuals, I
> think that's what herd privacy (many individuals at a single endpoint)
> should solve.

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.

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.

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.

-- manu

-- 
Manu Sporny - https://www.linkedin.com/in/manusporny/
Founder/CEO - Digital Bazaar, Inc.
blog: Veres One Decentralized Identifier Blockchain Launches
https://tinyurl.com/veres-one-launches

Received on Thursday, 27 August 2020 15:58:14 UTC