- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Fri, 13 Apr 2018 14:07:04 -0400
- To: Chris Boscolo <chris@boscolo.net>, Adam Powers <adam@fidoalliance.org>
- Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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>> wrote: > > > Answers inline below. > > > On April 13, 2018 at 9:25:33 AM, Chris Boscolo (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>>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> >> >> 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>) 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> >>> 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/> >>> *Identity Management | IT Governance | Information Security * >>> >>> >>> On Thu, Apr 12, 2018 at 10:08 AM, Adam >>> Powers<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>) 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> >>>> >>>> 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/> >>>> >>>> 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
Received on Friday, 13 April 2018 18:07:34 UTC