RE: Interop requirements for extensions

I don't think that WG believes this is the right decision to require 2 implementations of each extensions, the extension is a framework, the input and output are what is tested, each extension is optional to implement, not all extensions will be implemented. Each extension must be registered in the IANA registry. The extensions are extensible, as new extensions may be created and registered. 

-----Original Message-----
From: Ralph Swick [mailto:swick@w3.org] 
Sent: Saturday, March 17, 2018 6:59 AM
To: Samuel Weiler <weiler@w3.org>; W3C Web Authn WG <public-webauthn@w3.org>
Cc: Anthony Nadalin <tonynad@microsoft.com>
Subject: Re: Interop requirements for extensions



On 2018-03-16 05:15 PM, Samuel Weiler wrote:
> TL;DR: what is the problem, if any, in marking extensions as 
> "informative" (v. normative) when moving to CR, in the absence of 
> prover interoperable implementations?
> 
> 
> During the WG call on Wednesday, Ralph, acting as director, pushed 
> back on publishing not-yet-implemented and 
> not-yet-proven-to-be-interoperable
> extensions as normative.  He offered the WG the option to still 
> publish them but flagged as informative, marking the extensions as "at risk"
> during the present transition to CR.

To be clear, the only change for the CR would be to say that *if implementation experience has not been demonstrated for those "At Risk" 
features when the WG asks to advance this specification to Proposed
Recommendation* then rather than removing those features from the specification (the common approach in W3C), the features would be changed from normative to informative.*

That is, the CR can continue to propose these features as normative.

> I heard some objections from the WG, but I don't understand those yet. 
> Now's your chance to make the case in writing.  If you think we need 
> something different make the case for it, knowing that doing so might 
> delay publication.
> 
> I have proposed text below (as has John, in private mail) that takes 
> the director up on the offer that would still allow the WG to publish 
> unimplemented or untested extensions.

I interpret the proposed text as matching the clarification above.

-Ralph

> -- Sam
> 
> 
> 
> 
> -------- Forwarded Message --------
> Subject: Re: Transition Request: Web Authentication: An API for 
> accessing Public Key Credentials Level 1 to Candidate Recommendation
> Date: Fri, 16 Mar 2018 17:06:30 -0400 (EDT)
> From: Samuel Weiler <weiler@w3.org>
> To: Ralph Swick <swick@w3.org>
> CC: John Fontana <w3c@yubico.com>, chairs@w3.org, Philippe Le Hegaret 
> <plh@w3.org>, Team Archive <w3t-archive@w3.org>, Mike Jones 
> <Michael.Jones@microsoft.com>, Anthony Nadalin 
> <tonynad@microsoft.com>, Angelo Liao <huliao@microsoft.com>
> 
> On Fri, 16 Mar 2018, Ralph Swick wrote:
> 
>> I don't yet see (a version of) this in the Editor's Draft.
> 
> It is not in the Editor's Draft (contrary to what you were told 
> earlier).  It is in the (unpublished) CR.
> 
> The current (as of 15 March) text reads:
> 
> For the Web Authentication specification to move to Proposed 
> Recommendation we must show two independent, interoperable 
> implementations of the Web Authentication API in browsers. We have 
> already completed a portion of this work at two informal interops with 
> implementations from three browsers (Chrome, Firefox, and Edge). These 
> initial compliance tests have yielded relevant datasets that have been 
> used to improve the specification. We will have multiple interoperable 
> implementations of at least one extension – AppID, validating the 
> extensions framework. Some other extensions may not have multiple 
> implementations at the time of the PR transition, and are therefore at 
> risk. We have a suite of initial compliance tests that have been 
> committed to the W3C Web Platform Test repo and additional 
> improvements to the tests will be required for the move to Proposed 
> Recommendation
> 
>> Please explicitly enumerate in the SoTD those extensions that are at 
>> risk; i.e. are all of 10.2 through 10.9 At Risk?
> 
> Yes.
> 
>> If you only label features as "at risk" then the usual expectation is 
>> that those may be removed from the specification at Proposed 
>> Recommendation transition if you are not able to demonstrate 
>> implementation experience.  As an alternative, you might move those 
>> features from normative to informative. If the WG wishes to have this 
>> alternative available please state in the SoTD that the "at risk"
>> features will either be removed or made informative.
> 
> I propose:
> 
> For the Web Authentication specification to move to Proposed 
> Recommendation we must show two independent, interoperable 
> implementations of the Web Authentication API in browsers.  We will 
> also have multiple interoperable implementations of the AppID 
> extension, validating the extensions framework.  All other extensions 
> are "at risk".  If there are not multiple interoperable 
> implementations, each may independently be removed or made informative at Proposed Standard.
> 
> We have had two informal interoperability tests with implementations 
> in three browsers.
> 
> [This proposed text also removes many details re: the testing to date, 
> that, IMHO, doesn't need to be in the spec.]
> 
> -- Sam
>

Received on Monday, 19 March 2018 09:36:56 UTC