W3C home > Mailing lists > Public > public-webauthn@w3.org > December 2018

RE: IMPORTANT READ - Extensions

From: RAE HAYWARD <batraider@hotmail.com>
Date: Wed, 5 Dec 2018 07:43:16 +0000
To: Mike Jones <Michael.Jones@microsoft.com>, Anthony Nadalin <tonynad@microsoft.com>, Christiaan Brand <cbrand@google.com>, Adam Langley <agl@google.com>
CC: W3C Web Authn WG <public-webauthn@w3.org>
Message-ID: <DM5PR07MB28738238DDB9116D68BBFCF3B1A80@DM5PR07MB2873.namprd07.prod.outlook.com>
HI All,

My recommendation is to move forward as originally intended and keep the extensions as an optional but normative part of the final version of WebAuthn.

Kind regards,

Dr. Rae Hayward
Certification Director | FIDO Alliance

From: Mike Jones <Michael.Jones@microsoft.com>
Sent: Tuesday, December 4, 2018 16:41
To: Anthony Nadalin <tonynad@microsoft.com>; Christiaan Brand <cbrand@google.com>; Adam Langley <agl@google.com>
Cc: W3C Web Authn WG <public-webauthn@w3.org>
Subject: RE: IMPORTANT READ - Extensions

Despite what has been said on this thread, I strongly believe that the extensions in the WebAuthn spec should remain in the WebAuthn spec, even if we choose to mark some along the lines as “Proposed extension – non-normative”.  The more documents we have, the longer things will take overall.

Also, for the record, it was agreed on the call that all extensions, such as AppID, for which we have done explicit interop testing, would continue to be normative, even if some other extensions are marked as being proposed and non-normative.

                                                          -- Mike

From: Anthony Nadalin <tonynad@microsoft.com<mailto:tonynad@microsoft.com>>
Sent: Tuesday, December 4, 2018 1:57 PM
To: Christiaan Brand <cbrand@google.com<mailto:cbrand@google.com>>; Adam Langley <agl@google.com<mailto:agl@google.com>>
Cc: W3C Web Authn WG <public-webauthn@w3.org<mailto:public-webauthn@w3.org>>
Subject: RE: IMPORTANT READ - Extensions

I think the proper question was asked, as if you go back in the meeting minutes, the status quo has been per WG to make the extensions normative and that has been the path, thus I’m asking if anyone wants to change that path, so far I heard mixed results with no clear consensus.

From: Christiaan Brand <cbrand@google.com<mailto:cbrand@google.com>>
Sent: Tuesday, December 4, 2018 10:58 AM
To: Adam Langley <agl@google.com<mailto:agl@google.com>>
Cc: Anthony Nadalin <tonynad@microsoft.com<mailto:tonynad@microsoft.com>>; W3C Web Authn WG <public-webauthn@w3.org<mailto:public-webauthn@w3.org>>
Subject: Re: IMPORTANT READ - Extensions

Tony, I believe that on the call most was in favor of the new position: making things optional and non-normative. Since humans are biased towards inaction, I believe that this email, the way it's phrased, won't get us the answer we're looking for. I certainly for one believe in the new, non-normative position. Can we turn this question around and ask: who would absolutely not like to see these non-normative, and why not?

Can we close this item out on tomorrow's call?

On Mon, Dec 3, 2018 at 12:10 PM Adam Langley <agl@google.com<mailto:agl@google.com>> wrote:
On Sun, Dec 2, 2018 at 11:06 PM Anthony Nadalin <tonynad@microsoft.com<mailto:tonynad@microsoft.com>> wrote:
The current consensus position within the working group was to continue to push to keep the “extensions” as optional and normative, due to delays on meeting the ongoing requirements of the W3C for extensions an option was proposed at the last WG call to mark the extensions as optional and non-normative, but still publish the extensions as part of the specification. I would estimate that we would be 2-3 weeks more of discussions with the W3C staff to complete the answers they are looking for if we wanted to continue to make the extensions as optional and normative.

If WG member would like to change the current position from as optional and normative to optional and non-normative please respond to this message, or if you have other suggestions please also respond.

We support moving forward with the extensions being optional and non-normative. I believe this only affects the appid extension, since that's the only one where we have multiple browser implementations, but our position doesn't depend on that.

On the plus side, doing this eliminates a few weeks of expected delay and the risk of a longer delay (esp given the coming holidays). The downsides seem negligible as we don't believe that the normative status has any impact on the browsers' decision to implement or not implement something.


AGL
Received on Wednesday, 5 December 2018 08:08:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:58:59 UTC