tony: calls meeting to order
... agenda topic Charter

<wseltzer> Current charter

tony: will run out of time september 15, likely only close to closing out L2, but not into recommendation
... we have to think charter extension
... would have to go to TAG for extension

<wseltzer> [not TAG but Advisory Committee]

tony: short extension likely won't get us to recommendation.
... how short is a short extension, wendy?
... two year or one year

jcj_moz: are there plans for Level 3?

tony: we don't need to do one, it is the group's decision

akshay: what is difference. short and long

tony: time

akshay: we are saying L2 will be feature complete. seems like we should use caution and no rush. so extend

jeffH: akshay is arguing for longer. General support for extending

agl: the pause and reflection. and then a better account recovery story.

shane: I have no problems.

no problem

jcj_moz: get this out the door and see if we have . credible story around account recovery

tony: sounds like we need longer extension. so we have wiggle room.

jcj_moz: if we don't have a credible story. I don't see us working on the cryptography here.
... I know it is pain to reform a group, but may be easier to do it that way.

wendy: as a matter of w3c procedure, recharting goes to advisory committee for review
... we put in what we anticipate the group can do, and things are in scope.
... if the group pubs. Level 2, other options are still possible.

akshay: I feel all the relevant people are here , I think we can come up wit the solution.
... lets get Level 2 out. Maybe then we have less frequent meetings.

tony: hearing consensus to shoot for a longer extension and then see if we can do account recovery
... probably would add L3 doc, account recovery and that is all the changes we would make.

akshay: also includes back-up

tony: yes.

nick: would we have a separate working group?

tony: didn't sound what Akshay was looking for.

jcj_moz: concerned that any solution here will want some formal methods
... are charter says we are not ding low level stuff.

jeffH: reasonable to point out, but we could still go after the general problem here and involve the other groups on an as needed basis

jcj_moz: as wendy pointed out, we can reduce how often we meet.

tony: so lieave in out of scope stuff in the charter.

jcj_moz: if we take that out, I feel like I am the wrong person to rep Mozilla

<jcj_moz> elundberg: Thyla van der Merwe

tony: any other documents to provide if we do extend?
... nick do you want to see more.

nick: I am underwhelmed with some of the FIDO account recovery stuff. having some guidelines in the spec would be great.
... would like to have a better story around roaming mobile authenticators.
... want to consider multiple transports.

<jeffh> UL labs?

nick: we are thinking about a network based transport

agl: we are thinking about this, but not at liberty to say how we view it.

nick: what is main concern.

agl: it is the guarantee the authenticator near machine, but if we run that over network that is a different sort of thing.

nick: I don't think bluetooth proximity comes with unphishability. If there is way we can maintain unphisable properties over transport, we will explore that.
... I think people will opt for usability.

agl: if the exosystem degrades in that way, we have to ponder on that.
... but over network it is not webauthn at that point,

nick: i agree
... but want to look at main authentication being delegated.

tony: looks like we have until end of July to get agreement on updated charter and start process
... any other charter discussions?

none heard

tony: lets go back to issues.

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

tony: still pending.

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

tony: low priority and not ready to go yet.

jeffH: this can go to L3

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

agl: I think it is great.

akshay: i have to review this.

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

elundberg: I'm sure mike jones would say everything needs an output.

jcj_moz: adding to capability detection. it is an order of operation

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

tony: needs a look from akshay and shane

akshay wants to talk about #1219 https://github.com/w3c/webauthn/pull/1219

akshayL Alexei wanted to talk about this.

agl: alexei said he was fine with this.

akshay: so let me look at his comments.

agl: strudture is fine, nedd to anil down meaning of strings.

jefH: add a comment from Alexei

akshay: will look into it.

tony: go back to #1249
... waiting for review

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

tony: does anyone else want to review

agl: I had a few comments here.

jeffH: looks good to me.

tony: anyone?

rtony: merge #1254

jcj_moz: sure

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

tony: this is from the new member.
... should we wait for her next week.

jeffH: but please review.
... with this yo have to understand the Web driver spec

akshay: taking a look

jcj_moz: our expert is on pto for the next two weeks, but we will look .

tony: so keep this one open and get reviews.

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

tony: we should get this into wd-02

elundberg: I need to read jeffH review.

move to issues.

tony: look at issues without milestones. #1251

aglo: we can not accomodate this

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

elundberg: you could have check to see if there is a current credential.
... could add that. but also could say not worth the effort.

agl: RPs should know if what will work and what will not

jcj_moz: I will look at this. definitely lean on the privacy side.

jeffH: part of the issue. spec does not distinguish initial sign in and re-authentication

jcj_moz: does that kind of knowledge belong in this spec

jeffH: in terms of non-normative notes.

,..go back to issue #334. that is some of the use case destinctions.

tony: do we want to leave this un-triaged?
... or people need to do more before assigning a milestone.

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

akshay: close it.

tony: this is not within our charter

agl: not outside charter and not crazy request.

elundberg: should be possible with not too much effort, but do we want to?

shane: there is one right way to do things
... this is moving forward from the goal.

jcj_moz: this feels a lot like key-gen, which was pulled out a long time ago.
... this is not unreasonable
... this only makes sense if we abandon javascript and go back to tags. seems unlikely

elundberg: has to be actively supported by RPs for this to make any difference

agl: we don't want to do it, because RP would have to switch to a new API

jcj_moz: i fwe could get a consensus of RPs to do this, then maybe I would change my mind.

agl: nobody is standing up and saying they will make this happen
... so we should likely close this.

jbradley: good for humanity maybe, but way below our priorities.

tony: I will put this on Level 3
... lets have FIDO talk about this.
... any issues that we need to get to this week

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

agl: RPS don't seem to understand here and the default is tripping up everyone.

elundberg: I see akshay was against.
... this does bring up again discouraged and in-different.

agl: on thing we are pondering is having a dev. tool. you could set explicitly

jeffH: we are proposing in Level 2 is to set to discouraged.

agl: that does match what RPs imagine it will be.

akshay: give me a few days to get back into this.

shane: can we look again at

#1149

akshay: we need Christiaan here

christiaan: I am here.

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

Christiaan: I was taling about resident credentials. do we need to re:start the conversation
... make a credential, but not ask for pin

akshay: it was this way orginally. but new devices, you don't require a pin. most FIDO authenticators do this
... for newer fido devices, that behavior will change and platform will adopt.

christiaand: will it.

jeffH: there is PR to check #624

christiaan: I am fine, we no longer will require a PIN.
... asl long I can create a cred that functions how it functions today in FIDO
... I am happy.
... we need to make a notation. if you wnat U2f like behavior thisis how you sest these three things.

<nsteele_> thanks

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/make sense/make any difference/
Default Present: wseltzer, jcj_moz, sbweeden, nadalin, johnbradley, elundberg, akshay, jeffh, loud-typist, agl, jbarclay
Present: agl akshay elundberg jbarclay jcj_moz jeffh johnbradley nadalin nsteele sbweeden wseltzer
No ScribeNick specified.  Guessing ScribeNick: jfontana
Inferring Scribes: jfontana

WARNING: No "Topic:" lines found.

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