<elundberg> scribenick: elundberg

<jfontana> test

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

nadalin: talked to jeff, no movement on this
... stays as is for now

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

nadalin: discussed this a bit, jeffh and selfissued working on it

<jfontana> tony: not seeing any decisions

nadalin: no decision seems to have been made

<scribe> scribenick: jfontana

got it

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

tony: most of this will likely take place in the FIDO group, don't think this is major hit for us
... do we want to wait on more CTAP2 progress

akshay: want to wait. no implementations besides Google. Only for certain accounts, however.
... wait for some clarification on passwordless.
... there are open questions around passwordless. I would wait

tony: sounds good

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

jcj_moz: I will take a look

tony: akshay can you take a look

akshay: yes.

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

tony: akshay to look at? this is editorial
... JC and Adam have looked at it.

akshay: I will look at it today.

tony: emil can you merge today after it is looked at.

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

tony: has anyone looked at this yet.

jcj_mox: it is editorial
... not sure we merge this now, the pointer to this is bad.
... we want to wait for the valid link

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

elundberg: this is for issue #978
... this doesn't add any security over no attestation

jcj_moz: can ctap2 provide a non-attestation

akshay: no
... in terms of self attestation. does not block malicious act

shane: provide it is not a malicious act, you can't signal to user the authenticator in use

akshay: to clarify what is self-attestation format

jcj_moz: it has to be packed or something else. that is a google question
... I think the change is legit. we should not mandate authenticator return some type of attestation
... changing this to should does not affect anything right now
... I think this a good change.

elundberg: it is a consistency thing.

jcj_moz: it does not change anything functional today. I approve of this idea

tony: this would be a change...

jcj_moz: this is changing a must to a may

elundberg: just relaxation of requirements. anything compatible today will still be compatible.

tony: agree. but it something authenticator may do in the future.

jcj_moz: this group is not tied to CTAP 2. so this opens for a different transport that does not have attestation

tony: apple is not supporting attestation

jcj_moz: Firefox makes a new cert each time...and web authn strips it.
... but it is compliant

akshay: now thinking. it is not a good option either way

jcj_moz: from a strict spec reading sense I would say yes, but under the covers I could strip out attestation
... it helps a future involved party to spec, non- attestation was worthwhile
... we think authenticators in the future should treat this as a legit form of attestation

tony: i don't think these are the same.
... if stack is software only. I can do self-attestation and get some information....

elundberg: but no RP can depend on the info.
... this does not prevent self-attestation. it is just you don't have to implement if you don't care about it.

tony: that takes us through the PRs for the first working draft.
... now lets go to issues.

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

tony: Kim was assigned, she is not on the phone

akshay: we are proposing we would have a touch first.

jcj_jones: want to make this less prescriptive. things should blink or not blink.
... Google put stake in sand and Firefox agreed, but want to relax a bunch of this.
... want to let the browser decide... this is where it gets fuzzy....wnat to give browser more discretion when authenticator gets plugged in

akshay: browser can do what they want.

jcj_jones: we want to make things clear in the spec.

akshay: today I have scenarios, I only blink one authenticator if I have multiple authenticators.
... or you plug in authenticator is not recognized... it is the wrong one.
... I don't want for authenticators to have to blink.

jbradly: there may be some changes based on privacy guard
... so might be different with a PIN

akshay: once you have this, it is up to the browser. it does not impact privacy.
... I do not see a case where things will change from today
... lets start with what Kim is doing and then proceed

Jbradley: I thought we were waiting for someone to do something on the key. I think what we have now may mean we don't have to worry about #863

selfissue: I am joining the call

tony: so we will go ahead with what Kim in going to do and we can fully understand.

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

tony: not sure what is happening here. JeffH will go back to web app sec. they are looking at the permission model
... we will wait to hear back from Mike West. so this is on hold.

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

jcj_moz: this is TPM update

akshay: the PR and the Issue don't match on drafts.
... I will look at PR later

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

tony: this is JeffH

not on call

tony: talked about this uni-code stuff at F2F

akshay: I think the main point, authenticators will deal with this. I will look into this

tony: but this should be pretty much as editorial issue

akshay: I will read through this.
... it is correct it is mentioning the bytes. how browsers do this before sending to authenticator is the magic. I will look into it

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

elundberg: it is corresponding PRs.

tnoy: #1182 is what we talked about

adding PR number

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

shane: work in progress

tony: will you create the PR

shane: I will work with JeffH on that.
... I will work on change
... I don't know about backward compatibility

elundberg: this follows the pattern of the user verification parameter

<jeffh> not exactly present...but...

sorry, missed you

<jeffh> yeah, am buried in meetings the rest of this week will try to make prog next week on #991 and other items

<discussion> on extensions

shane: I will put in a comment that adds the extension suggestion
... I will get with JeffH

tony: so you will work together on this

share: yes.

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

elundberg: this is on going

tony: have you looked

elundberg: not really. what is there to do here?

tony: we need another set of eyes on it.... it looks like it will cause some issues down the line
... not sure of the value

jcj_moz: we would make clients to do into test mode to decide if this is correct form. I like idea of changing credman....
... that might not be the answer.

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

elundberg: think this is duplicate of #991

tony: keep this open just for refeernce

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

tony: this has open pull request.

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

tony: just editorial for jeffH to look at

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

tony: more editorial

jcj_moz: i thought this was addressed. I think this is already closed
... or should be closed.
... maybe just add a note to ask jeffH if we can close

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

eludberg: at surface level this looks like good idea, but we cannot enforce this. It does not break anything

tony: won't change behavior?

elundberg: correct.

tony: need to bring back one thing to bring to list

move list from 10PDT to noon PDT...please reply to the list so we understand concerns for moving the meeting.

sorry, move meeting from 10 PDT to Noon PDT

scribe: so please look at this
... there is a meeting next week, but not the following week.

selfissue: need support on COSE list for our algorithms

tony: adjorn

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/yes/correct/
Default Present: pranjal, tomlowenthal, plh_, nsteele__
Present: pranjal tomlowenthal plh_ nsteele__ elundberg jcj jbarclay ken
Regrets: wseltzer
Found ScribeNick: elundberg
Found ScribeNick: jfontana
Inferring Scribes: elundberg, jfontana
Scribes: elundberg, jfontana
ScribeNicks: elundberg, jfontana

WARNING: No "Topic:" lines found.


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