- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Mon, 29 Jun 2020 11:03:35 -0400
- To: public-did-wg@w3.org
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