RE: Interop requirements for extensions

Since we have more time to discuss ...

> And a registry typcially won't comment on the adequacy of the spec.

I do not believe this statement to be applicable either to the Webauthn registry or even the MSE bytestream registry.  For instance, see https://www.w3.org/TR/mse-byte-stream-format-registry/#entry-requirements:  "Candidate entries MUST be announced on public-html-media@w3.org(subscribe, archives) so they can be discussed and evaluated for compliance before being added to the registry."   In the case of the bytestream registry, the inclusion of a specification means that the spec itself has met the necessary inclusion requirements, i.e. a "comment on the adequacy of the spec."

In the case of webauthn, all of the pre-registered extensions and attestation formats have underwent significant discussion and technical review.  Although this has mainly occurred in the Github repo, this discussion has been replicated on the webauthn mailing list. The inclusion these formats in the spec is certainly an implicit comment on their adequacy. There will also be formal rules established for expert review for future extension/attestation proposals.  There is an issue tracking this topic in https://github.com/w3c/webauthn/issues/303.   

-Giri

-----Original Message-----
From: Samuel Weiler <weiler@w3.org> 
Sent: Monday, March 19, 2018 7:26 AM
To: W3C Web Authn WG <public-webauthn@w3.org>
Cc: Giridhar Mandyam <mandyam@qti.qualcomm.com>
Subject: 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 Sunday, 25 March 2018 16:28:13 UTC