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

@Daniel and maybe @Wayne,

I'm not against trying to use DID for public personas but the point of
starting this thread is an attempt to beef up the privacy section of the
DID spec in anticipation of objections like we've seen from EFF and Philip
Sheldrake that, I would summarize, as unintended consequences of SSI. My
other reason for starting this thread is trying to understand what problem
Trust OverIP and the 4-layer governance stack is solving so that we can
speed up the DID standardization process for all of our benefit.

I seem to have more success with this thread instead of the related issue
https://github.com/w3c/did-core/issues/324#issuecomment-651008970 where I
link to the recent SIOP review that goes a long way to linking privacy and
adoption issues.

- Adrian

On Mon, Jun 29, 2020 at 11:45 AM Wayne Chang <wyc@fastmail.fm> wrote:

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