Re: The DID service endpoint privacy challenge

On 6/29/20 10:10 AM, Oliver Terbu wrote:
> @Manu: Could you provide an example for "X"? If X ==
> some.agency.com/users/my-user-id/more-info
> <http://some.agency.com/users/my-user-id/more-info>, then you would get
> no benefit. 

Yes, that would be of no benefit. Instead, what was being referenced was
something more like:

X == decentralized-service/dids/did:ex:123

or

X == <other non-PII URL>

Where "decentralized-service" or "other non-PII URL" could be a lot of
things. Perhaps it could be a datashard or ipfs URL. Perhaps it could be
another DLT that supports tail-dropping. The point would be to include
no PII and decouple it from the DLT that intentionally never forgets (so
the DIDs themselves can't be lost).

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

+1

> 
> 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/
>     Founder/CEO - Digital Bazaar, Inc.
>     blog: Veres One Decentralized Identifier Blockchain Launches
>     https://tinyurl.com/veres-one-launches
> 


-- 
Dave Longley
CTO
Digital Bazaar, Inc.

Received on Monday, 29 June 2020 15:03:53 UTC