scribenick elundberg

jfontana: Let's continue the discussion about editors on the mailing list
... Freeze for CR is dec 20th, so we'll need to be efficient

correction: dec 18th

jeffh: Dec 18th seems very aspirational

<weiler> jeffh++

https://github.com/w3c/webauthn/issues/106

jfontana: I'm in a conversation with wseltzer, not much more to do here for now

https://github.com/w3c/webauthn/issues/184

there's a PR open for #184: https://github.com/w3c/webauthn/pull/687

selfissued: It's not clear what changes are requested

https://github.com/w3c/webauthn/issues/227

#687 is also related to this: https://github.com/w3c/webauthn/pull/687

akshay, elundberg: With hot plugging this is no longer an issue

selfissued: Does this need normative spec text or just some implementation guidance?

akshay: Probably just implementation guidance

gmandyam: I'm assuming a client that supports this extension will fail the makeCredential when an authenticator with the AAGUID is not available?

akshay: Right now we don't have a full implementation, but with hot plugging the extension can't fail the makeCredential before the timeout expires
... I think we can close this right now

jfontana: Let's leave it open and move to L2

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

jeffh: I agree with the intent, but I think we should ditch the "recognized algorithm name" term

jyasskin: That term is used in the DOM

agl: I think in practice all clients will pick SHA-256 and RPs will always expect SHA-256 and break horribly if other algs are used
... I think what we'll do in Chrome is pick algorithm by coin flip, so RPs are forced to support all algs

jbradley: I agree signaling is a nice theory, but not effective in practice

weiler: My interest in algorithm agility is the opportunity to upgrade to something we don't know today

gmandyam: @jyasskin: What was your issue with the COSE algorithm names?

@jyasskin sorry, I didn't catch your response

jyasskin: I think action now is stick to SHA-256

agl: And strip out the "recognized algorithm name" stuff because noone seems to like that

jeffh: There's some editing to do, let's do the work before we close the issue

agl: I can do this

https://github.com/w3c/webauthn/issues/491

agl: @jeffh points out the appId extension won't quite work if allowCredentials contains more than one credential
... There's quite some work to do here, and it's an important extension
... I think sites with U2F won't be able to move to webauthn without this

jcj_moz: I agree we need this

<jyasskin> elundberg: The issue with COSE algorithm names (listed in https://www.iana.org/assignments/cose/cose.xhtml#algorithms) is that there aren't any hash algorithms there now, just signing and encryption algorithms. https://www.iana.org/assignments/jose/jose.xhtml also doesn't have them.

thank you @jyasskin

jeffh: We need to resolve this for UAF as well

agl: I could do the surgery needed here for U2F, but not UAF

jeffh: I think we should settle for solving U2F for now

elundberg: Could you have the client try both RP ID hash and AppID hash if AppID is given?

jfontana: Seems like consensus is to focus on the U2F case for now

agl: I'll take this one too

https://github.com/w3c/webauthn/issues/543

jfontana: @selfissued is assigned, but no longer present

jeffh: We need to get @agl into the WG so we can assign him the issues

@weiler https://github.com/agl

angelo: There's no clear action to take here

jeffh: I need to take another look at this. If I recall correctly, it's about raising awareness to spec readers about COSE_Key
... Leave this for now

https://github.com/w3c/webauthn/issues/599

gmandyam: This is assigned to Christian who is out for a while, so we may want to reassign it

correction: that was Rolf, not gmandyam

agl: I can highlight this to some people at Google who might be familiar, but don't know if there'll be any tangible result

jcj_moz: If we have to kick this to PR we probably can

https://github.com/w3c/webauthn/issues/626

jcj_moz: I'm working on this, should have it done by the weekend

gmandyam: Related there's https://github.com/w3c/webauthn/pull/695 which has been approved, can we merge that?
... It's marked for PR but I think we can get that in now

jcj_moz: I agree, #695 is a pure improvement

https://github.com/w3c/webauthn/issues/685

there's a PR open: https://github.com/w3c/webauthn/pull/686

#686 needs review

jeffh: I'll review

jcj_moz: I'll review

jfontana: We're running out of time

gmandyam: I think there are some quick ones

https://github.com/w3c/webauthn/issues/589

Rolf: We can close this because it has been addressed

https://github.com/w3c/webauthn/issues/588

Rolf: The PR #677 addressing this has been merged already
... We should close this

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

related to #579

Rolf: This needs review

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

angelo: We planned to replace this section with a reference to CTAP

jeffh: The webauthn spec already indicates that it's an abstract model, but could perhaps be more clear on that
... CTAP isn't going to be the only client backend API
... So we still need this to be in the spec and keep it quite abstract
... The spec _may_ be good enough now, but we might need some editorial changes

angelo: I think we should move this to PR or L2, and look at this if we have time after CR

jcj_moz: That's fine with me

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)

Succeeded: s/agl: @jyasskin points out/agl: @jeffh points out/
Present: jeffh weiler elundberg gmandyam akshay battre elungberg selfissued jcj_moz jfontana JBradley Rolf apowers angelo agl
Regrets: wseltzer
No ScribeNick specified.  Guessing ScribeNick: elundberg
Inferring Scribes: elundberg

WARNING: No "Topic:" lines found.

Found Date: 06 Dec 2017
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


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.)