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

tony: still on hold. waiting for CTAP work

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

akshay: I am working on it.

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

jason: have made improvements

agl: if people are happy, we can go forward with this

jason: any emails or comment

agl: I don't recall anything coming up

tony: jason, when do you expect this to land in WD-02

jason: hope is for 02

tony: emil do you still have concerns with this?

elundberg: minor
... before it seemed the resident key part had a client issue and if the client supports showing cred pick list with external resident keys.
... would it make sense if these were two things

agl: one could support a platform that supports resident keys and external could not.

akshay: we could make it two separate things

agl: you want to nail down what the resident token means

jason: that is fair

shane: one reason confusing, the scenario is not clear

akshay: certain browsers can not do this in sertain OS versions
... we can get in done in future, not today

shane: some user experience

akshay: we will have updates in the next versino
... I want only resident keys and I don't want a fail if certain resident keys don't work

alexei: can you explain more

akshay: UV covers both built in and client pin.
... we don't have place where we say you will support client but not resident
... I have users with only PIN, does the browser support it.

alexei: my question, what is the error if we dont' add this capabilityi

akshay: user has gone from clicking link to seeing it does not work

alexei: when you click link what if it returns message it does not work.

Bradley: if you had like some versions of chrome you refuse to allow a get without an allow list, you can't use a resident credential
... there may be states where you have a credential that is not useful
... I wish all browsers would implement the spec fully, then this problem would not exist.
... hopefully browser vendors are not going to end up with mis-matched features..

akshay: I am solving one problem. on some versions of firefox I can't show a link...

alexei: we do this a lot with security key, we tried path of not showing secruity key. they are confused.

akshay: I agree that is a good point

alexei: what happens if we don't have this API, what will happen when users click.

akshay: it can fail

alexei: would it be any different with or without this API

shane: trying to do detection on other things.

akshay: say you want resident keys and UVM, if it fail immediatley, maybe you don't want it.

alexei: this is about browser.

akshay: maybe we say you do this and if it fails it is returned immediately.
... user have external security key with a PIN, if UV is required, from browser it does not know what to do because they key has yet to be plugged in.

shane: seems to mean this idea is here because on inconsistency in implementation
... wouldn't it be good if this goes away

akshay: that is optimal. but for time being can't do these things on safari, firefox

tony: what do we do.
... still some push back. non-agreement
... no hurry to close this unless there is some agreement on this

alexei: can I have another week to think about it.

shane: seems you are going to have to deal with edge cases.
... you have to deal with this issue anyway.

bradley: can we do the API faster than implementing the feature, i don't think we can say that.

tony: needs further discussion?

akshay: yes.

tony: put this on hold, and wait for JC

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

jeffH: I will review today

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

rolf: I don't have an update today. can I get another week.

tony: yes.
... if not we will move it to a future version
... OK

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

jeffH: let's merge. I reviewed it.

elundberg: I will merge it.

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

tony: I think this is out of scope
... we have viewpoints on this in the issue
... if there opposition to close this one.
... with no action
... or push it to level 3

agl: we are happy with status quo

akshay: I will close

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

elundberg: goes with 1219, i'll put it in WD-02

agl: we can defer this, involving finger prints is new

elundberg: maybe 1219 does not solve this if you reduce scope

akshay: this PR will not solve this issue

elundberg: keep in wd-02?

tony: does not sound like we should keep

akshay: let's look at it more and figure out what to do with this PR

tony: has you change 1219, look at 1218

akshay: we have preposed this. best to discuss next week after people look at 1219

tony: OK

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

tony: this looks like a breaking change

jeffH: he seems to be asking for allotcating for future use.
... I am abotu to respond to say this is better dealt with in the FIDO Alliance

shane: I think you are right about this is dealt with in CTAP

agl: not sure what this is asking
... we will never use them

jeffh: there is that argument, too

akshay: in a way you can do everything in extensions, but this more FIDO thing
... even if we run out we can do it from an extensions point of view.
... wha tis the use case.

agl: we took one place to say here is a place for more bits.

jeffH: I put in comment to summarize this discussion.

tony: we can close this one. move.

shane: close

akshay: it is a none issue

jeffH: it is closed

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

tony: there is nothing we can do.
... it is not affecting the spec.

agl: this group does not provide a reference implemtation.

tony: agl state that and close it.

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

elundberg: promoted by a question in Chrome Users

tony: we don't typically proivde this typel of guide

elundberg: there is no clear path forward here. I will look at it.

jeffH: they are misunderstanding the taxonomy table
... we could add some context.

tony: we will keep it around and look for progress.

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

agl: nina is working on this.

jeffh: no way to wire up automatic tests. there is shim of stuff for the browser, send it into browser code, Web driver tool can simulate authenticators
... have a draft for text for web authn spec. need to review and open PR
... I put this at L3
... it might go faster on L2

tony: put at L2 and punt it if not coming along
... we are out of time

adjourn.

co-chairs Nadalin, Fontana

<scribe> Meeting: Web Authentication Working Group Teleconference

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: jfontana, jbarclay_
Present: jfontana jbarclay_ nsteele
No ScribeNick specified.  Guessing ScribeNick: jfontana
Inferring Scribes: jfontana

WARNING: No "Topic:" lines found.

Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2019Jun/0179.html

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


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