Re: Transition Request: Web Authentication to Proposed Recommendation

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/

> *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)

> *# 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.

Where is the evidence for interoperable implementation of these extensions?

> # Substantive Changes*
> None
> 
> *# 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.  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.  If these test are relevant, and I hope 
they are, it would be good to have an accurate test result report somewhere.

We understand that these tests require extra effort to run due to the 
need to supply credentials.  PLH was able to show much better results 
for at least the IDL harness tests using his (hardware) key in both 
Chrome and Firefox so we have some hope of better implementation evidence.


> *# Patent disclosures*
> https://www.w3.org/2004/01/pp-impl/87227/status#current-disclosures 
> <https://www.w3.org/2004/01/pp-impl/87227/status#current-disclosures>
> https://www.w3.org/2017/03/webauthn-pag-report.html 
> <https://www.w3.org/2017/03/webauthn-pag-report.html>
> 
> Co-chairs
> Tony Nadalin
> John Fontana
> 
> -- 
> 
> John Fontana
> 
> Identity and Standards Analyst | Yubico <http://www.yubico.com/>
> 
> Phone: +1 303 301 4437
> 
> Skype: j_fontana

Received on Wednesday, 26 September 2018 16:54:37 UTC