Links to meeting minutes in 2017:
January 4, 2017
January 11, 2017
January 18, 2017
No meeting January 25th.
February 1, 2017
February 8, 2017
February 13, 2017: face to face meeting in San Francisco
February 22, 2017
March 1, 2017
March 8, 2017
March 15, 2017
March 22, 2017
No meeting March 29th (IETF).
April 5, 2017
April 12, 2017
April 14, 2017
April 19, 2017
April 26, 2017
May 3, 2017
No meeting May 10th (FIDO plenary).
May 17, 2017
May 24, 2017
May 31, 2017
June 7, 2017
June 14, 2017
June 21, 2017
June 28, 2017
July 5, 2017
July 12, 2017
No meeting July 19th (IETF).
July 26, 2017
August 2, 2017
August 9, 2017
August 16, 2017
August 23, 2017
August 30, 2017
September 6, 2017
September 13, 2017
September 20, 2017
No meeting September 27th (FIDO plenary).
October 4, 2017
October 11, 2017: face to face meeting in Mountain View
The Web Authentication Working Group will have a face-to-face meeting on February 13th in San Francisco during the week of the RSA Conference. Once again, Microsoft is hosting us in their office at 555 California St.
Advance registration is required. Please fill out the registration form to tell us you are coming! We hope to see you there and will post an agenda here shortly!
The W3C Web Authentication working group is pleased to announce publication of the fourth public working draft of the W3C Web Authentication specification.
We solicit your continued feedback – especially feedback based on implementations. If you’re not already a member, you can join the public working group mailing list at https://lists.w3.org/Archives/Public/public-webauthn/.
The W3C Web Authentication working group is pleased to announce publication of a new public working draft of the W3C Web Authentication specification. While this W3C Working Draft is similar in most respects to the First Public Working Draft, it contains numerous refinements intended to enhance the readability and clarity of the specification. These resulted from extensive ongoing review of the first public draft. Changes include separating the authenticator model from the defined attestation formats, clarifying the use of extensions, and defining some additional extensions. Thanks to all of you who reviewed the first public draft!
We solicit your continued feedback – especially feedback based on implementations. Reviews received before the working group meeting on Tuesday, September 20th at TPAC would be particularly useful. If you’re not already a member, you can join the public working group mailing list at https://lists.w3.org/Archives/Public/public-webauthn/. The working group expects to be issuing more frequent working drafts as we approach a Candidate Recommendation, so keep the great feedback coming!
Links to recent meeting minutes, June-December 2016:
June 01, 2016
June 08, 2016
June 15, 2016
June 22, 2016
July 06, 2016
July 13, 2016
July 27, 2016
August 03, 2016
August 10, 2016
August 17, 2016
August 31, 2016
September 07, 2016
September 14, 2016
September 20, 2016 at TPAC
September 21, 2016 TPAC 2FA Breakout
September 28, 2016
No meeting October 5th.
October 12, 2016
October 19, 2016
October 26, 2016
November 2, 2016
November 9, 2016
No meeting November 16th.
No meeting November 23rd.
November 30, 2016
December 7, 2016
December 14, 2016
December 21, 2016
No meeting December 28th.
The W3C Web Authentication working group is pleased to announce the publication of the First Public Working Draft of the W3C Web Authentication specification. This is an important step towards making unphishable privacy-preserving authentication available on the Web and reducing reliance on passwords. Per the W3C process, the publication of the First Public Working Draft “is a signal to the community to begin reviewing the document”. Your active reviews of the specification are solicited – particularly those based upon experiences implementing and using it.
Here’s the abstract:
This specification defines an API that enables web pages to access WebAuthn compliant strong cryptographic credentials through browser script. Conceptually, one or more credentials are stored on an authenticator, and each credential is scoped to a single Relying Party. Authenticators are responsible for ensuring that no operation is performed without the user’s consent. The user agent mediates access to credentials in order to preserve user privacy. Authenticators use attestation to provide cryptographic proof of their properties to the relying party. This specification also describes a functional model of a WebAuthn compliant authenticator, including its signature and attestation functionality.
This specification is derived from the November 12, 2015 member submission of FIDO 2.0 Platform Specifications. Content from the three submitted specifications has been merged into a single Web Authentication specification, also incorporating changes agreed to by the Web Authentication working group.
Early implementations of this and related specifications are already available. The Microsoft Edge browser has an implementation of a slightly earlier version of the specification. Likewise, the Google Chrome and the Mozilla Firefox browsers have implementations of earlier Web authentication specifications, which will both serve as a basis for implementing the W3C Web Authentication specification.
You can join the public working group mailing list at https://lists.w3.org/Archives/Public/public-webauthn/. Taking your feedback into account, the working group aims to reach a stable specification draft (Candidate Recommendation) by September, 2016. We look forward to receiving your feedback on this specification!
Just so they’re all in one place:
May 25th, 2016: summary of decisions sent to list for review:
1. Agreement that all extensions should be optional, and agreement to leave pre-defined extensions in the spec as they are currently defined.
2. Start an IETF RFC for the creations of a IANA Registry for the extensions (Jeff took this action item)
3. Add clarifying text around the extensions (Jeff took the action item)
Berlin F2F, May 13th: commentary
– VGB overviewed issues for FPWD, rough agreement for his rewrites
– Next meeting for agenda F2F
– Keeping sigs and attestation formats as separate sections
– Felipe’s terminology section
– CredentialID unique across authenticator architectural issue
– github issues preferred method before raising issues
– Discussion over what’s right level of abstraction re: attestation/signatures and whether they should stay in W3C, and IETF update
SF F2F, March 4
The next face-to-face meeting of the W3C Web Authentication Working Group is in Berlin, Germany from 9 AM-5 PM hosted by Microsoft at Unter Den Linden 17. The W3C Working Group meeting takes place directly after the FIDO Alliance meeting in Berlin May 10-12th. More details on the venue are available.
An agenda is now available.
Please register by Monday, May 9. Registration is open to Working Group participants. If you’re not yet a WG participant, please email wseltzer-at-w3.org to ask about observing the meeting.
The Working Group is using GitHub for its drafts and issue discussion: https://github.com/w3c/webauthn. The current Editors’ Draft combines the deliverables into a single draft spec, available at http://w3c.github.io/webauthn/.
We meet weekly on Wednesdays (1700 UTC, 1300 Boston) by phone and in the #webauthn channel on irc.w3.org. Calls and agendas are announced on the mailing list.
New participants are always welcome to join the group.
We’re looking forward to the Webauthn WG’s first meeting March 4. In preparation, we ask participants to familiarize themselves with the group’s charter and the FIDO 2.0 drafts we’ll be taking as input.
According to the charter,
The working group will deliver at least the following:
- Web Authentication API
- This specification will make secure authentication available to Web application developers via a standardized API providing the operations detailed in the scope section. The FIDO 2.0 Web APIs will be an input into this standard.
- Data and signature formats
Formats for signed data and verifiable attestation of a signer’s properties. The FIDO 2.0 Attestations and FIDO 2.0 Signature Format will be inputs into this standard.
At the meeting, we’ll formally ask to accept the drafts and move them into the GitHub repository for editing.
For easy reference: