- From: Steven Rowat <steven_rowat@sunshine.net>
- Date: Fri, 13 Apr 2018 10:03:30 -0700
- To: Adam Powers <adam@fidoalliance.org>, Stephen Curran <swcurran@cloudcompass.ca>
- Cc: Andrew Hughes <andrewhughes3000@gmail.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
On 2018-04-13 9:21 AM, Adam Powers wrote: > My understanding* is that pairwise DIDs is a feature of Sovrin, but > potentially not a feature of other systems. If it does turn out that > "all DIDs are pairwise" is a valid assumption, the "origin issue" may > be a non-issue. > > * - I'm new to DID and looking for education. This is largely me > repeating from what I've heard about people that are more educated > about DID. IMO your first understanding is right that other DID Methods than Sovrin's can be set up differently, and so I don't think "all DIDs are pairwise" is a valid assumption. I get this from the active spec section on DID Documents, section 4 of: https://w3c-ccg.github.io/did-spec/ There Section 4.6 describes "service endpoints" as only one possible function of the DID Document, which can exist on its own to specify the existence of an entity -- thing, person, company -- without tying it to a specific service. Steven Rowat > > > > On April 13, 2018 at 9:13:21 AM, Stephen Curran > (swcurran@cloudcompass.ca <mailto:swcurran@cloudcompass.ca>) wrote: > >> This is really encouraging to see, and from what I can tell would be >> huge if/when WebAuthn and DIDs can be combined. >> >> I'm confused on the origin issue as you frame it. I believe that >> most DID implementations plan to use pairwise DIDs between an entity >> (person, organization, etc.) and a service. So a user logging in >> would have a DID per service, and would not (as you show in your >> slides) be selecting which existing DID to use, but would use the >> one specifically created for this relationship. >> >> Is the origin issue different from that? Or better, has someone >> with sufficient knowledge of both documented somewhere the nature of >> the DID-WebAuthn gap? >> >> >> >> 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 >>> 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 >>>> >>>> >>>> >>>> >>>> >>> >> >> >> >> -- >> >> Stephen Curran >> Cloud Compass Computing, Inc. (C3I) >> >> /Cell: (250) 857-1096/ >>
Received on Friday, 13 April 2018 17:03:48 UTC