Re: [webkit-dev] Implementing Universal Second Factor (U2F)

[Jacob Greenfield]

In that case, I agree that it does not make much sense to implement the FIDO 
U2F API.

I would definitely be interested in working on Web Authentication for WebKit. 
Rick - I think collaborating with people working on Chromium and Edge would be 
great.

Thanks!

- Jacob Greenfield

> On Feb 22, 2017, at 18:13, Rick Byers  wrote:
> 
> As I understand, there's active development going on in both chromium and 
> Edge for Web Authentication right now.  I'm sure those folks would love to 
> collaborate with someone working in WebKit (and I'm happy to make 
> introductions).
> 
>> On Wed, Feb 22, 2017 at 6:08 PM, Sam Weinig  wrote:
>> 
>>> On Feb 22, 2017, at 1:22 PM, Ryosuke Niwa  wrote:
>>> 
 On Wed, Feb 22, 2017 at 12:56 PM, Rick Byers  wrote:
 Chrome ships with a built-in extension that exposes the high-level API 
 (which I think we all agree is a hack).  We recently had this discussion 
 about the right path forward here, and agreed that we should instead focus 
 our efforts on the Web Authentication API instead, since it seemed much 
 more likely to be something that would become interoperable between 
 browsers.
>>> 
>>> Boris's comment in the referenced thread makes me think that we should just 
>>> implement https://w3c.github.io/webauthn/ if any:
>>> 
 1) [Gecko/Firefox] have an implementation of the FIDO U2F API behind a 
 pref so people 
 can experiment with it. 
 2) [Gecko/Firefox] plan to ship the API being developed at 
 https://w3c.github.io/webauthn/ once it stabilizes. 
 > 3) [Gecko/Firefox] have no plans to ship the FIDO U2F API, now or in the 
 > future. 
>>> 
>>> As such, I don't think we should be implementing FIDO U2F API on trunk.
>>> 
>>> - R. Niwa
>>> 
>> 
>> Given that data, I agree with Ryosuke, and adding an implementing of the 
>> FIDO U2F API doesn’t seem like a great fit for WebKit.
>> 
>> That said, Jacob, do you have any interest in working on an implementation 
>> of the Web Authentication specification?
>> 
>> - Sam
>>  
> 
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

[Rick Byers]

As I understand, there's active development going on in both chromium and
Edge for Web Authentication right now.  I'm sure those folks would love to
collaborate with someone working in WebKit (and I'm happy to make
introductions).

On Wed, Feb 22, 2017 at 6:08 PM, Sam Weinig  wrote:

>
> On Feb 22, 2017, at 1:22 PM, Ryosuke Niwa  wrote:
>
> On Wed, Feb 22, 2017 at 12:56 PM, Rick Byers  wrote:
>
>> Chrome ships with a built-in extension that exposes the high-level API
>> (which I think we all agree is a hack).  We recently had this discussion
>> 
>> about the right path forward here, and agreed that we should instead focus
>> our efforts
>> 
>> on the Web Authentication API  instead,
>> since it seemed much more likely to be something that would become
>> interoperable between browsers.
>>
>
> Boris's comment in the referenced thread makes me think that we should
> just implement https://w3c.github.io/webauthn/ if any:
>
> 1) [Gecko/Firefox] have an implementation of the FIDO U2F API behind a
>> pref so people
>> can experiment with it.
>> 2) [Gecko/Firefox] plan to ship the API being developed at
>> https://w3c.github.io/webauthn/ once it stabilizes.
>> > 3) [Gecko/Firefox] have no plans to ship the FIDO U2F API, now or in
>> the future.
>
>
> As such, I don't think we should be implementing FIDO U2F API on trunk.
>
> - R. Niwa
>
>
> Given that data, I agree with Ryosuke, and adding an implementing of the
> FIDO U2F API doesn’t seem like a great fit for WebKit.
>
> That said, Jacob, do you have any interest in working on an implementation
> of the Web Authentication specification?
>
> - Sam
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

[Sam Weinig]

> On Feb 22, 2017, at 1:22 PM, Ryosuke Niwa  wrote:
> 
> On Wed, Feb 22, 2017 at 12:56 PM, Rick Byers  > wrote:
> Chrome ships with a built-in extension that exposes the high-level API (which 
> I think we all agree is a hack).  We recently had this discussion 
> 
>  about the right path forward here, and agreed that we should instead focus 
> our efforts 
> 
>  on the Web Authentication API  instead, 
> since it seemed much more likely to be something that would become 
> interoperable between browsers.
> 
> Boris's comment in the referenced thread makes me think that we should just 
> implement https://w3c.github.io/webauthn/  
> if any:
> 
> 1) [Gecko/Firefox] have an implementation of the FIDO U2F API behind a pref 
> so people 
> can experiment with it. 
> 2) [Gecko/Firefox] plan to ship the API being developed at 
> https://w3c.github.io/webauthn/  once it 
> stabilizes. 
> > 3) [Gecko/Firefox] have no plans to ship the FIDO U2F API, now or in the 
> > future. 
> 
> As such, I don't think we should be implementing FIDO U2F API on trunk.
> 
> - R. Niwa
> 

Given that data, I agree with Ryosuke, and adding an implementing of the FIDO 
U2F API doesn’t seem like a great fit for WebKit.

That said, Jacob, do you have any interest in working on an implementation of 
the Web Authentication specification?

- Sam
 ___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

[Ryosuke Niwa]

On Wed, Feb 22, 2017 at 12:56 PM, Rick Byers  wrote:

> Chrome ships with a built-in extension that exposes the high-level API
> (which I think we all agree is a hack).  We recently had this discussion
> 
> about the right path forward here, and agreed that we should instead focus
> our efforts
> 
> on the Web Authentication API  instead,
> since it seemed much more likely to be something that would become
> interoperable between browsers.
>

Boris's comment in the referenced thread makes me think that we should just
implement https://w3c.github.io/webauthn/ if any:

1) [Gecko/Firefox] have an implementation of the FIDO U2F API behind a pref
> so people
> can experiment with it.
> 2) [Gecko/Firefox] plan to ship the API being developed at
> https://w3c.github.io/webauthn/ once it stabilizes.
> > 3) [Gecko/Firefox] have no plans to ship the FIDO U2F API, now or in
> the future.


As such, I don't think we should be implementing FIDO U2F API on trunk.

- R. Niwa
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

[Rick Byers]

Chrome ships with a built-in extension that exposes the high-level API
(which I think we all agree is a hack).  We recently had this discussion

about the right path forward here, and agreed that we should instead focus
our efforts

on the Web Authentication API  instead,
since it seemed much more likely to be something that would become
interoperable between browsers.



On Wed, Feb 22, 2017 at 3:46 PM, Sam Weinig  wrote:

>
> On Feb 22, 2017, at 5:52 AM, Jacob Greenfield  wrote:
>
> I’m working on adding support to WebKit for FIDO U2F (JS API:
> https://fidoalliance.org/specs/fido-u2f-v1.1-id-
> 20160915/fido-u2f-javascript-api-v1.1-id-20160915.html Architecture
> overview: https://fidoalliance.org/specs/fido-u2f-v1.1-id-
> 20160915/fido-u2f-overview-v1.1-id-20160915.html ). The FIDO U2F
> specification allows a secure second factor to be used during
> authentication flow, with bidirectional verification (token verifies
> server, server verifies token and token’s knowledge of a specific private
> key). There are current implementations in Chrome, Opera, and Blink
> (Firefox). I’m primarily interested in bringing support to Safari, so that
> is the focus what I am currently working on.
>
>
> Hi Jacob, and welcome to WebKit.
>
> I went looking for how to use the feature in Chrome and Firefox (I assume
> you meant Gecko (Firefox), not Blink (Firefox)) I’m a little confused as to
> how this feature is exposed in the other browsers.  On the topic of the
> low-level MessagePort API, section 3 states “This specification does not
> describe how such a port is made available to RP web pages, as this is (for
> now) implementation and browser dependent” (https://fidoalliance.org/
> specs/fido-u2f-v1.1-id-20160915/fido-u2f-javascript-
> api-v1.1-id-20160915.html#api-levels).  Similarly, for the high-level
> API, it states in section 3.2, “Implementations may choose how to make such
> an API available to RP web pages. If such an API is provided,
> it should provide a namespace object u2f of the following interface" (
> https://fidoalliance.org/specs/fido-u2f-v1.1-id-
> 20160915/fido-u2f-javascript-api-v1.1-id-20160915.html#
> high-level-javascript-api).
>
> Do you have insight into how either of these APIs are exposed in other
> browsers? How do you plan on exposing them in WebKit?
>
> I should say, generally, I am concerned with APIs that leave important
> details like how the APIs are exposed to the implementation, as they lead
> to non-interoperable implementations.
>
> Thanks,
> - Sam
>
>
> ___
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

[Sam Weinig]

> On Feb 22, 2017, at 5:52 AM, Jacob Greenfield  wrote:
> 
> I’m working on adding support to WebKit for FIDO U2F (JS API: 
> https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-javascript-api-v1.1-id-20160915.html
>  Architecture overview: 
> https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-overview-v1.1-id-20160915.html
>  ). The FIDO U2F specification allows a secure second factor to be used 
> during authentication flow, with bidirectional verification (token verifies 
> server, server verifies token and token’s knowledge of a specific private 
> key). There are current implementations in Chrome, Opera, and Blink 
> (Firefox). I’m primarily interested in bringing support to Safari, so that is 
> the focus what I am currently working on.

Hi Jacob, and welcome to WebKit.

I went looking for how to use the feature in Chrome and Firefox (I assume you 
meant Gecko (Firefox), not Blink (Firefox)) I’m a little confused as to how 
this feature is exposed in the other browsers.  On the topic of the low-level 
MessagePort API, section 3 states “This specification does not describe how 
such a port is made available to RP web pages, as this is (for now) 
implementation and browser dependent” 
(https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-javascript-api-v1.1-id-20160915.html#api-levels
 
).
  Similarly, for the high-level API, it states in section 3.2, “Implementations 
may choose how to make such an API available to RP web pages. If such an API is 
provided, it should provide a namespace object u2f of the following interface" 
(https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-javascript-api-v1.1-id-20160915.html#high-level-javascript-api
 
).

Do you have insight into how either of these APIs are exposed in other 
browsers? How do you plan on exposing them in WebKit?

I should say, generally, I am concerned with APIs that leave important details 
like how the APIs are exposed to the implementation, as they lead to 
non-interoperable implementations. 

Thanks,
- Sam

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

[Michael Catanzaro]

On Wed, 2017-02-22 at 12:20 -0500, Jacob Greenfield wrote:
> Michael,
> 
> Thanks for the info. After looking into things a bit more - let me
> know if this does not make sense - it looks like it may be better to
> reimplement for WebKit.

OK, your explanation sounds reasonable to me.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

[Jacob Greenfield]

Michael,

Thanks for the info. After looking into things a bit more - let me know if this 
does not make sense - it looks like it may be better to reimplement for WebKit.

Specifically, it looks like hidapi does some opaque stuff with threading that 
may leave idle threads around, to expose a consistent API across platforms. 

The other reason (and an area I haven't explored much yet) is that much of the 
code in libu2f-host doesn't seem to be concerned with the protocol itself, but 
with other details of the protocol - stuff that WebKit already has; the biggest 
two I see are (and it looks like another dependency on JSON-C here) formatting 
browser responses and base64 encoding.

On a cursory glance at their code for reading a response from the device, it 
looks like 2 threads will have to be spawned: one to allow libu2f-host to block 
(it calls sleep if the device isn't ready) on a response from hidapi, and one 
for hidapi to monitor the device.

It looks like doing a clean implementation for Linux should also not be too 
hard; I think it would be okay to only enable it if hidraw is available, which 
should be the case now on most shipping kernels for desktop distros.

The Windows API also seems to have some HID stuff; I can look into this if any 
ports which would enable this feature want Windows support.

- Jacob Greenfield

> On Feb 22, 2017, at 10:17, Michael Catanzaro  wrote:
> 
>> On Wed, 2017-02-22 at 08:52 -0500, Jacob Greenfield wrote:
>> The (USB) protocol itself works by sending USB HID reports (packets)
>> to the key and getting USB HID reports back. There is a reference
>> implementation by one of the members of the specification group -
>> libu2f-host (by Yubico); however, it is licensed under GPL and
>> LGPLv2.1.
> 
> Hi,
> 
> According to the documentation:
> 
> "The library and command-ine tool is licensed under the LGPLv2+
> license. Some other files are licensed under the GPLv3+ license."
> 
> Sounds like a perfectly acceptable dependency for WebKit. The only
> trick is that if you need to import the source code under
> Source/ThirdParty (hopefully not), then you'd need to remove all the
> GPLv3+ files from the repository.
> 
>> - What to do about other platforms - no implementation, use libu2f-
>> host for them, or use libu2f-host everywhere
> 
> Ideally we would use the same code on all platforms unless there is a
> strong reason not to do so, to reduce the amount of platform-specific
> bugs. I'm not sure if there exists such a situation here, so using
> libu2f-host on all platforms seems to make the most sense. Possible
> examples of strong reasons to diverge:
> 
> * If removing the GPLv3+ files would be somehow problematic. GTK+ port
> doesn't care so long as none of the GPL files are used by the library
> itself. Apple is much stricter; I guess they might not allow the files
> to be imported into internal build systems. That could create a
> maintenance headache.
> * If the extra dependencies are problematic for some platform. You'd
> be hard-pressed to find a Linux system without libusb, and hidapi and
> libu2f-host both look unproblematic. But adding your implementation
> directly to WebKit might be easier for Mac ports.
> 
>> - UI for key access permission - malicious sites could (eventually)
>> lock up a key, as well as possibly identifying a user; the
>> specification suggests displaying an info bar for user to allow
>> access - but, I’m not familiar with the process of designing/adding
>> browser chromes
> 
> Sounds like WebKit should request a policy decision from the client on
> whether to allow a website to use the U2F API? Then making that
> decision in a secure manner is the responsibility of the client to
> figure out. In Epiphany we display info bars the first time a
> particular security origin requests a permission, and remember the
> user's choice in the future.
> 
>> - What process should communicate with the token - the protocol is
>> robust and designed for many simultaneous accesses and appropriate
>> isolation of them, so this can (should?) be per-page; IOKit needs a
>> CFRunLoop to schedule the report receive callback on: should this be
>> on the main runloop or on another thread just for U2F?
> 
> I don't know which process, but you should use the main runloop. Let's
> avoid creating a new always-running thread for a feature that will
> rarely be used.
> 
>> - Presumably, this should be gated behind a macro; does a suitable
>> one exist, or add a new one?
> 
> You'll have to add a new one, ENABLE_U2F. It's better not to gate
> features when possible, but in this case one will be required due to
> the new dependencies as we want to allow distributions that do not have
> the new dependencies to continue to build without them (with reduced
> feature set) for the next few years.
> 
> Michael

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Implementing Universal Second Factor (U2F)

[Michael Catanzaro]

On Wed, 2017-02-22 at 08:52 -0500, Jacob Greenfield wrote:
> The (USB) protocol itself works by sending USB HID reports (packets)
> to the key and getting USB HID reports back. There is a reference
> implementation by one of the members of the specification group -
> libu2f-host (by Yubico); however, it is licensed under GPL and
> LGPLv2.1.

Hi,

According to the documentation:

"The library and command-ine tool is licensed under the LGPLv2+
license. Some other files are licensed under the GPLv3+ license."

Sounds like a perfectly acceptable dependency for WebKit. The only
trick is that if you need to import the source code under
Source/ThirdParty (hopefully not), then you'd need to remove all the
GPLv3+ files from the repository.

> - What to do about other platforms - no implementation, use libu2f-
> host for them, or use libu2f-host everywhere

Ideally we would use the same code on all platforms unless there is a
strong reason not to do so, to reduce the amount of platform-specific
bugs. I'm not sure if there exists such a situation here, so using
libu2f-host on all platforms seems to make the most sense. Possible
examples of strong reasons to diverge:

 * If removing the GPLv3+ files would be somehow problematic. GTK+ port
doesn't care so long as none of the GPL files are used by the library
itself. Apple is much stricter; I guess they might not allow the files
to be imported into internal build systems. That could create a
maintenance headache.
 * If the extra dependencies are problematic for some platform. You'd
be hard-pressed to find a Linux system without libusb, and hidapi and
libu2f-host both look unproblematic. But adding your implementation
directly to WebKit might be easier for Mac ports.

> - UI for key access permission - malicious sites could (eventually)
> lock up a key, as well as possibly identifying a user; the
> specification suggests displaying an info bar for user to allow
> access - but, I’m not familiar with the process of designing/adding
> browser chromes

Sounds like WebKit should request a policy decision from the client on
whether to allow a website to use the U2F API? Then making that
decision in a secure manner is the responsibility of the client to
figure out. In Epiphany we display info bars the first time a
particular security origin requests a permission, and remember the
user's choice in the future.

> - What process should communicate with the token - the protocol is
> robust and designed for many simultaneous accesses and appropriate
> isolation of them, so this can (should?) be per-page; IOKit needs a
> CFRunLoop to schedule the report receive callback on: should this be
> on the main runloop or on another thread just for U2F?

I don't know which process, but you should use the main runloop. Let's
avoid creating a new always-running thread for a feature that will
rarely be used.

> - Presumably, this should be gated behind a macro; does a suitable
> one exist, or add a new one?

You'll have to add a new one, ENABLE_U2F. It's better not to gate
features when possible, but in this case one will be required due to
the new dependencies as we want to allow distributions that do not have
the new dependencies to continue to build without them (with reduced
feature set) for the next few years.

Michael
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Implementing Universal Second Factor (U2F)

[Jacob Greenfield]

I’m working on adding support to WebKit for FIDO U2F (JS API: 
https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-javascript-api-v1.1-id-20160915.html
 Architecture overview: 
https://fidoalliance.org/specs/fido-u2f-v1.1-id-20160915/fido-u2f-overview-v1.1-id-20160915.html
 ). The FIDO U2F specification allows a secure second factor to be used during 
authentication flow, with bidirectional verification (token verifies server, 
server verifies token and token’s knowledge of a specific private key). There 
are current implementations in Chrome, Opera, and Blink (Firefox). I’m 
primarily interested in bringing support to Safari, so that is the focus what I 
am currently working on.

The (USB) protocol itself works by sending USB HID reports (packets) to the key 
and getting USB HID reports back. There is a reference implementation by one of 
the members of the specification group - libu2f-host (by Yubico); however, it 
is licensed under GPL and LGPLv2.1. It also depends on two more libraries, 
hidapi and libusb. Figuring that adding all of these dependencies to Safari 
might be undesirable, I wrote a clean-room implementation outside of WebKit 
that uses IOKit directly to access the device (conveniently, IOKit exposes nice 
HID stuff). I’m now at the stage of adding this to WebKit.

Before I move forward, there are a couple of things that would be great to get 
some input on:

- What to do about other platforms - no implementation, use libu2f-host for 
them, or use libu2f-host everywhere
- UI for key access permission - malicious sites could (eventually) lock up a 
key, as well as possibly identifying a user; the specification suggests 
displaying an info bar for user to allow access - but, I’m not familiar with 
the process of designing/adding browser chromes
- What process should communicate with the token - the protocol is robust and 
designed for many simultaneous accesses and appropriate isolation of them, so 
this can (should?) be per-page; IOKit needs a CFRunLoop to schedule the report 
receive callback on: should this be on the main runloop or on another thread 
just for U2F?
- Presumably, this should be gated behind a macro; does a suitable one exist, 
or add a new one?

Thank you!

- Jacob Greenfield
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev