RE: DID WG Special Topic Call (Service Endpoints)

+1 to Daniel's view.

The whole purpose of DIDs is to enable the DID controller to publish useful information. "How to reach me" (cf Service End Point) is extremely useful information, both for businesses and individuals. 

There is a business opportunity for "Privacy Routing Service Providers" to provide generic herd-privacy-supporting service end points. The fact that those do not exist today is a bad reason to deprecate the feature. The fact that (some?) DID Method developers take short-cuts means that we have some education to do, including normative spec text and providing best practices. 

Oskar


-----Original Message-----
From: Manu Sporny <msporny@digitalbazaar.com> 
Sent: 27 August 2020 17:58
To: public-did-wg@w3.org
Subject: 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


This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.

Received on Thursday, 27 August 2020 16:07:54 UTC