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

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<mailto: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>