<weiler> fontana: <updates us on transition>

<weiler> ... need exit criteria.

<weiler> ... test tools will be baked, but those need more work. also mentioning that we have interop.

<weiler> ... I'll alert Ralph; no need to resubmit doc.

<weiler> nadalin: does he need updated doc?

<weiler> weiler: don't need new doc for review, but will need one for CR

<weiler> jeffh: this sounds like a WD-09, but formatted as CR

<weiler> ... what about PR835?

<weiler> weiler: except that we don't publish the WD-09

<jeffh> weiler: wrt publishing a CR -- we need to run bikeshed to produce CR-formatted HTML output

<weiler> https://github.com/w3c/webauthn/issues/837

<jeffh> weiler: we need to create an include file that (ostensibly) contains the "CR exit criteria"

<weiler> example: https://www.w3.org/TR/wake-lock/

<jeffh> weiler: see also issue #837

<jeffh> weiler: see the examples in #837

<jeffh> weiler: to do this need new include file, probably ought to put the file in the webauthn repo, do a PR to put it there

<jeffh> weiler: run BS, package up the output into tarball, send to Weiler, he works with w3c web team to post it in TR namespace

<jeffh> weiler: now discuss CR exit criteria...

<jeffh> tony: extensions are optional

<jeffh> weiler: we will be safest by documenting we are not doing interop testing on the extensions

<jeffh> mikejones(mbj): <suggests specific text wrt extensions & interop testing>

<jeffh> weiler: not sure what mbj said will fly...

<jeffh> angelo: web crypto did it...

<jeffh> weiler: they said those things were "at risk"

<jeffh> weiler: will go down the hall and check with folks on this....

<weiler> https://github.com/w3c/webauthn/pull/839

<Rolf> what about attestation formats and types?

<jeffh> mbj: approves pull #839

<gmandyam> Note that the topic of extension interop was raised during TPAC 2016. Harry (representing W3C) stated "re extensions as long as there's no MUST/SHOULD normative text and it's clearly marked as extensions, should be fine"

<gmandyam> See https://www.w3.org/2016/09/20-webauthn-minutes.html

<weiler> thanks, giri. let me see

jeffH if it is clearly marked as extensions it should be OK

tony: these are the only issues we have left. correct

selfissue we need to do #835

tony: i don't see it
... that the one self issued did

selfissue: I will put it under CR

jeffH: i thnk we need to address this

selfissue: this is left over. this sentence was deleted, it said it was in the sta structure and it is not in the structure
... it is a one sentence change
... the rest is instructions for processing steps

jeffH: we probably need to have a hyperlink to cross reference what we are talking about

selfissue: I will call it a dictionary of client extensions
... we stil hav eto have thisl
... i will fix the language here in real time.

weiler: cna we go back to criteria for extensions
... we normally interop the extensions. we can mark the extensions as at risk for now, if we don't have at PR time we mark them as...

tony: they are not intended to be interop.

ralph: OK if you have two implementations of these extensions.

tony: I don't know anyone who will implement the others.

<jeffh> weiler: we should mark the extensions all except appid as "at risk" expecting at PR we will mark them as informative

weiler: we should amke everytig expcet appID as 'at ridsk' and put then in the exit criteria, expecting at PR we need to mark them as informative when we publish.

tony: I would like ot argue that pont I wold not say they are at risk
... I don't want to say they are infomrative when we go PR

giri: I was told extensions would be a special case and not a candidate for implementaion

weiler: ralph said we don't have to show interop, but we have to show it is used. there is some form of implementation experience.

giri: need to be one implementation if we don't want to makr it as informative?

wieler: ralph is grimacing at that.

giri: if we mark as informative,

tony: informative mark hurts us not helps us.

weiler: key I hear is implementation experience.

tony: why do we have to do for each extensions?
... if they all use the same framework, we say this is all compatible.

weiler: i would suggest marking as 'at risk' for now and sort it out over the next three months

selfissue. i disagree marketing appID as at risk.

tony: goal is to not have to come to PR and be told we have to make these informative

jeffH: because some may bet implemented. liek transaction confirmation
... tonu met implement now; it could be in the future
... we are pusing back on w3c prcoess a bit, this is an odd-ball spec, maybe w3c spec review needs to be updated to accommodate protocol specs

weiler: I don't se ethe difference between API and protocol, I see labing something that does not have interop.
... i don't think you can label vaporware.
... maybe extensions have to sit as we move to PR

tony: but this is one spec.
... I want to push back on process

jeffH: i agree. we have an extensible protocol here.
... at IETF we run things up standards track that are extensions

ralph: if there is a framework that demonstrates the interop....if you can't show that someone is using extensioins. then how do we know they are ready to be declared a standard

<jeffh> ralph: demo of impl expr of framework is good baseline. wrt extns, if there is not impl experience of some of them, how can we declare them as part of a std ?

ralph: speculating, maybe the mechanism is patterns after things that are proven in a diff context.
... the w3c kprocess shows that someone actually wants to use this. it doesn't have to be a shipping product.
... want to make sure something wasn't overlooked

tony: current plan is to mark the extensions 'at risk' accept for appID and we will work though it so these are not made informative
... thanks Ralph
... Mike will write sentence about this is framework and the extensions are optional to implement...

selfissue: can say extensions all optional to implement
... but say we expect to have at least one implementation to validate the framework.

tony: Angelo will merge the new language.

angelo: after I get language

<weiler> put it in https://github.com/w3c/webauthn/issues/837

weiler: as soon as you submit changes on 835, we will send exit criteria text separate in email.

<weiler> send a note to Ralph once 835 is done. send him the exit criteria text in email separately, even before the CR doc is done.

https://github.com/w3c/webauthn/pull/835

jeffH: it has been evaluated and I will merge.

selfissued: we never merge #839 removing Johan
... I will do it

<weiler> mention 839 in the note to Ralph. it won't surprise him.

jeffH: saying turn the crank and produce the draft, turn the crank
... on a cR

tony: angleo can you produce a wd09

angelo: yes. whiy?

tony: just for process, so we can say we have working draft, and then do the tar ball for sam

weiler: marking them as at rick now, gives us all the outs we could possibly want

tony: I don't wnat to get in battle and not get to CR

<apowers> thx

tony: goal is not to have extensions separate, or made informative and we will work on process change so we can proceed without the at risk.

weiler: i wil put propsoed text in the draft.

selfissued: I thik 'at risk' goes in the draft , so we need a PRl

weiler: think it can go in the include file.

selfissue: OK put it there
... extensions all are optional, and all are at risk excpet appID

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Present: weiler jfontana nadalin gmandyam akshay agl jeffh christiaan Rolf angelo elundberg Ralph apowers
Regrets: jcj_moz
No ScribeNick specified.  Guessing ScribeNick: jfontana
Inferring Scribes: jfontana

WARNING: No "Topic:" lines found.

Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2018Mar/0086.html
Found Date: 14 Mar 2018
People with action items: 

WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)