<scribe> Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2020Feb/0035.html

Meeting name: Meeting Web Authentication WG

tony: face to face next wed.
... make sure you register
... Nick will send out note with WebEx instructions
... I have been working in ISO land, request for PAS submission SE17
... as far as I undestand as log as WG agrees we can make this submission
... it is one way, we still have control .
... PAS is a publicly available standard.
... so they can reference it in other specs
... they also want to use CTAP, for mobile drivers license specs
... for readers.
... they want to be able to use FIDO authn for their purposes and need to reference an ISO document
... this would be a ....we can ask for it to be a free standard.
... this is not going to be any different...

wendy: we have copyright and change control on the doc. it is giving it an ISO number.
... can still get it for free from W3C
... ctap will be addressed in FIDO land

agl: for CTAP we will need to work with translators, a lot of nuance to understand

tony: is there any objection to proposal to start PAS submission
... any objections. just need consensus
... no objections, wendy we will contact yo on starting this process
... any other questions on F2F or PAS
... move to PRs

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

akshay: let me review and I if I approve I will merge it.

tony: yes.

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

jeffH: I am working on that.
... I have comments from IANA
... I will get this dealt with before next IETF

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

tony: jeffH will take over and look at this

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

elundberg: I thnk this is review.

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

akshay: can i talk about #1333 again
... we re looking at remote desktops and those scenarioes
... use FIDO keys
... there is also some info. around proximity , any comments on remote pieces

agl: chrome remote desktop only supports security keys
... the attacker has to have something physically compromised close to the user.
... we noodled with putting something in client data json

aksay: I am fine with the changes and I approve this and I can merge

agl: at most it says consider the effects.

tony: issues.
... untriaged issues first

agl: #1370, write a PR

shane: #1372

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

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

shane: the history to not being facet IDs forward, pre-dates me
... to not bring forward
... is there resistance from the browser vendors.

jeffH: there is nothing standardized.
...dwaite: this is not http post
... lets you share data between windows

jc_moz: can pass back resulting attestation
... we didn't do facets for the same reason the domain boundaries WG at IETF did not have an answer

jeffH: we can take that offline

agl: we are saying iframes available behind flag and we want to know why they are not efficient.

shane: cross-domain trust mechanism is something we prefer

jeffH: if there was way for onee party to generate credentials and second party can validate...would that solve your use case.

tony: web auth and web payments discussed this today
... yes, wait for what they come up with.

christiian: iframes is a web construct
... we think the iframe we have done will be of great value

shane: my question is different

tony: payment guys are saying this is inadequate at this time.
... some of the fintechs have issues.
... my suggestion is to leave this open and see what comes from fintechs.
... and banks

agl: need details on why they cannot use iframes

shane: one thing is RP deployment complexity.
... didn't say it wasn't possible, it is a complexity issues. complexity is undesirable

jc_moz: we might have to invent a new mechanism

tony: leave this untriaged until we have another meeting with payments people.

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

shane: take browser vendors as authority on this one.
... if there is no movement on UV extensions, or see them implemented, why include in spec

agl: we do support UVM on android, but lot in the specs no one intends to implement

shane: we have dropped some things based on our practical knowledge
... someone coming to this may think these things are available and that might not be the case

agl: I agree that some of these can be dropped

jc_moz: would be nice to do a simplification pass
... I have not gathered consensus

agl: we might find objection if things start dying off
... current wording might be a doc that has what people want to see from their prespective.

nick: either delete or delete this issue

agl: will someone make a PR then leave open, if not - close

dwaite: I would look into a PR

nick: maybe wait for the face to face.

jc_moz: can we put this one the agenda for next week.

tony: yes.

jeffh: #1373 is not about this, there is chrome issues and UV extension, I think we should close issue

tony: we can close and next week discuss a purge of issues.
... are there other issue we want to discuss

agl: I say IP addresses
... #1358 is the issue

akshay: we should consider this behind a flag to test it out.
... but I don't think user willl understand

agl: we think the spec says they are not allowed and others say that, then this issue should close

jc_moz: we need web platform tests.

agl: jc will you write the tests.
... nina might want to help

nina: I would be glad to review

agl: i will do doc pull requests if you do tests.

jc_moz: Ok
... i will mark that this needs a web platform test.

tony: agl what do you want to do about #1363

agl: seems like nice idea, not currently a burning priority.

tony: keep it going
... ?

agl: leave it open for now, and let someone come along and look at it.

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

tony: this is waiting to be addressed

akshay: some RP the other day was trying to find out how it works
... people are looking at it

agl: I see that people are looking, but what do we do

akshay: another thing we are hearing about is what do we call it.
... not sure the right answer.

jc_moz: maybe this is something we should push to the authnticator, sounds easier to get it done that way.

akshay: i have seen this come up as a requirement. see what we can do here.

jbradley: joins the call
... I will make the three word change on #1354

tony: any other issues.

jbradley: I have one that came up on web authn - web payments call
... residential vs. discoverable credentials.
... does not seem to differentiate

akshay: I have replied on this one.
... we did not have discoverable at that time.
... what is RP trying to do.

jbradley: the spec allows any authenticator to make creds resident and discoverable.

agl: we have tighten it and CTAP, it is #661 issue

jeffH: we are using multiple terms.

agl: resident has an overlap with stateful, discoverable is more what it means.
... current CTAP spec if a mess on this

jeffH: resident and discoverable is what we have now. needs cleanup

jbradley: need to say if RK is not true than the key is not considered resident even if it is stateful

agl: hope #661 clears this up.

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/is/is not/
Succeeded: s/aying/saying/
Default Present: elundberg, jfontana, jeffh, nsteele, wseltzer, jbarclay, nadalin, akshay, davidwaite, davidturner, jcj_moz, Jiewen, johnbradley, sbweeden, christiaan, agl, mikejones, nina
Present: elundberg jfontana jeffh nsteele wseltzer jbarclay nadalin akshay davidwaite davidturner jcj_moz Jiewen johnbradley sbweeden christiaan agl mikejones nina
No ScribeNick specified.  Guessing ScribeNick: jfontana
Inferring Scribes: jfontana

WARNING: No "Topic:" lines found.

Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2020Feb/0034.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.)