Primary eng (and PM) emails
eng: juanlang@
PM: shah@
Spec
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.
On Monday, January 27, 2014 5:24:47 PM UTC-8, Juan Lang wrote:Primary eng (and PM) emails
eng: juanlang@
PM: shah@
Spec
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.
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.
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
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
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 callIt'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
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.