<elundberg> nadalin: no meeting 2019-04-12 due to ???

<elundberg> scribenick: elundberg

nadalin: will give an update on AC meeting on webauthn
... anyone got anything we should say?
... hearing nothing
... let's get on to issues

<jfontana> #909

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

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

scribe: on #909, waiting for input from google
... on #1095, JC away for a few weeks, might need to move on with this once Jeff reviews
... @selfissued please review

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

<jfontana> tony: still issues with this one. Akshay has lookeda t

<jfontana> ...at it

elundberg: we can remove the "-2" link, merge this, then revert that removal once "-2" is valid

#1186 to remove "-2" https://github.com/w3c/webauthn/pull/1161

#1186 to remove "-2" https://github.com/w3c/webauthn/pull/1186

#1187 to revert #1186 https://github.com/w3c/webauthn/pull/1187

<jfontana> https://github.com/w3c/webauthn/pull/1186

<jfontana> elundberg: we can merge #1181 into #1186 if we want

akshay: #1181 has merge conflicts, let's wait

<jfontana> agl: we have arnar with us briefly today

<scribe> scribenick: jfontana

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

tony: looks ready

akshay: looks fine to me

tony: any objections for merging?

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

tony: looks like this one is pending.
... akshay has signed off on it. agl also
... can you go ahead and merge if you get review from ...

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

tony: shane do you have anything

akshay: I want to talk with the right people on the call
... Christiaan is not on
... this is long thread.

when you create authnticator, the spec in CTAP says required ot have PIN this was earlier behavior

scribe: we have come to agreement on non-resident keys , dont' require PIN
... he does not want PIN, needs more discussion.
... shane wants to know when the cred is created , what kind is it
... RP wants to know this
... I have comments. certain authenticators will always do user verification
... that is one of the existing authenticators out there that do it, not many out there.
... not uniform across authenticators.
... my requirement is do not force them to not use user verificaiton
... don't force authenticators to support non-resident keys if they don't want to
... now as RP, when says I want to register a credential
... what is the third optino, crete non-reisdent keys like U2F, will solve Christiann's issue

Shane: this is my original proposal, go to top of thread #1191
... emil first brought this up.

<discussion> resident credentials, PIN, user verification

shane: second part of PR #1191 reports on what was actually done.
... I will put back the original proposal
... what akshay recommends and what I proposed are the same things to me.
... not certain if it satisfies Christiann's requirements. comes down to how the browsers work.

akshay: some browsers will always require a PIN. Christiann may not get what he wants.

elundberg: required, preferred, and discourage are three choices.

share: in the proposal, had a default value of discouraged. that has same semantics as what we had.
... default value

elundberg: I disagree.
... I want indifferent and discouraged

Akshay has to leave.

akshay: can we discuss later>

elundberg: sure.

agl: tony would you want to move on. You may wish to close this.

tony: go ahead now

agl: the term discouraged weirds me out. I care about if it can be returned in context.
... that is meaningful. best argument for discouraged, CTAP has some requirements, Web Atuhn should not make promises it can't keep.

elundberg: in practice CTAP model might allow it to act as if it was forbidden.

agl: I think ctap2 should be changed. it won't affect authenticators other than perhaps one software authenticator
... I don't think RP has any place to thing credential is stateful or not.

elundberg: we should be align description to be in allow lists rather than storage
... we could modify CTAP to align with authenticators

jbradley: one authenticator widely distributed that always created resident credentials, but it could be fixed.

agl: I would not worry too much

jbradley: if you are not specifying residential credentials then the authenticator can do what it wants.

shane: if there is a path forward here with respect to PR what do we want to do with these values.
... having more values is better, RPs don't want to settle on one.
... it is most likely the willuse discouraged or preferred, to make use cases broader.
... somewhat inclined to bring this back to not having forbidden

agl: think your flag is good, could make it about allow lists.
... I think we need three values.
... I thin we can get to consensus on what it is called.

jbradley: discourage may be defined if we define it. what is UV requirement on main credential
... if you say discouraged , then the user is not prompted for a PIN.

agl: i am more concerned about privacy.

jbradley: if we want to do that, we need to make a change to CTAP for it to work

agl: that is true

jbradley: we wold ned in CTAP explicit language, cred can't be returned without an allowed list.

agl: that flag is cred protect.

jbradley: cred protect is similar.

tony: see you in two weeks.

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)

Present: nsteele jbarclay elundberg jfontana akshay John_Bradley nadalin sbweeden agl arnar selfissued
Regrets: =jeffh jcj_moz
Found ScribeNick: elundberg
Found ScribeNick: jfontana
Inferring Scribes: elundberg, jfontana
Scribes: elundberg, jfontana
ScribeNicks: elundberg, jfontana

WARNING: No "Topic:" lines found.


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