<kpaulh> +present

<jcj_moz> scribenick: vgb

<jcj_moz> J.C. is on the record that he'll scribe next week

tony: main issue today is to reach a decision on CredMan integration and how to proceed
... if we want to do this we should do it now, "later release" might be too late
... bear in mind we also want to lock down WD-05 for implementers

alexei-goog: agree with taxonomy on https://lists.w3.org/Archives/Public/public-webauthn/2017Apr/0157.html
... should get started

angelo: also agree
... let's start with #397 which may be less controversial
... this seems like a worthy simplification of the IDL with no significant side-effects

alexei-goog: naming seems a bit confusing and maybe misleading

vgb: i think this is mainly refactoring with little normative change

mkwst: trying to extract commonality between makeCredential and getAssertion responses to inherit from, to make other refactoring easier down the road. if someone has better names, please share.
... this seemed to be mostly agreeable to everyone since Alexei's alternative had a similar feature.

jcj_moz: like this. think inheritance is the right thing to have here.

mkwst: this (specifically, the inheritance) also enables some changes that #384 is trying to make.

angelo: seems like we have agreement on concepts, modulo some tweaking of names.

jcj_moz: agree with mkwst that there are no normative changes. should we merge this and rename later?

jeffh: no problems with the names.

alexei-goog: reading this a bit more, like it. ok with merging and renaming later.

jeffh: want to give it a closer reading

tony: how about we wait until Friday and merge if no objections by then?

alexei-goog: on to #398 and #399

mkwst: #398 changes args to getAssertion so they are all in one dictionary
... #399 is a little more but also not a huge change. The only difference here is that it restructures things by throwing away superfluous interfaces. believe these are minor but do expect more commentary on this than #398.

alexei-goog: like this pattern
... for the rest, need to read more. let's get this done by Friday as well.
... how about moving on to the harder questions in the threads, regarding requireUserMediation semantics and so on? (i.e. the parts of #384 that are not covered in #397 - #399)

dirk: this is an issue is because now we're on the same namespace so we inherit this method as well

alexei-goog: would like to invite mkwst to further explain his response from this morning

<angelo> The issue at hand: will requireUserMediation apply to WebAuthentication?

jyasskin: but you're happy with #397 - #399 regardless of the answers here?

alexei-goog: yes

mkwst: requireUserMediation is really about RP telling UA that user is logged in vs. logged out. in the former state for example passwords can be replayed silently. webauthn seems to have something that smells similar in "silent auth"
... seems like these would be useful in similar scenarios

angelo: difference may be that requiring user mediation is the baseline expectation from webauthn authenticators, where the common case in CredMan was the opposite

mkwst: but does that matter? what if we just called the API isLoggedOut() and just said the UA needs to respond appropriately fro each credential type?

alexei-goog: was thinking about the use cases for this.
... is the default closed or open? this is a privacy concern.

mkwst: everything defaults to requiring user mediation
... but UA can make choices to maximize your convenience based on what it knows

alexei-goog: i go to my bank, log on, go idle, get logged out - is user mediation on now?

mkwst: yes, if the bank site is well written, when it logs you on idle out it should also call requireUserMediation

alexei-goog: and if they forget, it is a security bug on them?

mkwst: yes it would be their fault

jyasskin: if they didn't call store then the ua would not store the cred either?

mkwst: the goal here is to provide a flag that enables websites to indicate the sensitivity of the state in which the user currently is
... each credential then does the right thing with that

dirk: in the bank example, the goal of logging the user out was to require user mediation - how does calling requireUserMediation prevent random people from walking up and authenticating?

mkwst: that is an issue with using password managers at all, not specific to this.

alexei-goog: why not have buttons on the page instead of dealing with the UA this way?

mkwst: lots of RPs want to do silent and transparent auth. this enables such sites by making "get" always safe to call. it will either work transparently or not depending on the user's logout state, in a way that the user would expect.
... does not necessarily defend against attacks. a password manager may require additional master passwords when user mediation is required, but Chrome does not do that.

angelo: maybe the audiences are different? CredMan is mainly targeted at low-security websites that want people to be transparently signed in, but WebAuthn targets security-conscious RPs. So is requireUserMediation ever relevant?

mkwst: you get to decide. it's expected that each credential type will make different choices based on the information that this flag provides. the flag itself seems generic and valuable even if different credential types make different choices based on it.
... so what is this question blocking exactly?

alexei-goog: trying to understand where we would call this in our logon flow

angelo: who is an RP asking for silent auth?

jeffh: PayPal

alexei-goog: potentially Amazon? Can see many sites wanting this, maybe it should be DontRequireUserMediation or something like that?
... Google would also like something like this just to check if the authenticator is still around

tony: that's basically similar to the EMVCo request

alexei-goog: we think of this mainly as a call-by-call thing rather than a user state
... for example is this user state synced across devices? if i sign in to a website on one device, am i automatically signed in on all other synced devices as a result of this>
... worry about websites creating large security issues through programming errors

mkwst: the question here, though, is whether this flag is flexible enough to accommodate WebAuthn's needs (even if that need is to be tightly locked down) without going into whether we do things right for password credentials

<gmandyam> Are we honoring the speaker queue, or should I just jump in?

mkwst: we do believe that there is room to change the CredMan API if it turns out that is needed
... renaming is a smaller concern and is on the table if it makes sense

alexei-goog: don't want to get into a situation where finishing webauthn depends on refactoring another api

gmandyam: how about UI outside the browser? if requireUserMediation is set, does that mean the user has to interact with both browser and authenticator?

mkwst: it depends on the state the user is in. the UA needs to be involved to point the user to the right authenticator device, but should understand the user mediation state of the authenticator and allow for that.

gmandyam: so, no prompting in two places if the browser is doing it right?

mkwst: believe the API supports that

angelo: we need to decide things quickly, implementations are at risk if we don't wrap up soon. how about a second call late this week?

jcj_moz: could make that work, good idea if others can make it.

wseltzer: W3C can support that

<gmandyam> Thanks, mkwst. My conclusion is the requireUserMediation is a no-op for Webauthn except in the case of silent authenticators

alexei-goog: still have significant uncertainty about the practical behavior of the API.
... and how best to use it
... what is the SOP and how much uncertainty are people willing to take on for the sake of progress?

jcj_moz: it's a tradeoff - schedule risk vs. prettier API. even if we fail, we can go back to the way things already are. this feels like the right direction though.

jeffh: +1

gmandyam: also agree

angelo: sympathize but worry more about scheduling risk. there are RPs waiting to use the API today. we should take that into account.

tony: seems like the only way to answer the question is to merge and try implementing

alexei-goog: should try and think through how to use API including writing code

jcj_moz: we've thought about this, just haven't written the code

tony: how about follow up call at 10am PT Friday?

wseltzer: will send out details

tony: will send out agenda
... also please watch the list

This is scribe.perl Revision: 1.152  of Date: 2017/02/06 11:04:15  
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: wseltzer vgb jcj_moz nadalin mkwst angelo jyasskin dirk alexei kim jfontana alexei-goog selfissued jeffh gmandyam apowers
Found ScribeNick: vgb
Inferring Scribes: vgb

WARNING: No "Topic:" lines found.

Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2017Apr/0170.html

WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 12 Apr 2017
Guessing minutes URL: http://www.w3.org/2017/04/12-webauthn-minutes.html
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