16:47:10 RRSAgent has joined #webauthn 16:47:10 logging to http://www.w3.org/2017/04/12-webauthn-irc 16:47:12 RRSAgent, make logs public 16:47:12 Zakim has joined #webauthn 16:47:14 Zakim, this will be 16:47:14 I don't understand 'this will be', trackbot 16:47:15 Meeting: Web Authentication Working Group Teleconference 16:47:15 Date: 12 April 2017 16:47:49 agenda: https://lists.w3.org/Archives/Public/public-webauthn/2017Apr/0170.html 16:47:58 weiler has changed the topic to: agenda: https://lists.w3.org/Archives/Public/public-webauthn/2017Apr/0170.html 16:51:21 vgb has joined #webauthn 16:59:04 present+ 17:01:25 present+ 17:01:54 present+ jcj_moz, nadalin 17:02:09 present+ mkwst 17:02:13 present+ angelo 17:02:17 apowers has joined #webauthn 17:02:48 selfissued has joined #webauthn 17:02:50 present+ jyasskin, dirk, alexei, kim 17:02:50 present+ 17:03:10 present+ jfontana 17:03:12 kpaulh has joined #webauthn 17:03:19 alexei-goog has joined #webauthn 17:03:19 +present 17:03:25 present+ 17:03:28 present+ 17:03:45 jeffh has joined #webauthn 17:03:51 gmandyam has joined #webauthn 17:03:53 present+ jeffh 17:04:00 present+ gmandyam 17:04:37 scribenick: vgb 17:04:40 angelo has joined #webauthn 17:04:48 present+ apowers 17:04:49 J.C. is on the record that he'll scribe next week 17:05:17 tony: main issue today is to reach a decision on CredMan integration and how to proceed 17:05:53 q+ 17:05:59 ... if we want to do this we should do it now, "later release" might be too late 17:06:15 ... bear in mind we also want to lock down WD-05 for implementers 17:06:33 ack alexei-goog 17:07:18 alexei-goog: agree with taxonomy on https://lists.w3.org/Archives/Public/public-webauthn/2017Apr/0157.html 17:07:33 ... should get started 17:07:41 angelo: also agree 17:07:56 battre-google has joined #webauthn 17:07:56 ... let's start with #397 which may be less controversial 17:08:39 ... this seems like a worthy simplification of the IDL with no significant side-effects 17:09:50 alexei-goog: naming seems a bit confusing and maybe misleading 17:11:08 vgb: i think this is mainly refactoring with little normative change 17:12:11 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. 17:12:25 weiler has joined #webauthn 17:12:48 ... this seemed to be mostly agreeable to everyone since Alexei's alternative had a similar feature. 17:13:11 jcj_moz: like this. think inheritance is the right thing to have here. 17:14:02 mkwst: this (specifically, the inheritance) also enables some changes that #384 is trying to make. 17:14:35 angelo: seems like we have agreement on concepts, modulo some tweaking of names. 17:15:24 jcj_moz: agree with mkwst that there are no normative changes. should we merge this and rename later? 17:15:45 jeffh: no problems with the names. 17:15:46 Ketan has joined #webauthn 17:16:08 alexei-goog: reading this a bit more, like it. ok with merging and renaming later. 17:16:53 jeffh: want to give it a closer reading 17:17:44 tony: how about we wait until Friday and merge if no objections by then? 17:18:08 alexei-goog: on to #398 and #399 17:18:30 mkwst: #398 changes args to getAssertion so they are all in one dictionary 17:19:23 ... #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. 17:19:33 alexei-goog: like this pattern 17:20:03 ... for the rest, need to read more. let's get this done by Friday as well. 17:21:47 ... 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) 17:22:29 dirk: this is an issue is because now we're on the same namespace so we inherit this method as well 17:22:55 alexei-goog: would like to invite mkwst to further explain his response from this morning 17:22:59 The issue at hand: will requireUserMediation apply to WebAuthentication? 17:24:08 jyasskin: but you're happy with #397 - #399 regardless of the answers here? 17:24:11 alexei-goog: yes 17:25:36 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" 17:25:57 ... seems like these would be useful in similar scenarios 17:27:03 angelo: difference may be that requiring user mediation is the baseline expectation from webauthn authenticators, where the common case in CredMan was the opposite 17:27:42 q+ alexei-goog 17:27:57 ack alexei-goog 17:28:01 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? 17:28:19 alexei-goog: was thinking about the use cases for this. 17:29:23 ... is the default closed or open? this is a privacy concern. 17:29:38 mkwst: everything defaults to requiring user mediation 17:29:59 ... but UA can make choices to maximize your convenience based on what it knows 17:31:00 alexei-goog: i go to my bank, log on, go idle, get logged out - is user mediation on now? 17:31:32 mkwst: yes, if the bank site is well written, when it logs you on idle out it should also call requireUserMediation 17:31:52 alexei-goog: and if they forget, it is a security bug on them? 17:32:19 mkwst: yes it would be their fault 17:33:02 jyasskin: if they didn't call store then the ua would not store the cred either? 17:34:06 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 17:34:14 ... each credential then does the right thing with that 17:34:40 q+ 17:35:29 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? 17:35:48 mkwst: that is an issue with using password managers at all, not specific to this. 17:36:18 alexei-goog: why not have buttons on the page instead of dealing with the UA this way? 17:37:44 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. 17:38:27 ... 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. 17:39:59 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? 17:41:03 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. 17:41:36 ... so what is this question blocking exactly? 17:42:13 alexei-goog: trying to understand where we would call this in our logon flow 17:43:11 angelo: who is an RP asking for silent auth? 17:43:17 jeffh: PayPal 17:44:20 alexei-goog: potentially Amazon? Can see many sites wanting this, maybe it should be DontRequireUserMediation or something like that? 17:45:09 ... Google would also like something like this just to check if the authenticator is still around 17:46:02 tony: that's basically similar to the EMVCo request 17:46:49 alexei-goog: we think of this mainly as a call-by-call thing rather than a user state 17:47:48 ... 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> 17:48:41 ... worry about websites creating large security issues through programming errors 17:50:11 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 17:50:15 Are we honoring the speaker queue, or should I just jump in? 17:50:48 ... we do believe that there is room to change the CredMan API if it turns out that is needed 17:51:02 q? 17:51:10 ... renaming is a smaller concern and is on the table if it makes sense 17:51:58 alexei-goog: don't want to get into a situation where finishing webauthn depends on refactoring another api 17:52:16 ack gmandyam 17:53:10 gmandyam: how about UI outside the browser? if requireUserMediation is set, does that mean the user has to interact with both browser and authenticator? 17:54:19 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. 17:54:46 gmandyam: so, no prompting in two places if the browser is doing it right? 17:54:56 mkwst: believe the API supports that 17:55:49 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? 17:56:14 jcj_moz: could make that work, good idea if others can make it. 17:56:31 wseltzer: W3C can support that 17:56:44 Thanks, mkwst. My conclusion is the requireUserMediation is a no-op for Webauthn except in the case of silent authenticators 17:57:10 alexei-goog: still have significant uncertainty about the practical behavior of the API. 17:57:20 ... and how best to use it 17:57:40 ... what is the SOP and how much uncertainty are people willing to take on for the sake of progress? 17:58:43 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. 17:58:47 jeffh: +1 17:58:58 gmandyam: also agree 18:00:19 angelo: sympathize but worry more about scheduling risk. there are RPs waiting to use the API today. we should take that into account. 18:00:26 q+ 18:00:46 tony: seems like the only way to answer the question is to merge and try implementing 18:01:34 alexei-goog: should try and think through how to use API including writing code 18:01:49 jcj_moz: we've thought about this, just haven't written the code 18:02:06 tony: how about follow up call at 10am PT Friday? 18:02:47 wseltzer: will send out details 18:03:03 tony: will send out agenda 18:03:11 ... also please watch the list 18:07:30 rrsagent, make logs public 18:07:34 rrsagent, draft minutes 18:07:34 I have made the request to generate http://www.w3.org/2017/04/12-webauthn-minutes.html wseltzer 20:00:59 Zakim has left #webauthn