> That said, I think we're in violent agreement that the specs are far, far, > far from finished - and I'm unclear whether we're in agreement that one is > under active development, while the other is a technological dead end which, > through a series of unfortunate events, happened to have been launched beyond > the scope of a few limited sites.
Oh believe me, U2F is not ready to die. U2F is a great second factor solution, whatever ongoing FIDO 2 discussion. > > Are you following the Fido Alliance on going work? > > To an extent my sanity permits, yes. > > > Please focus on existing full specifications with existing services and > > products : FIDO U2F. > > The problem is that U2F represents a dead-end of sorts. It, along with FIDO > UAF, tried to provision high-level APIs for two very disjoint use cases. The > FIDO 2.0 work tries to embrace the extensiblewebmanifesto portion by > providing the common low-level primitives shared by UAF/U2F, so that > appropriate high level APIs can be built atop the low-level communication > mechanism. Perhaps when FIDO 2 will be reality, and it is far from being a reality, this discussion will make more sens. Why discouraging existing services and products support ? Perhaps FIDO U2F won't evolve a lot but it serves a purpose and reached its goal. FIDO 2 is also a very disjoint branch from UAF and U2F, and it seems to follow a strange way by promoting smartphone based application, marginalizing again the use of secure elements, unknown pairing, and so on... There are now many existing FIDO U2F solutions that are pushing for FIDO based solutions. Let's welcome Mozilla inside the Alliance and let Mozilla deal with existing actors, please... (insert a begging smiley here). > Yes, there are sites that support and use the U2F high-level API, and yes, > unfortunately Chrome ships a built-in extension that is automatically granted > sufficient privileges to polyfill that high-level API atop our > (extension-only) USB HID API, allowing the extension to inject into sites and > transparently add support 'as if' it was implemented through the standard > Chrome feature process, but unfortunately bypassing it, and thus suffering > many of the known issues with implementing and shipping specs before > consensus - such as ossification due to premature deployment. > > However, the U2F API inherently is something that will be replaced in the > future - it will presumably be supplanted with the FIDO 2.0 API low-level > primitives, for which there can then be 'many' high-level polyfill APIs > implemented through support libraries independent of the UA, perhaps 'some' > of which will be standardized, as such extensiblewebmanifesto-y things go. Wow, I won't follow you on this path :) If Google had strange ways to reach the goal, now it is working, and no, FIDO2 will not replace U2F. The second factor (authent after user+pass) is not even a part of FIDO 2. And compatibility is not even discussed. So if Mozilla waits (for an unknown period of time) and implements FIDO 2 (that will have its problems too...), this won't help people with their FIDO U2F based products and services. > This was captured by threads like > https://groups.google.com/a/fidoalliance.org/d/msg/fido-dev/zvS9BM8HXLQ/4GmJaSTTSN4J > and such. I know, I am the same Fred there :) > I think we'd also all agree that supporting a "U2F 1.0 API, U2F 1.1 API, UAF > 1.0 API, and FIDO 2.0 API" all within a browser is also... non-ideal. That's > why I was trying to get clarification about both the short- and long-term > commitments of the Firefox folks, while we try to get things clarified on the > Chrome side. Thanx for all the information, I hope you'll understand that we just want to enjoy the Mozilla announcement to support FIDO, please let them cover U2F. I don't see any kind of problem for them to cover FIDO 2 later when available and even support them side by side. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
