W3C home > Mailing lists > Public > public-credentials@w3.org > April 2018

Re: Question: WebAuthn announcement -- relation to DIDs?

From: Chris Boscolo <chris@boscolo.net>
Date: Fri, 13 Apr 2018 10:34:19 -0700
Message-ID: <CAByYRhb5ZuKiEqFDL4kZY_T=gqVJp3g3T=rKcP_vs-rnZk7Bhg@mail.gmail.com>
To: Adam Powers <adam@fidoalliance.org>
Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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.

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.

   -chrisb

On Fri, Apr 13, 2018 at 9:35 AM, Adam Powers <adam@fidoalliance.org> wrote:

>
> Answers inline below.
>
>
> On April 13, 2018 at 9:25:33 AM, Chris Boscolo (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 a per-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>
> 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_SZpqboIPfUa1lo9
>> zKtNv9SIv-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) 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
>> 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>
>> 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)
>>> 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
>>>
>>> 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/
>>>
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
>
Received on Friday, 13 April 2018 17:34:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:26 UTC