- From: Philippe Le Hégaret <plh@w3.org>
- Date: Fri, 11 Jan 2019 15:04:42 -0500
- To: Ralph Swick <swick@w3.org>, John Fontana <jfontana@yubico.com>, W3C Comm Team <w3t-comm@w3.org>, chairs@w3.org
- Cc: Tim Berners-Lee <timbl@w3.org>, W3C Web Authn WG <public-webauthn@w3.org>, Anthony Nadalin <tonynad@microsoft.com>, Samuel Weiler <weiler@w3.org>, Wendy Seltzer <wseltzer@w3.org>, Yuriy Ackermann <yuriy@fidoalliance.org>
On 9/26/2018 12:54 PM, Ralph Swick wrote: > > > On 2018-09-21 05:21 PM, John Fontana wrote: >> *# Document title, URLs, estimated publication date* >> >> *Title:* Web Authentication: An API for accessing Public Key >> Credentials Level 1 >> >> *URL*:https://www.w3.org/TR/2017/WD-webauthn-20170811/ >> <https://www.w3.org/TR/2017/WD-webauthn-20170811/> > > I believe you meant > > https://www.w3.org/TR/2018/CR-webauthn-20180807/ yes >> *Publication date:* 25 September 2018 >> >> *Last Published:* >> https://www.w3.org/TR/webauthn/ <https://www.w3.org/TR/webauthn/> >> >> *Latest Editor’s Draft:* >> https://w3c.github.io/webauthn/ <https://w3c.github.io/webauthn/> >> >> *# Abstract* >> This specification defines an API enabling the creation and use of >> strong, attested, scoped, public key-based credentials by web >> applications, for the purpose of strongly authenticating users. > > (there's more in the CR abstract, with some edits in the ED abstract) Should read [[ This specification defines an API enabling the creation and use of strong, attested, scoped, public key-based credentials by web applications, for the purpose of strongly authenticating users. Conceptually, one or more public key credentials, each scoped to a given WebAuthn Relying Party, are created by and bound to authenticators as requested by the web application. The user agent mediates access to authenticators and their public key credentials in order to preserve user privacy. Authenticators are responsible for ensuring that no operation is performed without user consent. Authenticators provide cryptographic proof of their properties to Relying Parties via attestation. This specification also describes the functional model for WebAuthn conformant authenticators, including their signature and attestation functionality. ]] >> *# Status* >> https://www.w3.org/TR/webauthn/ <https://www.w3.org/TR/webauthn/> >> >> *# Comments* >> Send comments to:public-webauthn@w3.org <mailto:public-webauthn@w3.org> >> Feedback is due 02 October 2018 >> [Or 7 days from day Request is approved] >> >> *# Link to group's decision to request transition* >> Call for Consensus: >> https://lists.w3.org/Archives/Public/public-webauthn/2018Sep/0043.html >> <https://lists.w3.org/Archives/Public/public-webauthn/2018Sep/0043.html> > > There's a question from Giri about the extensions in > > https://lists.w3.org/Archives/Public/public-webauthn/2018Sep/0046.html > > for which I don't see an explicit answer in the mail archive. Looking > at the diff between the CR and the ED I observe the following change in > Section 10: > > These /-are RECOMMENDED for implementation-/ /+can be implemented+/ > by user agents targeting broad interoperability. > > At a minimum this would be more clear if it used the RFC 2119 > terminology "These MAY be implemented ...". > > However this is still unclear; my understanding is that the Group's > intent is that optional features, if implemented, must conform to the > specification. Therefore it is still necessary to state which parts, if > any, of the extension specifications do not have sufficient > implementation evidence and therefore would be dropped or made informative. The extensions are normative but optional. > Where is the evidence for interoperable implementation of these extensions? With the help of FIDO Alliance, I produce the following document indicating extension implementation status as tested by the FIDO Alliance: https://www.w3.org/2019/01/webauthn-extensions.html >> # Substantive Changes* >> None Note that a few editorial tweaks were made since September: https://github.com/w3c/webauthn/commits/master/index.bs None of those are substantive. >> *# Requirements satisfied* >> Yes. No changes >> >> *# Dependencies met (or not) >> *Met >> ## *The spec has normative dependencies on the following W3C Recs:* >> https://www.w3.org/TR/webauthn/#normative >> <https://www.w3.org/TR/webauthn/#normative> >> >> ## *The spec has normative dependencies on the following non-W3C >> standards:* >> >> Base64url encoding [RFC4648] >> >> CBOR [RFC7049] >> >> CDDL [Internet Draft] >> >> COSE [RFC8152]. >> >> DOM [DOM4]. >> >> ECMAScript [ECMAScript]. >> >> HTML [HTML5.2]. >> >> OAUTH 2 [RFC6749] >> >> JSON Web Key [RFC7517] >> >> CTAP (Client to Authenticator Protocol) [FIDO Alliance] > > Thank you for the IETF Token Binding Working Group chair's statement on > the dependency on the IETF Token Binding Protocol which is still IETF > draft state. Please confirm with that group whether there are changes > likely to that specification which will require changes the WebAuthn > specification. We already documented a statement from the Group that they were fine with the spec moving forward, so not sure if we need more: https://lists.w3.org/Archives/Public/public-webauthn/2018Mar/0054.html > Also, the Token Binding protocol should be included in > the References section. > > Also, there are many in-line references to github.io versions of > specifications. These will need to be to stable URIs for the PR and > REC. If there are not /TR URIs yet for some of these, that will require > additional explanation. > >> >> *# Wide Review* >> *TAG:* >> https://www.w3.org/Search/Mail/Public/search?keywords=%22TAG+review+feedback%22&hdr-1-name=subject&hdr-1-query=&index-grp=Public_FULL&index-type=t&type-index=public-webauthn >> <https://www.w3.org/Search/Mail/Public/search?keywords=%22TAG+review+feedback%22&hdr-1-name=subject&hdr-1-query=&index-grp=Public_FULL&index-type=t&type-index=public-webauthn> >> >> >> *Privacy Interest Group:* >> https://www.w3.org/2018/01/11-privacy-minutes.html >> <https://www.w3.org/2018/01/11-privacy-minutes.html> >> * >> Web Payments Working Group:*WG discussion >> (12/14/2017):https://www.w3.org/2017/12/14-wpwg-minutes#item02 >> <https://www.w3.org/2017/12/14-wpwg-minutes#item02> >> >> https://lists.w3.org/Archives/Public/public-webauthn/2018Mar/0230.html >> <https://lists.w3.org/Archives/Public/public-webauthn/2018Mar/0230.html>(03/18/2018) >> >> >> *Accessible Platform Architectures (APA) Working Group:* >> https://github.com/w3c/webauthn/issues/733 >> <https://github.com/w3c/webauthn/issues/733> >> >> *IETF Token Binding Working Group:* >> >> https://lists.w3.org/Archives/Public/public-webauthn/2018Mar/0054.html >> <https://lists.w3.org/Archives/Public/public-webauthn/2018Mar/0054.html> >> >> *Public review:* >> The API was the subject a critical blog post. The WG reviewed these >> claims and decided that changes in this API are not needed - changes >> might be advisable (but optional) in CTAP (the companion FIDO spec). >> Of note, these crypto-savvy researchers identified less-than-ideal >> choices the WG had made, typically for good reason, and did not >> identify any showstopper issues: >> https://paragonie.com/blog/2018/08/security-concerns-surrounding-webauthn-don-t-implement-ecdaa-yet >> <https://paragonie.com/blog/2018/08/security-concerns-surrounding-webauthn-don-t-implement-ecdaa-yet> >> >> >> *FIDO Alliance FIDO2 WG review* >> >> *# Issues addressed* >> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2Fwebauthn%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fwebauthn%2F >> <https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2FTR%2Fwebauthn%2F&doc2=https%3A%2F%2Fw3c.github.io%2Fwebauthn%2F> >> > > We noticed in section 5.6 that there is a informative dependency on an > open issue in the HTML spec: > > https://www.w3.org/TR/webauthn/#abortoperation > > It's great to have this documented in the ED (and future WDs). For the > PR and REC the text "the above paragraph will be updated to include" > should say something like "developers may be able to use". > >> *# Formal Objections* >> None >> >> *# Implementation* >> *Web Payments Demo >> implementation*https://www.w3.org/2018/06/lyra-webauthpay.mp4 >> <https://www.w3.org/2018/06/lyra-webauthpay.mp4> >> *Worldpay Web Payments and Web Authentication >> Demo*https://www.w3.org/2018/08/worldpay.html >> <https://www.w3.org/2018/08/worldpay.html> >> >> *Mozilla’s Firefox browser implements W3C Web Authentication API since >> Version 60.* >> https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API <https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API> >> >> >> *Microsoft has added support in its Edge Browser.* >> >> *Google’s Chrome supports the W3C Web Authentication API in Chrome 70 >> (Sept. 2018).* >> >> *The Web AuthN WG has conducted three interop events.* > > The Web Platform Test results are inconclusive: > > https://wpt.fyi/results/webauthn?label=stable&aligned=true > > Please explain these results. The tests are mostly manual so wpt.fyi can't run those properly. We did run them and produced better results: https://w3c.github.io/test-results/webauthn/less-than-2.html https://w3c.github.io/test-results/webauthn/all.html > If these test are relevant, and I hope > they are, it would be good to have an accurate test result report > somewhere. Here is a detailed analysis of the results: https://lists.w3.org/Archives/Public/public-webauthn/2018Dec/0089.html Basically, some of the tests are incorrect, some will need to be removed, some are known bugs. None of the results indicated a specification issue that should prevent the spec from morning forward. Philippe
Received on Friday, 11 January 2019 20:04:50 UTC