W3C

- DRAFT -

Web Authentication WG

24 Jun 2020

Agenda

Attendees

Present
wseltzer, jfontana, Nadalin, elundberg, jeffh, jeremy, selfissued, gavin, bill, akshay, agl, Jiewen, Eric, nsteele
Regrets
jcj_moz
Chair
Nadalin, Fontana
Scribe
jfontana

Contents


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

agl: potentially ready. some comments to address

elundberg: I will resolve the conversation and mark as approve

agl: with empty extensions, should that extension be echoed back, current spec says no

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

seelfissue: I will fix the names and merge

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

tony: nick is not here
... table

elundberg: re-read and then I can approvee

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

nickS. some clarification in there

scribe: I did address elundberg questions

tony: he need to verify

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

<nsteele> thanks for rewinding jfontana!

agl: not exciting. we can close next week if no aciton

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

elundberg: suggestion we change dfinition in the extension section to mirror the App Exclude
... AppID Exclude

agl: broad rules, but I don't think it is true

selfissue: I disagree, you get output if extension is processed

adl: for AppID Exclude, it is useless

tony: it is a rule that should be obeyed

agl: I think the rule should change rather than bending

jbradley: may be true nothing useful. knowing that AppID Exclusion did not work does tell you something

agl: if you want a true in there, go ahead. I might not implement

elundberg: saying the value of the output would be true.

agl: so it is useless and confusing
... we could parse to Windows, but if not enforced, do we treat as use agent string

bradley: larger discussion here
... extend the API and pass it down and get something back...
... do something with the extension?

agl: would could plumb it back, but this is what led me to my thinking
... it is a great deal of plumbing, which is behind the idea it should not have an output

selfissue: consistency is more important. we have "true if no output"

jbradley: chrome may not know it was acted on, that is where it gets compicated

akshay: looks to me it is more confusing

agl: not always true; it is misleading

akshay: if i had time I would plumb it through

agl: lot of work to throw it away in the end

selfissue: the rule lets you know it was processed.

agl: could leave as none, always true or true/false
... I have no opinion

jbradley: don't you need to change API to pass down the AppID
... don't know if there is that much more work

agl: doing the plumbing does not seem worthwhile

selfissue: problem is you will have to handle this special

agl: delete the paragraph that says everything has an output.

selfissue: I will work on this

tony: tag it on the #1445

selfissue: OK

elundberg: can we go back to PRF?
... that has the same issue

agl: does mike has an opinion
... I will go back and adjust

jbradley: where are we at with Dirk's payments proposal

jeffh: we have to work on this

tony: this is new feature. we are feature frozen

agl: dirk not sure that this works at all

jbradley: it may be FIDO European group

agl: I don't think we should make an exception on this

jbradley: we likely need to at least keep people in the loop

jeffH: this WG should work on this general topic, don't think it gets into Level 2

<jeffh> jeffh: tho dirk now has web use case input

tony: best thing to do is get an issue opened and then we can look at it and make decisions

jeffh: sure

selfissue: I want to talk about 1441
... some missing normative guidance, i propose to add normative guidance. add those we are adding from FIDO2

Signature Formats section https://w3c.github.io/webauthn/#sctn-signature-attestation-types

<jeffh> https://github.com/w3c/webauthn/issues/1441

jbradley: since we specify the algorithm and not the curve, it does not prevent things from being added.
... I will look at the issue.

tony: anymore?

jeffH: we still have 22 issues for Wd-03. And several are old. We won't deal with them
... we need to side what we are going to punt on
... a bunch of the editorial stuff is not going to get done.
... I don't think we have time now, i can make suggestions

elundberg: maybe talk about eliminating duplicate terminology

jeffH: should we just close?

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

jeffH: we can eliminate. adding comment
... OK, one less issue

agl: update for akshay. there is nothing about number of attempts.

tony: adjorn

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version (CVS log)
$Date: 2020/06/24 19:51:07 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision of Date 
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: wseltzer jfontana Nadalin elundberg jeffh jeremy selfissued gavin bill akshay agl Jiewen Eric nsteele
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/2020Jun/0209.html

WARNING: No date found!  Assuming today.  (Hint: Specify
the W3C IRC log URL, and the date will be determined from that.)
Or specify the date like this:
<dbooth> Date: 12 Sep 2002

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


[End of scribe.perl diagnostic output]