W3C | Submissions

Submission version:
https://www.w3.org/submissions/2015/02/
  1. https://www.w3.org/submissions/2015/SUBM-fido-web-api-20151120/ FIDO 2.0 Web API
  2. https://www.w3.org/submissions/2015/SUBM-fido-key-attestation-20151120/ FIDO 2.0 Key Attestation Format
  3. https://www.w3.org/submissions/2015/SUBM-fido-signature-format-20151120/ FIDO 2.0 Signature Format

Team Comment on the "FIDO 2.0 Platform Specifications 1.0" Submission

W3C is pleased to receive the FIDO 2.0 Platform Specifications submission from Microsoft, Google, PayPal, and NokNok Labs. The FIDO 2.0 Platform Specifications package consists of three specifications: FIDO 2.0 Web APIs, FIDO 2.0 Attestation Format, and FIDO 2.0 Signature Format. Together, these FIDO 2.0 specifications provide a means to perform strong authentication to a web site (the "relying party") using private key material held on an authenticator, ranging from private keys held on an external USB key to private key material held by the operating system.

In detail, the Web API for accessing FIDO 2.0 credentials allow the registration of an authenticator and authentication via the authenticator by Web applications, the Key Attestation Format provides cryptographic assurance to the relying party of the kind of authenticator in use (necessary for a "level of assurance"), and the Signature format provides proof of possession of the private key material held by the authenticator. FIDO 2.0 unifies and simplifies elements of the previously existing FIDO 1.0 UAF (Universal Authentication Framework) and U2F (Universal Second Factor) specifications.

Overall, the design of the specification is compatible with Web architecture. The key material used for authentication is scoped on a per-origin basis, thus helping to protect users' privacy. The level of abstraction over authenticators solves an outstanding practical problem, as with FIDO different kinds of authenticators ranging from key material based in the operating system to external smartcards can be discovered and registered to a relying party without device-specific Javascript code.

FIDO 2.0 works by signing a response to a challenge that proves possession of some registered authentication device with some private key material on it. The key format of FIDO allows both RSA and elliptic curve cryptography, and given that elliptic curve cryptography is in a state of flux, continued algorithm, key size, and curve parameter agility will continue to exist in tension with having algorithms be mandatory to implement. In terms of 'fingerprinting,' more work may be necessary to keep authentication compliant with local policy as well as to enable anonymity and personae (multiple authenticators for different accounts on the same site), although the use of blinding with Direct Anonymous Authentication provides a solid foundation. In detail, authenticator-specific endorsement keys endorsed by the Privacy CA and revocation of authenticators need wide review. Lastly, there needs to be detailed consideration on the interaction of FIDO with other parts of the larger Web eco-system via liaisons with other W3C and IETF Working Groups, in particular around the consistent use of identifiers and data formats in the Web Platform and FIDO's use in environments that could require deterministic signatures.

Related Work

There are alternative schemes for authentication being developed by W3C Community Groups. The WebID Community Group proposes the use of client certificates in its WebID+TLS specifications, but because it does not follow the same origin policy, WebID+TLS lets user identity be linked across otherwise-independent interactions unlike FIDO 2.0. Efforts at the IETF to improve HTTP-based authentication to take into account stronger cryptographic credentials at HTTP Authentication Working Group have progressed, but currently show no widespread adoption.

It is appreciated that FIDO focuses clearly on "killing passwords" via user authentication using cryptographic credentials. It should also enable two-factor authentication as it does not restrict the number of authenticators used or how they can be used in concert with other forms of authentication like passwords. However, FIDO 2.0 has a different level of abstraction than the existing W3C Web Crypto API as well as a distinct scope of work from that being discussed as Hardware-Based Security Working Group, so the future efforts around this submission can usefully proceed in parallel, but should not be merged.

Future Work

We congratulate FIDO participants on their hard work and thank them for submitting parts of the FIDO 2.0 specifications to W3C to develop open standards for the Web Platform. This submission is in scope of a charter in development for a Web Authentication Working Group.

Continuing discussion of this topic, including whether or not this particular authentication technology is ready for W3C standards-track work, is welcome via the Web Security Interest Group's public-web-security@w3.org [archive] and using Github at https://w3c.github.io/websec/web-authentication-charter.

Disclaimer: Publication of a Member Submission by W3C does not imply endorsement by W3C, including the W3C Team or Members, nor does it guarantee that a Working Group will agree to take any specific action on a Submission.

Harry Halpin <hhalpin@w3.org> and Wendy Seltzer <wseltzer@w3.org>