Re: IMPORTANT READ - Extensions

I don't recall any proposal to remove extensions from the spec.

I think the proposal was to have the AppID extension optional and 
normative because er have interop, and have the other extensions marked 
optional and non normative.

I agree that it would be better to have them as normative, but not if it 
holds up publishing the spec for another month.

At some point we do need to move ahead and publish.   If we need to mark 
some of the extensions as non normitive until the next version of the 
spec I don't think anyone is going to die.  I suspect the browser and 
authnticator vendors will do the correct thing even if they are not 
normative.    If they don't then they will be broken.

I prefer to finish.

John B.

On 12/5/2018 12:40 AM, Mike Jones wrote:
>
> 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>
> *Sent:* Tuesday, December 4, 2018 1:57 PM
> *To:* Christiaan Brand <cbrand@google.com>; Adam Langley <agl@google.com>
> *Cc:* W3C Web Authn WG <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
>