Re: Interop requirements for extensions

On 3/19/18 6:12 AM, Giridhar Mandyam wrote:

> I view the concept of Webauthn extensions and the corresponding extension/attestation registry (currently being taken up in the IETF) as being roughly comparable to other registries that allow for standard extensibility in the W3C.  For instance, the MSE bytestream registry (https://www.w3.org/TR/mse-byte-stream-format-registry/) does not use the term "informative" anywhere in the document (although some sections are clearly marked as 'non-normative').  Moreover, registry entrants such as the ISO BMFF bytestream (https://www.w3.org/TR/mse-byte-stream-format-isobmff/) are not marked in total as "informative" although the bytestream formats do not seem to be verified for interoperability (or if they were, I could not find where in the W3C the interoperable implementations were documented).  Granted, the MSE registry and corresponding entries are designated as WG Notes.  However, we as a WG chose to document extensions and attestations as part of the Webauthn specification itself.

I see a notable difference in what's required for an assignment in a 
registry v. what's required for a standard.  A common metric for 
assignment is registries is "specification required".  That could be a 
not-yet-implemented spec, as Tony has said some of these extension will 
be.  And a registry typcially won't comment on the adequacy of the spec. 
  Whereas a common expectation for W3C Recommendations is "you actually 
implemented this and demonstrated interop".  We're not talking about 
denying these extensions slots in a registry.  But we are talking about 
not including the full text of them in a Recommendation or, 
alternatively, flagging it as non-normative.  I'm fine with the WG's 
decision to include extensions, including unimplemented ones, in the 
same doc, but I see the Director's point about flagging them.

In any case, based on discussions with the chairs and other WG members, 
I've started the publication machinery for a CR doc containing the text 
I proposed last week, favoring keeping to our publication schedule 
rather than delaying the doc for this.  We can keep hashing this out 
over the next few days, weeks, or even months, if needed.

-- Sam

Received on Monday, 19 March 2018 14:25:44 UTC