W3C

- DRAFT -

Web Authentication WG

03 Jun 2020

Agenda

Attendees

Present
nmooney, wseltzer, elundberg, agl, akshay, bill, davidturner, jeffh, nadalin, nina, selfissued, eric
Regrets
Chair
Nadalin, Fontana
Scribe
wseltzer, jfontana

Contents


<wseltzer> scribenick: wseltzer

SPWG update

akshay: joint meeting between biometrics, SPWG, and @@
... mostly about timelines

Open Pull Requests

nadalin: 966

akshay: no update yet
... TPM specs are hard to read, but not WebAuthn's job to demystify
... propse we close this

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

nadalin: any objection to close?

johnbradley: ok if nothing else is caught up in the same PR

akshay: nothing is

nadalin: Close 966
... 1300

agl: It's turned into the how to FIDO doc
... so close 1300

nadalin: 1330

elundberg: I'll take another look

nadalin: 1402
... needs jeffh and akshay to look at it

agl: web exposure of largeBlob

[aside on large and small blobs]

<jfontana> OK

<jeffh> see also: https://en.wikipedia.org/wiki/The_Blob

nadalin: 1420

<jfontana> https://github.com/w3c/webauthn/pull/1420

<inserted> scribenick: jfontana

tony: mike jones have you looked at it
... bradley

selfissue: I will read

bradley: i don't think we have anything right at the moment to fix it

selfissue: I will approve now.

tony: merge it

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

agl: not ready to land, added comments from last week
... exposeing HMAC secrets to the web - we quite an amount of wrapping

akshay: I have not looked at it.

tony: would google implement this

agl: yes, maybe too late. we may expose for extensions before we are done here.
... there are people who want to encrypt stuff with security keys

akshay: I support this

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

bradley: done

tony: needs approvals.

selfissue: I will do it right now

bradley: the examples are now correct.

selfissue: merged

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

tony: recovery extension
... do we work on this? where does it fit in schdule

elundburg: catching up on comments.
... how do you feel about this going forward. quantum concerns?

agl: could work with quantum. AAGUIDs a concern for us. not that complecated - if there is demand we could plumb it through
... pairing and other stuff makes it more complicated.

elundburg: there will some stuff to do on the RP side.
... that is a concern

bradley: on aaguid, we are not deeply wedded to that.
... knowing the backup authenticator at the same time is an advantage.
... could evaluate right there.

agl: if that was tied into CTAP in certain ways, we could maybe go there.

elundburg: this happens during a get call
... maybe you could add parameters to this as well.

agl: difference here, its an assertion, if we can control it
... narrow concerns here are addressable, wider is another story

bradley: is there a better way, or combos in other ways.
... we want a way

dwaite: could the aaguid mean client collected data rather than direct response from the key?

tony: still have issues in FIDO land
... it looks like Yubcio has motivation to get this is level 2

bradley: not sure of that. we need it around to experiment with it. Level 2 seems abitious

tony: un-triaged for now

bradley: sure.

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

jeffH: there are a couple of cleanup things I suggested. I want to get to those

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

Nina: this is fine

tony: I will put you on the reviewers list
... takes us through PRs
... issues

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

tony: leaving this open

elundburg: don't need to assign this to any milestone, just some questions.

<nina> (merged https://github.com/w3c/webauthn/pull/1432)

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

elundberg: looks like the are saying CTAP is inconsistent with web authn

bradley: I will have to look at this

selfissue: with this, are there different names that do not match

jeffH: need to look at this and figure it out

selfissue: so what is this about

akshay: this may be mismatch. doesn't say have to do cred protect.

elundberg: we'll look at how this is implemented in YubiKeys

selfissue: I think this not talking about a key

jeffH: what is called the entry key, includes name of the extension in the object
... think term entry key is vague.

elundberg: I will look into this.

tony: I want to go back to #1396

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

scribe: I thnk there are problems here.
... thoughts
... is this a problem? or is this being forced on this group?

bradley: lots of people trying to force this around transaction confirmation
... interest is in payments, there is use confusion

tony: I think people want to use it for other things.

bradley: they don't seem to understand the issues that surround this

tony: thye want a general signing mechanism.

bradley: and they want it displayed.

jeffH: there is some liability shifting

nickS: this feels like it is being pushed on this group

bradley: most of the first party cases, is around the web browser security
... hard argument to make
... I don't buy the three party use case.

jeffh: ideas the payment handler could do this.
... and you can hash in the challenge, and you wouldn't need to change anything to make that happen
... but in discussion I've been it, there is some distrust with the payment handler

tony: this is not a first party thing.
... we can look from a three-party angle
... this could be done by the payment handlers, do we feel this group is going to do something to help.

bradley: what are the browsers willing to display
... we could look at this and other things later.

tony: still not hearing what we want to do
... we owe an answer on this

bradley: need agl and JC to weigh in on this

selfissue: how do we display?
... it doesn't sound like we have general purpose solution to this.

tony: this is something that we are interested in or not. then work on specific proposals or not

selfissue: is there someone to write it.

tony: Visa may be the only champion on this. can leave it out here. It is getting attention, so I think we need some answer

bradley: we need to continue with the web payments folks

akshay: can we narrow it down to one problem, instead of all the problems?

tony; AOB

tony: AOB
... adjourn

chairs: Nadalin, Fontana

*web page updated with minutes

rrsagent: draft minutes

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/03 20:16:31 $

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)

Succeeded: i|tony: mike|scribenick: jfontana
Default Present: nmooney, wseltzer, elundberg, agl, akshay, bill, davidturner, jeffh, nadalin, nina, selfissued, eric
Present: nmooney wseltzer elundberg agl akshay bill davidturner jeffh nadalin nina selfissued eric
Found ScribeNick: wseltzer
Found ScribeNick: jfontana
Inferring Scribes: wseltzer, jfontana
Scribes: wseltzer, jfontana
ScribeNicks: wseltzer, jfontana
Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2020Jun/0019.html
Found Date: 03 Jun 2020
People with action items: 

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]