- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Fri, 13 Apr 2018 17:34:28 -0400
- To: Brent Zundel <brent.zundel@evernym.com>
- Cc: Chris Boscolo <chris@boscolo.net>, Adam Powers <adam@fidoalliance.org>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
On 04/13/2018 03:16 PM, Brent Zundel wrote: > Sovrin does encourage the use of pairwise DIDs. Each relationship should > have a unique pair of DIDs, even if one or both of the entities has a > ledger-bound "public" DID. > The point of pairwise DIDs is exactly to avoid building "up a lot of > correlatable data about yourself." At the risk of going way off topic, I do think it's important to mention this to others who may not be familiar with pairwise DIDs: It should be noted that using pairwise DIDs is a *requirement* for avoiding correlation where the common link would be a DID. This does not mean that pairwise DIDs will enable you to "avoid building up a lot of correlatable data about yourself". The number of ways this may occur is myriad and pairwise DIDs plug a single hole in that colander. If your use case can be addressed such that it has just that one hole, then the math of ZKPs (Zero-Knowledge Proofs, more on those below) and the use of pairwise DIDs will keep your shared information isolated. These use cases are a good fit for the technology and the added complexity it brings. But, be aware that if your use case has more than one hole, then those technologies do not have the power keep your shared information isolated. They, of course, will still make sure that at least one hole is plugged, but they cannot help you with the others. I think everyone unfamiliar with the tech (but using it) should know this; we don't want to give false assurances that may lead people to engage in more risky behaviors than they would have otherwise. By means of example, suppose you share that: 1. you are "over 21" and your DID is "A" with "company1.com", and 2. you are a "US citizen" and your DID is "A" with "company2.com" Clearly, should company1 and company2 elect to share your information, then both will know that you are "over 21" and a "US citizen". Pairwise DIDs would prevent this by breaking the common link of a single DID. Instead, you'd use two different DIDs: 1. you are "over 21" and your DID is "A" with "company1.com", and 2. you are a "US citizen" and your DID is "B" with "company2.com" Now "company1" and "company2" -- *on the basis of the DIDs* -- cannot establish a common link. You may be two different people for all they know. However, there may be other ways to establish a common link. IP addresses, browser fingerprints, third party tracking cookies, or AI analysis of Web surfing time/behavior are all examples of "side channel" information that could reveal a common link. Supposing we could eliminate these side channels, then there is a possibility that other information that is explicitly shared can still establish a common link. For example, if you shared: 1. you are "over 21", your email is "alice@example.com", and your DID is "A" with "company1.com", and 2. you are a "US citizen", your email is "alice@example.com", and your DID is 2 with "company2.com" Then your email address provides a common link to enable companies that share your information to aggregate data to build a single profile on you. If this data must be exchanged, then only policy and law can help mitigate this problem. > > The Sovrin protocol does not issue credentials to a DID, but rather to a > DID holder. The credentials themselves may then be used across different > DIDs. > We like to think of DIDs as identifiers for relationships, while > credentials represent qualities or attributes. The attributes help > define a digital version of me; I can selectively share portions of that > digital version among my relationships. Below is just a general warning for our community (I'm not addressing anyone in particular) and is for the benefit of others less familiar with this technology: What is stated here is true, given the caveats above. Systems like Sovrin use a common "link secret" that is held privately by what is referred to here as the "DID holder". This "link secret" is never revealed through the use of "ZKPs". An issuer of a Verifiable Credential can bind the credential to your "link secret" without you having to reveal it -- and -- you can share proof that you possess that credential and that the issuer signed off on it to *someone else* ... all while not revealing the "link secret" to anyone. This requires a fair bit of fun math, it works, and is very cool. Users should be aware that if their software uses the same "link secret" for all of their credentials that the loss of that link secret could be catastrophic. It would mean that all credentials must be reissued (which must be done carefully to avoid correlation) and that if that secret were obtained by a malicious party then the knowledge that all accessible information is linked to the same entity would be revealed. Obviously the loss of a wallet full of credentials to a malicious party is a problem whether it's a physical wallet, a wallet that doesn't use ZKPs, or one that does. So some problems are not unique to software that uses pairwise DIDs and ZKPs. However, the damage may be greater for users that significantly change their behavior because they believe a risk has been mitigated to a degree that it has not been. For example, users that have no knowledge of this sort of technology may presently attempt to be as anonymous as possible. They may avoid directly sharing any information with certain websites, especially on handheld personal devices. Should they get the wrong idea about what this technology can do, i.e. believing that with this new tech *everything they share is unlinkable*, they may change this behavior in ways that could *increase* their correlation risk and result in significant harm. I'm much more comfortable with telling people that this technology can help make specific existing interactions more private and enable specific new interactions that weren't possible before. In other words, keep the scope of promises under control. So, all of this is to say that this sort of technology can be used to help solve certain use cases. But we need to be careful that the enthusiasm for this technology does not lead people to believe it does more than it can. I fully expect "but the technology doesn't stop other correlation" to be an unacceptable response *after* a massive privacy violation occurs. This could be damaging to the community as a whole. I think the community should be clear about the scope of the benefits of the technology and the pitfalls of using it in conjunction with existing systems from the beginning. Let's be careful not to fall into the well known "blockchain can solve every problem" trap that can arise from the enthusiasm for any new technology. This community is working on valuable tools but we need to make sure that people understand their limitations and for which jobs they are appropriate. > > > On Fri, Apr 13, 2018 at 12:07 PM, Dave Longley > <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>> wrote: > > On 04/13/2018 01:34 PM, Chris Boscolo wrote: > > Regarding my questions "2a". Sorry, I didn't phrase that clearly. > > I was just questioning whether pair-wise unique DIDs are > feasible when considering the WebAuthn flows. > > From other comments on this thread, it sounds like some people > think pair-wise unique DIDs are not always needed. It would be > nice to hear from someone at Sovrin regarding this. > > > I am another "some person" that agrees that pairwise unique DIDs are a > fit-for-purpose approach (i.e. not always needed). This is true for many > common interactions where other personal identifiers are exchanged (e.g. > email). I expect many of the scenarios where pairwise DIDs are > desirable do not even require their storage on ledger for long term use. > If you are going to build up a lot of correlatable data about yourself > with a particular DID, you've likely defeated the purpose of using a > pairwise DID to begin with. > > Using the same DID, even with only the same party, over a long period of > time, produces patterns that reveal more information than the user may > have intended -- to the point that they may be personally identified. > And this information could be shared across boundaries that the user did > not intend in a variety of ways. > > The primary purpose of DIDs and SSI is to give greater control over > identifiers and data to people; this holds true even if there are > secondary advantages that arise from the model that do not apply to > every use case. > > > My opinion is that when one side of the conversation is a public > entity like PayPal or CA-DMV, -- which is most WebAuthn use > cases -- they should just use one public DID. > > > There are still good reasons to use more than one public DID, but people > should be aware of the limitations of pairwise identifiers particularly > in these cases where personally identifiable information is exchanged or > where side channel information defeats privacy. > > Privacy will need to be protected by policy and law under certain > circumstances. > > > -chrisb > > On Fri, Apr 13, 2018 at 9:35 AM, Adam Powers > <adam@fidoalliance.org <mailto:adam@fidoalliance.org> > <mailto:adam@fidoalliance.org <mailto:adam@fidoalliance.org>>> > wrote: > > > Answers inline below. > > > On April 13, 2018 at 9:25:33 AM, Chris Boscolo > (chris@boscolo.net <mailto:chris@boscolo.net> > <mailto:chris@boscolo.net <mailto:chris@boscolo.net>>) wrote: > > Adam, > I'm jumping in here mid-stream, so I apologize if my > questions/comments have been discussed. > > In your presentation "WebAuthn & DID.pptx", I see two > things that > concern me. > > 1) In the "DID Registration Flow" (slide 3), it looks > like the > "issuer" is writing the user DID to the ledger. > Would this not create an undesirable public correlation > between > the user DID and the issuer? > > > That may be my misunderstanding of the typical / existing DID > registration flow. As long as the public key exists in the > ledger I > think it's fine, but it's probably worth a conversation of > what that > flow would look like (especially with regards to the > security model > assumed by WebAuthn). > > 2) In all of the DID-based flows, it does not appear > that the > "service/issuer" ever uses a unique DID when > communicating with a > user. > In most discussion of DID based SSI that I have seen, > there are > always unique DIDs for each side of the communication. > How would > this work in the context of WebAuthn? > > > Interesting -- you're right, that's totally missing because > I wasn't > aware that was an essential feature of DID. It may also > address some > of the anti-phishing concerns that arise from removing / > changing > the origin. I don't think it would be hard to add it into the > protocol and it seems like it could be a useful clarification. > > 2a) Is aper-user unique DID on the service side even > feasible? > > > I don't follow the concern here. > > > > -chrisb > > On Thu, Apr 12, 2018 at 11:17 PM, Adam > Powers<adam@fidoalliance.org > <mailto:adam@fidoalliance.org> <mailto:adam@fidoalliance.org > <mailto:adam@fidoalliance.org>>>wrote: > > Great point, here are the links from my > presentation (there > were a couple other presentations as well): > https://drive.google.com/drive/folders/1LyYp_SZpqboIPfUa1lo9zKtNv9SIv-5I?usp=sharing > <https://drive.google.com/drive/folders/1LyYp_SZpqboIPfUa1lo9zKtNv9SIv-5I?usp=sharing> > > <https://drive.google.com/drive/folders/1LyYp_SZpqboIPfUa1lo9zKtNv9SIv-5I?usp=sharing > <https://drive.google.com/drive/folders/1LyYp_SZpqboIPfUa1lo9zKtNv9SIv-5I?usp=sharing>> > > I think the only real problem we encountered was > that (by > design) WebAuthn uses "origin" to bind > authentication to a > specific service. It's a solvable problem, it will > just take > some conversation to figure out the pros and cons > of some of > the solutions that were mentioned. At the very > least, it's > implementable / demo-able now but the same DID > can't be used > across multiple sites until the origin issue gets > solved. > > On April 12, 2018 at 10:19:06 AM, Andrew Hughes > (andrewhughes3000@gmail.com > <mailto:andrewhughes3000@gmail.com> > <mailto:andrewhughes3000@gmail.com > <mailto:andrewhughes3000@gmail.com>>) wrote: > > At the Internet Identity Workshop (IIW) last > week in Mountain > View, there were some sessions discussing > exactly this topic > - how should WebAuthn and Verifiable > Credentials and > Credentials Community Group work together - > leaders from each > of the efforts were in attendance. > > andrew. > > *Andrew Hughes *CISM CISSP > *In Turn Information Management Consulting* > > o +1 650.209.7542 > m +1 250.888.9474 > 1249 Palmer Road, Victoria, BC V8P 2H8 > > <https://maps.google.com/?q=1249+Palmer+Road,%C2%A0Victoria,+BC+V8P+2H8&entry=gmail&source=g > <https://maps.google.com/?q=1249+Palmer+Road,%C2%A0Victoria,+BC+V8P+2H8&entry=gmail&source=g>> > AndrewHughes3000@gmail.com > <mailto:AndrewHughes3000@gmail.com> > <mailto:AndrewHughes3000@gmail.com > <mailto:AndrewHughes3000@gmail.com>> > ca.linkedin.com/pub/andrew-hughes/a/58/682/ > <http://ca.linkedin.com/pub/andrew-hughes/a/58/682/> > > <http://ca.linkedin.com/pub/andrew-hughes/a/58/682/ > <http://ca.linkedin.com/pub/andrew-hughes/a/58/682/>> > *Identity Management | IT Governance | > Information Security * > > > On Thu, Apr 12, 2018 at 10:08 AM, Adam > Powers<adam@fidoalliance.org > <mailto:adam@fidoalliance.org> > <mailto:adam@fidoalliance.org > <mailto:adam@fidoalliance.org>>>wrote: > > The quickest summary: WebAuthn is a way of > generating > public key pairs, storing a public key on a > server and > the private key in an "authenticator", and > later using > that key pair for authentication to a service. > > Insofar as DID is storing a public key in a > DID document, > that public key can be generated by > WebAuthn and stored > by DID. The most obvious overlap between > DID and WebAuthn > would be using WebAuthn as the mechanism > for DIDAuth -- > although there is still some work that > needs to happen > there to define and align the specs. In my > perspective, > they should be complimentary and not > competitive. > > I hope that helps. > > Adam Powers, > Technical Director, FIDO Alliance > > > > On April 12, 2018 at 9:24:03 AM, Steven Rowat > (steven_rowat@sunshine.net > <mailto:steven_rowat@sunshine.net> > <mailto:steven_rowat@sunshine.net > <mailto:steven_rowat@sunshine.net>>) wrote: > > Greetings, > > The Guardian yesterday had a story of > what appears to be > a major > announcement about how WebAuthn will > replace passwords: > > https://www.theguardian.com/technology/2018/apr/11/passwords-webauthn-new-web-standard-designed-replace-login-method > <https://www.theguardian.com/technology/2018/apr/11/passwords-webauthn-new-web-standard-designed-replace-login-method> > > <https://www.theguardian.com/technology/2018/apr/11/passwords-webauthn-new-web-standard-designed-replace-login-method > <https://www.theguardian.com/technology/2018/apr/11/passwords-webauthn-new-web-standard-designed-replace-login-method>> > > This included a quote showing that this > is a W3C project: > > “WebAuthn will change the way that > people access the > Web,” said Jeff > Jaffe, chief executive of the World > Wide Web Consortium > (W3C), the > body that controls web standards." > > And after looking at the recent API > spec itself, I see > that it's a > FIDO project, and so supported by > Google, Microsoft, > Paypal, and also > Mozilla: > > http://www.w3.org/TR/2018/CR-webauthn-20180320/ > <http://www.w3.org/TR/2018/CR-webauthn-20180320/> > > <http://www.w3.org/TR/2018/CR-webauthn-20180320/ > <http://www.w3.org/TR/2018/CR-webauthn-20180320/>> > > My Question: > > Is there any expected or known > relationship between > WebAuthn and the > use of DIDs? ie., Can WebAuthn be used > with DIDs? Will > the uptake of > WebAuthn preclude or inhibit the use of > DIDs? > > ie., Are DID Docs and WebAuthn in > competition, or are > they complementary? > > Steven > > > > > > > > > > > > > -- > Dave Longley > CTO > Digital Bazaar, Inc. > http://digitalbazaar.com > > -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Friday, 13 April 2018 21:35:03 UTC