present

<wseltzer> nadalin: Level 2 Draft 1 has been published, https://www.w3.org/TR/webauthn-2/

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

rolf: waiting for review

tony: rolf do want to review

rolf: yes

elundberg: how does this help

rolf: new, how does web browser pass assertions through

elundberg: what happens when UAF response comes back

rolf: it depends on how you see. now describing GET assertion
... mans UAF is already registered

elundberg: OK. would also require different implementation from RP

agl: since chrome likely wont do this, we might specify format
... but probably not going to fly

lost Tony

<elundberg> akshay: how would the browser communicate with the UAF device?

<elundberg> rolf: the UAF device will speak CTAP

<elundberg> ...BLE with smartphone authenticator to desktop browser for example

bradley: the phone will let you be ctap provider to another device

rold: yes.

bradley: won't that get confused

rolf: if phone supports ctap that is fine, so no need for another interface.

akshay: I have a simliar issue. I pass and parse , then how do I pass it apporpriately

agl: you are proposing a ctap authenticator that does not follow protocol

rolf: the assertion is just slightly different.
... if different we have to flag that. and that is what this PR is trying to do.

tony: so it is just passing this through

alexei: we have said browsers have to understand extensions. do we remember

rolf: those things are not written in the spec

akshay: what is in the spec, not asking for an extensiond, don't return
... possibly we can say it is a UAF extension.

alexei: if we use extensions, browsers should not blindly pass through.
... this will become way to get things through browser
... either fully define or pass through - that is scary

agl: do we pass through without structure

jcj_moz: seems bad to mozilla, we don't want to pass things we don't understand.

agl: you already do.

jcj_moz: we strip attestation by default

alexei: because one source of leakage, we should create more

agl: but this is already the case. we threaten them at time

bradley: I am skeptical this will catch on
... it is a fair amount of work
... putting it in a extension isn't very much harder

rolf: revise making it an extension rather than full assertion

jcj-moz: maybe
... saying this could be some other assertion, where does a user of spec go to learn the full amont of things they request of use

rolf: make it binding and the idea is to only mention UAF here. that reference has been added
... I heard concern in supporting new arbitrary assertions

jcj_moz: if it were extension we would have to define actions

rolf: that is the other alternative
... we can specify new extension, this is UAF and get back an assetion in correct syntax

bradley: there are UAF extensions that are not in web authn

rolf: at this stage. i would happy if we only had extensions in web authn world and not add new ones

selfissue: what are we trying to achieve.
... no UAF devices that use web authn today. right
... we would need to write and deploy new code. then why not return FIDO2 assertion

rolf: the assertion is something you could do on a software level
... use support in web browser

selfissue: all the web authn client code would be needed
... i am against doing this at all. we made a decision not to do this

rolf: i think there is one use case , where cleint is on one device and UAF sits on another device
... there is a web authn stack
... that speaks ctap

selfissue: but this is not an easy eco system change to update every web authn client
... that is horrible thing to do
... get a software update to get them to talk web authn natively, not change all web authn clients.

bradley: what phone would this work on. Android has a platform with principal support. is it for old android phones
... are we talking 100s of phones or 10s of phones.

selfissue: that really matters. i am adding note that this is bad for eco system and we should not do this.

bradley: i don't understand who would do this.

tony: rolf could you come back with some more information. and how to enable.

rolf: yes.

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

akshay: need ctap stufgf

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

akshay: this is for me. I will look at it.

https://github.com/w3c/webauthn/pulls?utf8=%E2%9C%93&q=is%3Apr+is%3Aopen+1219

alexei had some comments

agl: I think more webby people will have issues with this

akshay: we write once and it works is where we are.

agl: i understand the motivation. makes sense. what are we going to do to move forward
... can we make the call ourselves.
... yes.

akshay: I would propose to add one more API, say what issues are

alexei: looking at comments now

akshay: debating on best way to do this.
... think this is best

agl: want to avoid collision with our web people. how about I point them to this and see there reaction.
... if no one kicks up a fuss,....

wseltzer: you can raise an issue in the TAG on that question. that is home for design, architectural issues

<inserted> TAG repo for design reviews

tony: any more discussion.

alexei: I will post my questions.

tony: we could do it now

alexei: wants to drop language in regards to transports

this is ctap2

alexei: we need meaningful statements, what things do.
... if it is there it better be user verifying
... I don't understand why these transports are there.

elundberg: if you have BLE transport , it doesn't say anything about device.

bradley: i think intention was to turn off ctap

alexei: we need a crisp case.
... I don't get it.

akshay: we can do that.

alexei: and then another one. is UV supported.
... why do we need that plus UV platform authenticator

akshay: one is for external devices.

alexei: trying to understand particular parameters.

akshay: let me list all the questions we are looking for

alexei: that is good to do
... then we know motivation

elundberg: adding this. would this invite fracturing the eco system
... would be excuse not to support all the parts of the spec

jcj_moz: this makes it easier for those that want to use user agents.

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

elundberg: editorial
... first step toward PR 1223
... jeffH take a look

tony: jeffH and mike look at it

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

editorial

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

tony: tied to 1122

elundberg: also editorial. adds language to spec

agl: there is change in ctap2 that requires key never leave authenticator
... we have to do something about recovery at some point

eludnberg: I'll keep it at hand wavvy.

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

elundberg: this is guidance.

jeffH: I have pointed web authn list to the 1230 discussion

agl: i think this is good and we should do more to clarify this extension

tony: we will meet next week..

adjourn

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)

Succeeded: s/gub//
Succeeded: i|any more discussion.|TAG repo for design reviews
FAILED: s/<... addccccccekcfhrbhkhhbleebkrjvrhvjhcifkvldctjh>/<Bradley:>/
Default Present: wseltzer, jfontana, nadalin, elundberg, akshay, selfissued, rolf, jcj, agl, alexei, jeffh, nsteele, jbarclay
Present: wseltzer jfontana nadalin elundberg akshay selfissued rolf jcj agl alexei jeffh nsteele jbarclay
No ScribeNick specified.  Guessing ScribeNick: jfontana
Inferring Scribes: jfontana

WARNING: No "Topic:" lines found.

Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2019Jun/0028.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.)