Re: [EXTERNAL] Re: The DID service endpoint privacy challenge

Wanted to add on the following use case for consideration, which takes an approach that is a hybrid of the extremes that Adrian was talking about:

1. User has publicly-available and indexable DID, not unlike MIT Key Server. Probably resolved against public blockchain
2. Public DID has a single service to spawn new DIDs from a service-specified set of types, such as WhisperChannel, FileUpload, PresentationRequest, Payment.BTC, or Payment.ETH.
3. Spawned DIDs use a method that resolves against a privately-controlled server, and the DID Doc contains additional service information per its type, probably just one service. Perhaps it even supports modes for authenticated and authorized DID Doc resolution. Spawned DID lifespans can be ephemeral (single use, expiration date, message limit, etc.) or long-living.
4. The new DID is used for the interaction with no correlation except to the "anchor" public DID.
5. Optionally, if the service requestor is also using DIDs, a similar dance could happen on their end to create an ad-hoc DID to better preserve their privacy as well.

Is there any prior work on something similar?

On Mon, Jun 29, 2020, at 11:19 AM, Daniel Buchner wrote:
> 

> I just want to level set here with a user requirement we have on our list of needs:
> 
> 

> As a user, I would like at least one (or more) globally indexable/resolvable public persona IDs anyone can use to locate my personal datastore to view all sorts of intended-public data I want associated with my public persona IDs, including: headshot/bio, short social posts (e.g. tweets), blog posts, resume info, etc. As a user who currently, along with most of the planet, wants to have at least one public persona ID that is known to represent me across many different venues of interaction, I want this intended-public data to come from me, not be subject to the censorship and crony whims of large service providers and other entities who may seek to interdict my communication and suppress my ability to broadcast myself to the world.

> 

> ^ This is what 90% of the people on the planet want, and they express this by trying to get the same username across many different public facing apps, then posting a picture of themselves with a small bit bio text (in fact, I know many of you on the thread who do exactly this). I will be frank, as I so often am: to pretend the free and open web of publicly exchanged posts, comments, etc. is some horrible thing to be avoided is to *implicitly* argue against posting to Twitter, showing off your resume on websites, or posting articles on your personal blog. Please, please understand that intended-public data is incredibly useful, not evil, and represents a massive % of the data/app traffic in the world. I get the sense we are often designing everything around a small use case called ‘credentials’ that comprises sub-1% of my identity interactions (which includes every interaction/exchange that others can know about me:  http://www.backalleycoder.com/2018/01/25/identity-is-the-dark-matter-energy-of-our-world/). The goal should be privacy where we want and need it, not hobbling a bunch of other obviously beneficial things people want and need to do in their daily lives.

> 

> - Daniel

> 

> 

> 

> *From:* Oliver Terbu <oliver.terbu@consensys.net> 
> *Sent:* Monday, June 29, 2020 7:11 AM
> *To:* Manu Sporny <msporny@digitalbazaar.com>
> *Cc:* W3C DID Working Group <public-did-wg@w3.org>
> *Subject:* [EXTERNAL] Re: The DID service endpoint privacy challenge
> 

> 

> @Manu: Could you provide an example for "X"? If X ==  some.agency.com/users/my-user-id/more-info <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsome.agency.com%2Fusers%2Fmy-user-id%2Fmore-info&data=02%7C01%7Cdaniel.buchner%40microsoft.com%7C19d1cf48b76b4e594b8508d81c3657a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290367011388819&sdata=f5k09JOGQj19c7a3gd3gw6lZJ37gdnxMS2xT3LyOV80%3D&reserved=0>, then you would get no benefit. 

> I do think that service endpoints can be extremely useful for public DIDs of companies. So, I don't know if this counts as an objection because I feel that we are more or less on the same page because I do believe that service endpoints should be avoided for end users if there is no way to fully anonymise the data that is stored on an immutable storage medium.

> 

> I'm happy we are having this discussion.

> 

> On Mon, Jun 29, 2020 at 3:52 PM Manu Sporny <msporny@digitalbazaar.com> wrote:

>> 

>> On 6/29/20 5:14 AM, Adrian Gropper wrote:
>> > If there were only one service endpoint, what would it be and could it
>> > accommodate authentication, authorization, storage, and notification
>> > uses without undue limitation? 
>> 
>> I believe that this is where Digital Bazaar currently is... that service
>> endpoints advertised in the DID Document are an anti-pattern... we can
>> already see that developers without a background in privacy engineering
>> are unwittingly abusing the field.
>> 
>> In the simplest case, it creates large challenges wrt. GDPR and the
>> organizations creating software for or running verifiable credential
>> registries.
>> 
>> In many other use cases, it invites abuse (direct link to your personal
>> Identity Hub, web page, email, being some of them).
>> 
>> The solution is probably to place a pointer in a DID Document that
>> effectively states: "You can find more information about the DID Subject
>> over here ---> X"... and then to point to somewhere that a caller can
>> see public information in a way that is GDPR compliant (e.g., a list of
>> Verifiable Credentials), or for more advanced use cases, where the
>> caller can authenticate in order to get information that is intended for
>> only a subset of individuals (again, protecting privacy by default).
>> 
>> Would anyone object if we took service endpoints in this direction?
>> Effectively, we'd replace them with a "seeAlso" or "moreInformation"
>> link pointing to a list of Verifiable Credentials that would provide
>> information relating to identity hubs, personal data stores, web pages,
>> contact information, and other privacy-sensitive material.
>> 
>> -- manu
>> 
>> -- 
>> Manu Sporny -  https://www.linkedin.com/in/manusporny/ <https://nam06..safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.linkedin.com%2Fin%2Fmanusporny%2F&data=02%7C01%7Cdaniel.buchner%40microsoft.com%7C19d1cf48b76b4e594b8508d81c3657a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290367011398778&sdata=TWWk%2FH7dkZNNBKZpofvRijoMXTxXZaWlRYIPvV8e3so%3D&reserved=0>
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: Veres One Decentralized Identifier Blockchain Launches
>> https://tinyurl.com/veres-one-launches <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftinyurl.com%2Fveres-one-launches&data=02%7C01%7Cdaniel.buchner%40microsoft.com%7C19d1cf48b76b4e594b8508d81c3657a9%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637290367011398778&sdata=UYv%2B2fEskryLWZUP5%2FMPbWANvIcSw8Ii9bPcvH4JH2w%3D&reserved=0>
>>