<weiler> scribenick: jfontana

Tony: talk about paragon about concerns over ecdaa stuff and RSA PKCS1.5
... I don't see issues iwth RSAissues, using this for signatures.

jeffH: we have it in there mostly for backward compatibility

tony: yes, most of systems so this.
... the author is a bit confused on what is beign used and why it is being used.
... rolf can you fill us in

rolf: there is same pattern, there is some context knowledge missing. ..no clue about attestation
... on criticism we are using random numbers, but that is not uncommon
... I can kind of understand the argument to make typical implementation better.
... we cant simply take the message and has and use that to replace the random number
... it needs to be more complex, not as straight forward as researcher things.
... we may want to remove shorter curve, ...we might want to see longer curves .
... what are good curves for this purpose, we can have that discussion with others.
... I can't follow the compress and uncompress argument

agl: I can speak to pint compression. if you decompress point, you cannot forget to check those points on the curve
... there is IP fear around compression
... the question has been tied to type of curve.
... I don't see any strong reason to worry. I am pretty negative on this blog post overalll

tony: I don't think any of the W3C specs are affected by the blog post
... ther may be a slight change or note tha tFIDO has for attestation.

agl: I think we are in agreement there are no webauthn changes called for here.

tony: sam, do we need to do anything here, address in github

sweiler: would like to see someone from group post to mailing list with a technical evaluation of the findings.

gmandyam: may be good for FIDO to do this

rolf: discussion in FIDO was for short response on Twitter then start some talks privately
... could be more valuable for FIDO and W3C to have a conversation

sweiler: I don't want a press release. I would like to point to a public post. We don't think these points are warranted on a technical level

tony: if we come to agreement on something. we can have it as a note from WG, but not have a post.
... the problem is we are taking his words from his post and there is not a lot of detail
... we need more information about his concerns.
... worry about point by point that lacks detail

rolf: defending publicly doesn't lead anywhere.

tony: I think we can do a generic statement...that we determined changes are not needed.

sweiler: I would almost like to have the more detail but not WG response. but I am agreeable to what you are suggesting.
... a short response. either is fine with me.

agl: I will offer that to write up something technically, I can do that. but we have not plans around ECDAA

tony: so maybe others should come up with short response for WG mailing list.

akshay: do we really need to respond to every report? we can say we have evaluated and don't see an issue.

tony: yes, do simple post to mailing list, we looked over, we see no changes needed to webauthn

rolf: in favor of a generic response.

gmansyam: don't need more than a brief response. We have enough to do with the spec to worry about every comment.

jbradley: I am happy with what the group wants to do.

jeffH: I concur with thoughts stated here.

jc_jones: Mozilla has tendency to respond to these, but I am fine with our general consensus.

tony: anyone opposed to WG statement?
... I will try to put one together.
... OK, sam.

sweiler: I am fine following the WG here.

now to PRs

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

tony: this is JeffH

jeffH: emil had issues and I just replied, don't some clarification.

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

tony: jeff has some questions
... emil has to look at these. He will respond to comments.

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

tony: ready to go, can someone merge

JeffH: yes.

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

JeffH: I can merge, ready to go

tony: if we are going to meet our deadline for PR we will have to punt some issues.
... are there issues here that some would be uncomfortable not closing out.

agl: I want to talk about 'n' on WebAuthn..

tony: last week we said lowercase 'n'....emil will make that change.
... there is a few spots where capital 'n' used.
... I will make sure all instances are lowercase

this Issues is https://github.com/w3c/webauthn/issues/1056

jeffH: to speed this up
... I looked through mine and the ones that do not have PR open on them are ones we can move forward without addressing either credman , fetch or other minor things.
... that takes out about half.

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

heffH: pr oepon

585, 1020, 1042 1059 these are the ones we need to resolve.

tony: does anyone have any objections to move remaining issues to Level 2?
... I am following up on call for consensus and make sure no objection for request to go to PR
... caveat is that we close the 5 open PRs that we have.
... if we close, is anyone objecting to going to PR?
... resolving the remainng editorial changes in Rec or moving to level 2.
... not hearing any objections

we have consensus

close 483, 585, 1020, 1042, 1059, and if needed 1056

tony: so we will pull together the package to request PR, and present it next week Spet 18

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

tony: this could be technical...

jbradley: i think it can wait til the next releaes.

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

tony: agl has responded..

agl: my thoughts summarize as, sure, whatever.

tony: if someone does this fine, or it gets pushed to L2?
... it would only be a consideration and not a tech change to spec.

jeffH: agrees with this

akshay: i think we can move to L2

tony: any objection? none heard

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

jeffH: this is a nit.

agl: I think you are correct about it

jeffH: it is quick and easy change

tony: ... can you do soon.

jeffH: yes. I will makes changes and merge.

tony: any objections?

none

tony: please merge.
... any other business

jbradley: one issues. I filed something on it. comes down to interpretation of intended functionality
... we have APP/ID extension. browsers interpret part of spec only applies to U2f only authenticators.
... noting in spec that lead me to this, but more than 1 browser interprets it this way.
... the intent is that when sitses from from u2f to webauthn the credential should continue to work.
... so the browser has implemented app/ID for only u2f authenticators

agl: I will say, it if does not work with FIDO2 Yubikey, we are working with Yubico to figure out. But we will figure it out.
... we were internally confused, but it is part of wider issue.
... hope to fix soon

jbradley: this is different from make cred issues in chrome

agl: we have a general difference around CTAP2 codees

Kim: we will fix. I do agree the spec does not call out how combo of specs works.

jeffH: if under specified, is there an issue somewhere.

?

jbradley: the appid is not in the ctap2 spec

akshay: we are doing... if you have appid you are bridging an old world and new world. use appid for u2f interface in new we used AppID

jbradley, which had unintended consequence if you have hybrid authenticator, it means that when google goes to webauthn not all of your credentials will work

jbradley: there is a fix in an upcoming version....

akshay: lets put it in to spec and close it down

gmandyam: i don't see it in the spec.

jbradley: if all browser vendors understand the right way, then we will be fine. maybe we need to add clairifcation so we can end this conversation.
... I can open an issue.

tony: on other thing gmaydyam, has agreed to write up our extensions at risk. so we can move forward with extensions that are already in the spec without them being pulling

gmandyam: I have had some conversations with w3c leadership. I will work with Mike and Jeff, and then have something at TPAC.
... want to makes sure PHL is in the room

tony: OK, anything else.

akshay: I want to talk to Adam about . #1050. the level of transport
... christiaan there? no.

agl: no

akshay: want to understand some use cases. create platform cred on android and you want to tell RP you can use it for other transports.
... think that underlying use case on this PR

agl: not quite what we have in mind. create a cred on android using fingerprint. when that cred is challenged by spec ...the authenticator will say it will not work
... it presents confusion for the user.
... we are looking at transport to sovle the issue I just talked about.

tony: adjorn.

adjourn

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: LukeWalker Rolf agl jcj_moz jeffh jfontana john_bradley nadalin weiler akshay gmandyam kim
Found ScribeNick: jfontana
Inferring Scribes: jfontana

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 12 Sep 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.)