W3C

- DRAFT -

Web Authentication WG

02 Oct 2019

Agenda

Attendees

Present
nmooney, jfontana, jbarclay
Regrets
wseltzer
Chair
nadalin, fontana
Scribe
jfontana

Contents


<wseltzer> present=

<scribe> Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2019Oct/0000.html

tony: start in on pull requests.

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

akshay: stiill working on this

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

tony: good to go:

nina: yes.

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

tony: this is still over the Cred Man

akshay: I have not looked at it.

jeffH: this is queued up.
... I have work underway in cred man on this

tony" done?

jeffH: about half way.
... this is pretty simple, do the feature policy thing in web authn. The work is in cred man
... if it came down to it, we could punt to wd03
... depends on wd02 timing

tony: trying for end of oct. for wd02

jefH: we do need to update w2o2
... wd02

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

tony: akshay?

akshay: not yet

tony: did emil fix all the suggestions here?
... review and mark them off.

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

tony: mike opened this up.

jeffH: I just suggest a polishing of the paragraph

tony: mike you OK with this

selfissue: I will read them

Tony: do you want to look at it again after mike

jeffH: yes, .

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

tony: JC needed to do a PR
... i'm looking at technical issues.
... the rest have Jeffh's editorial name on them
... so this is on hold.

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

akshay: I will be back on this next week

tony: come back with a PR if you have something concrete.

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

agl: any consideration in the past weeks

tony: nothing

agl: I will do a PR and others can tell me if it is done.

jeffH: did we discuss in Japan

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

shane: i will create a PR
... I will chat with alexei

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

jeffH: JC is assigned.
... we did land a web driver test.
... JC needs to look at it.

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

agl: were people happy with this at the face to face?

tony: JC was tagged for a PR

agl: iframe support?

bradley: answer is yes, but firefox said it would not happen. so need to look else where for delegation

agl: is one pixel visible

bradley: firefox and apple said it needed something visible or it would be blocked

agl: how will the technically enforce
... if these problems were easy to fix it would not be a problem
... this is a can of snakes to me. have to see what PR is

bradley: in broswer vendors want to block, maybe we say don't try this

agl: in practical sense what works will ship
... other browser vendors mayors want to fight it

bradley: we will have to look for alternative for some payment use cases. Maybe messy

agl: I have not gauged the payment folks.

bradley: the top level won't be affected by this, this some PSD2 use cases

agl: this looks like can of worms, but lets deal with it

jeffH: lets see what JC has to say.
... there is proposal on web payments work to generalize the modal dialogue for these use cases
... but that looks like top level browsing, maybe better for them than embedded i-frame
... could turn out to be a non issue

bradley for browser that may be the delegation answer for native apps

bradley: it might be a way around some of the iframe restrictions . cookies, etc.
... won't be liaison between FAPI and web payments
... that happened on Monday.

tony: any more discussion

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

agl: this was sorted out at TPAC

akshay: thought JC was looking for simple API parameters

agl: I understand apple's motivation here, have sympathy. don't know what the answer to that should be.
... i will work on #1300

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

bradley: leave it now, but evaluate in the future. apple thinks "lightning" name should eventually go

tony: lets see how this progresses

selfissue: close and open later?

bradley: they might do something, so leave it now

jeffH: I will look at this and write something on it.

<elundberg> !present

jeffH: they understand we need this around for now

bradley: with the latest vesion of iOS it might not be required anymore

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

agl: this is not true, but there is note in spec that needs to go

bradley: it is confusing

elundberg: it is not very clear on if authenticator is single user or multi-user

christiaan: the authenticator is always single user

bradley: does apply to windows hello, but can't prevent abuse.
... we're making an assumption, but can't say users are acting in their best ingterest

elundberg: maybe be we should spell out clearly

bradley: say no defense of friendly fraud, can't make guarantee
... that's what we are hearing from payments guys.

elunberg: also realted to if you register without UV and then ask for UV

christiian: asl ong as UV is set up when credential made

eluncbverg: not what I said. we should clean up

christiaan: if you try to use UV you should get are error back
... is there UV when the authenticator was set up

bradely: this is probably a CTAP change

akshay: user has ownership

bradley: right thing to do , is if you want UV later on, you should ask for it at set-up
... deal with this and other use cases.

tony: what do we do here?
... move forward, anyone.

elundberg: we want to remove the note
... I can do that
... any concrete action we want to take?

bradley: we should think about if we want authenticator to create an error.
... we should go one way or the other.

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

agl: if CTAP spec was public we could explain this

tony: so keep it open?

agl: we could close it because we are not doing anything.

jeffH: talking 1306?

tnoy: yes

akshay: we can mark it level 3?

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

tony: this is jeff?

agl: I don't know how to clarify this
... clarify this diagram

tony: close no, action

agl: I will add, say this is definition of relying party. and close with no action

jeffH: we don't define.
... I would say in note you will write. say relying party server is not well defined it is pretty clear.

elundberg: maybe add something about RP, definition is abstract.
... I can thak this.
... take this

jeffH: lets leave this open and clarify with a note.
... what elundberg will do.

tony: that takes us through the open issues. anything else to discuss?
... lets close and see you in a week

rssagent, draft minutes

rssagent, make logs public

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/10/02 19:48:08 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Default Present: nmooney, jfontana, jbarclay
Present: nmooney jfontana jbarclay
Regrets: wseltzer
No ScribeNick specified.  Guessing ScribeNick: jfontana
Inferring Scribes: jfontana

WARNING: No "Topic:" lines found.

Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2019Oct/0000.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]