Intent to Implement: WebCrypto API extension for U2F

[Juan Lang]

Primary eng (and PM) emails

eng: juanlang@

PM: shah@

Spec

https://docs.google.com/a/chromium.org/document/d/1EEFAMIYNqZ7XHCntghD9meJwKgNOX7ZN-jl5LJQxOVQ/edit?usp=sharing

Summary

This feature adds support for FIDO Alliance (fidoalliance.org) "Universal 2nd Factor" (U2F) devices to the WebCrypto APIs.

Motivation

This API extension allows web sites to interact with U2F devices using a standard API.

Our current implementation relies on the externally_connectable feature of Chrome packaged apps to add U2F support to Chrome. Because of our OWP commitment, the externally_connectable feature requires that we explicitly whitelist each web origin that wants to support U2F devices, or that users install separate packaged apps for each origin. Because Chrome for Android doesn't support packaged apps, a different implementation was built for Android, and web site developers must be aware of and support both variants.

Compatibility Risk

Medium risk. On one hand, as a new algorithm within WebCrypto, we don't expect collisions with other WebCrypto implementations. On the other hand, we don't yet have commitment from any major browser vendor to implement this extension. To mitigate this latter risk, I'll note that Microsoft recently joined the FIDO Alliance, and we've at least discussed the feature with mozilla.

Ongoing technical constraints

None.

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

OWP launch tracking bug?

None yet.

Link to entry on the feature dashboard

None yet. I'll ask shah@ to create one.

[Adam Barth]

Have you proposed this extension to the W3C's Web Cryptography working group?

Adam

[Juan Lang]

Good point. No, only in private to the chair, Ryan Sleevi. I'll get a proposal lined up, thanks for the reminder.

--Juan

2014/1/27 Adam Barth <aba...@chromium.org>

[Adam Barth]

Thanks.  Acceptance by the working group doesn't block getting started on the implementation, but it's good to get that ball rolling because the working group participants are likely to have valuable feedback.

Adam

[rsl...@chromium.org]

I definitely think this should be brought to the Web Crypto WG. However, please note that the current work is focused on advancing the spec, and all forms of hardware-backed identities have been declared out of scope for current efforts.

The biggest concern here is introducing U2F-specific bits into the API. As discussed previously, and as conveyed by Mozilla, it would be much better to have a general API capable of signing various browser-attested assertions (such as the origin of the request - which in U2F terms is the "app id", as I understand it).

That is, the current sign API returns a signature as well as the browserData - the latter being fully generated by the UA. An alternate proposal, one that was suggested by Mozilla, is to have the signer request a number of fields that the browser can then fill in as appropriate as part of a signature.

For example,

window.crypto.subtle.sign({"name": "some_name_here", "trustedData": [ "url", "timestamp", "channel_id" ], "untrustedData": "foo"})

where the UA generates a signature over the following JSON-encoded object

{

  "url": "http://example.com/requesting_url",

  "timestamp": 1234567890,

  "channel_id": "<base-64 here>",

  "untrustedData": "foo"

}

This allows the relying parties (that is, those receiving the signature) to be able to trust the assertions, provided they trust the UA that generated them and the storage of the key - and allows a more robust set of claims than just U2F-specific APIs.

It would be good to understand the tradeoffs of a U2F-specific mechanism - which is not at all a generic signing scheme like those WebCrypto tries to provide - versus something that allows for browser-backed assertions in a generic way.

Cheers,

[Juan Lang]

Thanks Ryan.

2014-01-28 10:28 GMT-08:00 <rsl...@chromium.org>:

On Monday, January 27, 2014 5:24:47 PM UTC-8, Juan Lang wrote:

Primary eng (and PM) emails

eng: juanlang@

PM: shah@

Spec

https://docs.google.com/a/chromium.org/document/d/1EEFAMIYNqZ7XHCntghD9meJwKgNOX7ZN-jl5LJQxOVQ/edit?usp=sharing

Summary

This feature adds support for FIDO Alliance (fidoalliance.org) "Universal 2nd Factor" (U2F) devices to the WebCrypto APIs.

Motivation

This API extension allows web sites to interact with U2F devices using a standard API.

Our current implementation relies on the externally_connectable feature of Chrome packaged apps to add U2F support to Chrome. Because of our OWP commitment, the externally_connectable feature requires that we explicitly whitelist each web origin that wants to support U2F devices, or that users install separate packaged apps for each origin. Because Chrome for Android doesn't support packaged apps, a different implementation was built for Android, and web site developers must be aware of and support both variants.

Compatibility Risk

Medium risk. On one hand, as a new algorithm within WebCrypto, we don't expect collisions with other WebCrypto implementations. On the other hand, we don't yet have commitment from any major browser vendor to implement this extension. To mitigate this latter risk, I'll note that Microsoft recently joined the FIDO Alliance, and we've at least discussed the feature with mozilla.

Ongoing technical constraints

None.

Is this feature supported on all five Blink platforms (Windows, Mac, Linux, Chrome OS and Android)?

Yes.

OWP launch tracking bug?

None yet.

Link to entry on the feature dashboard

None yet. I'll ask shah@ to create one.

I definitely think this should be brought to the Web Crypto WG. However, please note that the current work is focused on advancing the spec, and all forms of hardware-backed identities have been declared out of scope for current efforts.

Indeed. As you saw, I did send the proposal to the WG. So far I haven't received all that much actionable feedback in the doc or to my email there. At what point may I assume it's safe to proceed?

 

The biggest concern here is introducing U2F-specific bits into the API. As discussed previously, and as conveyed by Mozilla, it would be much better to have a general API capable of signing various browser-attested assertions (such as the origin of the request - which in U2F terms is the "app id", as I understand it).

That is, the current sign API returns a signature as well as the browserData - the latter being fully generated by the UA. An alternate proposal, one that was suggested by Mozilla, is to have the signer request a number of fields that the browser can then fill in as appropriate as part of a signature.

For example,

window.crypto.subtle.sign({"name": "some_name_here", "trustedData": [ "url", "timestamp", "channel_id" ], "untrustedData": "foo"})

where the UA generates a signature over the following JSON-encoded object

{

  "url": "http://example.com/requesting_url",

  "timestamp": 1234567890,

  "channel_id": "<base-64 here>",

  "untrustedData": "foo"

}

This allows the relying parties (that is, those receiving the signature) to be able to trust the assertions, provided they trust the UA that generated them and the storage of the key - and allows a more robust set of claims than just U2F-specific APIs.

This is an interesting suggestion, and one we had considered. We didn't propose such a mechanism because it would require modifying the sign semantics, and worried that this would delay the effort considerably. For example, the approach you propose does not trivially map to the existing implementation of sign when no trustedData are specified. But perhaps this conversation would be better at the WebCrypto mailing list, rather than here?

Thanks,

--Juan

[Ryan Sleevi]

Considering that

- The WG has explicitly stated via charter that such tokens are out of scope

- The editors (*cough* hi *cough*) and the WG are focusing on getting the spec in a form suitable for last call

It's not surprising that you didn't get much reaction. I don't know what you wish for regarding "safe". I defer to API OWNERS on the overall process for http://www.chromium.org/blink#launch-process , in particular when it regards prototyping a new feature.

My only advice is that this should be behind a flag and should not be Shipped until the WG has adopted it or there is strong consensus from other vendors on this. Although I'd much rather see the WG adopt it.

 

 

The biggest concern here is introducing U2F-specific bits into the API. As discussed previously, and as conveyed by Mozilla, it would be much better to have a general API capable of signing various browser-attested assertions (such as the origin of the request - which in U2F terms is the "app id", as I understand it).

That is, the current sign API returns a signature as well as the browserData - the latter being fully generated by the UA. An alternate proposal, one that was suggested by Mozilla, is to have the signer request a number of fields that the browser can then fill in as appropriate as part of a signature.

For example,

window.crypto.subtle.sign({"name": "some_name_here", "trustedData": [ "url", "timestamp", "channel_id" ], "untrustedData": "foo"})

where the UA generates a signature over the following JSON-encoded object

{

  "url": "http://example.com/requesting_url",

  "timestamp": 1234567890,

  "channel_id": "<base-64 here>",

  "untrustedData": "foo"

}

This allows the relying parties (that is, those receiving the signature) to be able to trust the assertions, provided they trust the UA that generated them and the storage of the key - and allows a more robust set of claims than just U2F-specific APIs.

This is an interesting suggestion, and one we had considered. We didn't propose such a mechanism because it would require modifying the sign semantics, and worried that this would delay the effort considerably. For example, the approach you propose does not trivially map to the existing implementation of sign when no trustedData are specified. But perhaps this conversation would be better at the WebCrypto mailing list, rather than here?

Thanks,

--Juan

I do not follow your concerns here as to how it would modify sign semantics.

I think the general conversation about how to sign browser-supplied data in an unspoofable manner (eg: where the UA contributes origin or other security assertions - like channel ID, timestamps, or the like) can and should happen in the WG.

However, I do not expect there will be significant progress or discussion of that due to the current focus of the WG to advancing the spec maturity.

As such, it seems like it would be "best" to work on an implementation behind a flag (and not the general WebCrypto flag) to develop and prove the concept, as well as gain implementation experience that may be used to inform the broader WebCrypto WG.

[Adam Barth]

Based on this discussion, it sounds like this feature isn't on a great standards trajectory.  If we're serious about this feature, we going to need to invest more in standardizing it.

If there are implementation risks you're worried about, would it make sense to start off with an experimental implementation on a branch?  That approach can be useful if there are specific implementation questions you would like to answer.

If you need help navigating the standards world, we have a number of experienced folks on the team who can help.  I worry that if we start implementing this feature now, we'll get invested in the implementation and be unable to ship it because the standards track will be so far behind.

Adam

On Thursday, February 13, 2014, Ryan Sleevi <rsl...@chromium.org> wrote:

On Thu, Feb 13, 2014 at 10:29 AM, Juan Lang <juan...@chromium.org> wrote:

Thanks Ryan.

2014-01-28 10:28 GMT-08:00 <rsl...@chromium.org>:

On Monday, January 27, 2014 5:24:47 PM UTC-8, Juan Lang wrote:

Primary eng (and PM) emails

eng: juanlang@

PM: shah@

Spec

https://docs.google.com/a/chromium.org/document/d/1EEFAMIYNqZ7XHCntghD9meJwKgNOX7ZN-jl5LJQxOVQ/edit?usp=sharing

Summary

This feature adds support for FIDO Alliance (fidoalliance.org) "Universal 2nd Factor" (U2F) devices to the WebCrypto APIs.

Motivation

This API extension allows web sites to interact with U2F devices using a standard API.

Our current implementation relies on the externally_connectable feature of Chrome packaged apps to add U2F support to Chrome. Because of our OWP commitment, the externally_connectable feature requires that we explicitly whitelist each web origin that wants to support U2F devices, or that users install separate packaged apps for each origin. Because Chrome for Android doesn't support packaged apps, a different implementation was built for Android, and web site developers must be aware of and support both variants.

Compatibility Risk

Medium risk. On one hand, as a new algorithm within WebCrypto, we d

Considering that

- The WG has explicitly stated via charter that such tokens are out of scope

- The editors (*cough* hi *cough*) and the WG are focusing on getting the spec in a form suitable for last call

It's not surprising that you didn't get much reaction. I don't know what you wish for regarding "safe". I defer to API OWNERS on the overall process for http://www.chromium.org/blink#launch-process , in particular when it regards prototyping a new feature.

My only advice is that this should be behind a flag and should not be Shipped until the WG has adopted it or there is strong consensus from other vendors on this. Although I'd much rather see the WG adopt it.

 

 

The biggest concern here is introducing U2F-specific bits into the API. As discussed previously, and as conveyed by Mozilla, it would be much better to have a general API capable of signing various browser-attested assertions (such as the origin of the request - which in U2F terms is the "app id", as I understand it).

That is, the current sign API returns a signature as well as the browserData - the latter being fully generated by the UA. An alternate proposal, one that was suggested by Mozilla, is to have the signer request a number of fields that the browser can then fill in as appropriate as part of a signature.

For example,

window.crypto.subtle.sign({"name": "some_name_here", "trustedData": [ "url", "timestamp", "channel_id" ], "untrustedData": "foo"})

where the UA generates a signature over the following JSON-encoded object

{

  "url": "http://example.com/requesting_url",

  "timestamp": 1234567890,

  "channel_id": "<base-64 here>",

  "untrustedData": "foo"

}

This allows the relying parties (that is, those receiving the signature) to be able to trust the assertions, provided they trust the UA that generated them and the storage of the key - and allows a more robust set of claims than just U2F-specific APIs.

This is an interesting suggestion, and one we had considered. We didn't propose such a mechanism because it would require modifying the sign semantics, and worried that this would delay the effort considerably. For example, the approach you propose does not trivially map to the existing implementation of sign when no trustedData are specified. But perhaps this conversation would be better at the WebCrypto mailing list, rather than here?

Thanks,

--Juan

[Juan Lang]

2014-02-14 10:04 GMT-08:00 Adam Barth <aba...@chromium.org>:

Based on this discussion, it sounds like this feature isn't on a great standards trajectory.  If we're serious about this feature, we going to need to invest more in standardizing it.

Could you elaborate, please? I think Ryan's saying he doesn't have time for this feature right now, and of course I respect that. He also suggested that the Mozilla folks might have some feedback. Since they haven't given it, I'll try reaching out to them individually. But I believe I'm demonstrating my commitment to standardizing this feature, so if there's a particular concern here I haven't addressed, I'd like to hear it.

If there are implementation risks you're worried about, would it make sense to start off with an experimental implementation on a branch?  That approach can be useful if there are specific implementation questions you would like to answer.

I'm not particularly concerned about the implementation at this stage. I've already begun a branch. I was pinging this thread because it wasn't clear to me whether I should solicit additional feedback prior to continuing this work. http://www.chromium.org/blink#TOC-Web-Platform-Changes:-Process describes sending an intent to implement, which I did. You and Ryan both suggested I should send a proposal to the WebCrypto WG, which I also did. Now I intend to proceed, unless there's good reason not to.

--Juan

[Adam Barth]

Ok.  You're welcome to ignore my feedback and push forward.  The risk you're taking is that you'll get invested in an implementation that will need to change substantially before we're able to ship it.

Adam

[Juan Lang]

I think your feedback was that I need to work more on standardizing it, and I think I'm doing that? Thanks for taking the time to reply.

--Juan