W3C home > Mailing lists > Public > public-did-wg@w3.org > June 2020

Re: The DID service endpoint privacy challenge

From: Oliver Terbu <oliver.terbu@consensys.net>
Date: Mon, 29 Jun 2020 16:10:55 +0200
Message-ID: <CALu3yZLzLyW+3pMHjf=Zpc7qiHkT+mit_amTfoF2Fdmjgv-Xsg@mail.gmail.com>
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: W3C DID Working Group <public-did-wg@w3.org>
@Manu: Could you provide an example for "X"? If X ==
some.agency.com/users/my-user-id/more-info, 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>

> 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/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
Received on Monday, 29 June 2020 14:11:19 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:27:50 UTC