- From: Akshay Kumar <Akshay.Kumar@microsoft.com>
- Date: Tue, 4 Dec 2018 21:22:18 +0000
- To: Christiaan Brand <cbrand@google.com>, "J.C. Jones" <jc@mozilla.com>, Giridhar Mandyam <mandyam@qti.qualcomm.com>
- CC: Adam Langley <agl@google.com>, Anthony Nadalin <tonynad@microsoft.com>, W3C WebAuthn WG <public-webauthn@w3.org>
- Message-ID: <MW2PR2101MB08899641A0D61B97421D73BC86AF0@MW2PR2101MB0889.namprd21.prod.outlook.>
Changing from normative to not normative is not what we want... We want extensions to be normative as those are normative in nature whenever we implement those... From: Giridhar Mandyam Sent: Wednesday, December 5, 1:59 AM Subject: RE: IMPORTANT READ - Extensions To: Christiaan Brand, J.C. Jones Cc: Adam Langley, Anthony Nadalin, W3C WebAuthn WG What I had proposed many moons ago [1] was to deal with extensions/attestations as other existing W3C registries, such as the MSE bytestream registry. The MSE bytestream registry refers to WG notes (not standards-track) that are normative, in the sense that they contain normative language. For example, see [3]. I don’t think we need to alter our course of publishing the registry in the IETF, but if we are willing to re-factor the spec we could separate the extensions out into WG notes that are normative. But that could be an intensive task. -Giri [1] https://lists.w3.org/Archives/Public/public-webauthn/2016Aug/0136.html<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.w3..org%2FArchives%2FPublic%2Fpublic-webauthn%2F2016Aug%2F0136.html&data=02%7C01%7CAkshay.Kumar%40microsoft.com%7C39a45c768d0042285f9108d65a2733eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795521756071694&sdata=1B6K40EtAyhSDnQ6gIDp%2BN1oPcpFzSy1dPx1q8NlZ5o%3D&reserved=0> [2] https://www.w3.org/TR/mse-byte-stream-format-registry/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fmse-byte-stream-format-registry%2F&data=02%7C01%7CAkshay.Kumar%40microsoft.com%7C39a45c768d0042285f9108d65a2733eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795521756081704&sdata=lm1GmWs2l1Mj1sk9tgqAF7F2P9pDzan6HOvMEq6FsaQ%3D&reserved=0> [3] https://www.w3.org/TR/mse-byte-stream-format-webm/<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.w3.org%2FTR%2Fmse-byte-stream-format-webm%2F&data=02%7C01%7CAkshay.Kumar%40microsoft.com%7C39a45c768d0042285f9108d65a2733eb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636795521756081704&sdata=FACqdTrYFERAsOXNYSKyb%2B3Cnbm4Y26R5uPknDzE7%2Fo%3D&reserved=0> From: Christiaan Brand <cbrand@google.com> Sent: Tuesday, December 4, 2018 12:13 PM To: J.C. Jones <jc@mozilla.com> Cc: Adam Langley <agl@google.com>; Anthony Nadalin <tonynad@microsoft.com>; W3C WebAuthn WG <public-webauthn@w3.org> Subject: Re: IMPORTANT READ - Extensions I think the “three week wait” is overly optimistic. But maybe that’s just me. On Tue, Dec 4, 2018 at 11:58 J.C. Jones <jc@mozilla.com<mailto:jc@mozilla.com>> wrote: If we mark all of the extensions as non-normative, it seems like they should move into some other document(s) of extensions then, as Mike Jones advocated many moons ago. Isn't that the normal way these things work? That seems like more work or delay than waiting for the FIDO/W3C talks to finish up. J.C. On Tue, Dec 4, 2018 at 1:59 PM Christiaan Brand <cbrand@google.com<mailto:cbrand@google.com>> wrote: 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 Tuesday, 4 December 2018 21:33:57 UTC