15:32:51 RRSAgent has joined #webauthn 15:32:51 logging to http://www.w3.org/2016/06/01-webauthn-irc 15:32:52 Meeting: Web Authentication WG 15:33:02 RRSAgent, make logs public 16:09:38 selfissued has joined #webauthn 16:10:17 WebEx says the call isn't started 16:10:23 Are any of you somehow on the call? 16:13:27 OK - false alarm. The call's at 10 Pacific Time. 16:53:48 weiler has joined #webauthn 16:57:15 present+ 16:57:17 Chair: Tony Nadalin 16:57:20 present+ 16:57:25 regrets+ rbarnes 16:58:19 zakim, who is here? 16:58:19 Present: weiler, wseltzer 16:58:21 On IRC I see weiler, RRSAgent, Zakim, slightlyoff, mkwst, wseltzer, adrianba 16:59:20 wseltzer has changed the topic to: webauthn June 1 https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0000.html 16:59:24 Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0000.html 16:59:28 agenda+ Roll call 16:59:32 agenda+ Agenda bashing 16:59:38 agenda+ "It's all about extensions" discussion, please read Jeff's proposal that was sent to list 16:59:42 agenda+ AoB 17:00:26 present+ Nitin 17:00:53 present+ Rolf, Tony 17:01:00 Rolf has joined #webauthn 17:01:55 vgb has joined #webauthn 17:02:15 present+ gmandyam 17:02:38 present+ 17:03:05 present+ dirkbalfanz 17:03:23 present+ JeffH 17:03:29 dirkbalfanz has joined #webauthn 17:04:11 present+ apowers 17:04:18 present+ Hubert 17:04:27 gmandyam has joined #webauthn 17:04:28 present+ 17:04:34 zakim, who is here? 17:04:34 Present: weiler, wseltzer, Nitin, Rolf, Tony, gmandyam, vgb, dirkbalfanz, JeffH, apowers, Hubert 17:04:35 present+ 17:04:36 On IRC I see gmandyam, dirkbalfanz, vgb, Rolf, weiler, RRSAgent, Zakim, slightlyoff, mkwst, wseltzer, adrianba 17:07:00 present+ RobTrace 17:07:33 JeffH has joined #webauthn 17:07:39 ChristiaanBrand has joined #webauthn 17:07:39 present+ 17:07:41 present+ 17:08:12 Tony: talk of extensions on-list, and a submission of a new proposed extension 17:09:33 hubert-PayPal has joined #webauthn 17:09:39 scribenick: hubert-PayPal 17:09:48 present+ 17:09:54 zakim, take up agendum 3 17:09:54 agendum 3. ""It's all about extensions" discussion, please read Jeff's proposal that was sent to list" taken up [from wseltzer] 17:10:11 -> https://lists.w3.org/Archives/Public/public-webauthn/2016May/0306.html Jeff's email 17:10:43 mail msg wrt client filtering of extensions: https://lists.w3.org/Archives/Public/public-webauthn/2016May/0306.html 17:10:53 present+ 17:11:31 In the thread on extensions, Wendy made a great observation that some client may or may not accept some of those extensions 17:11:45 i/In/JeffH: In/ 17:12:31 JeffH: there can be legal recourse when an authenticator is found misrepresenting an RP etc. 17:13:18 JeffH: If a client is filtering all extensions, it is going to add friction to adoption 17:13:39 q+ 17:13:47 JeffH: I just wanted to present that overall line of thinking and up level the conversation 17:13:53 ack vgb 17:14:02 weiler has joined #webauthn 17:14:14 Vijay: what I took away from that explanation, is that it seems there are a couple things to be inferred 17:14:21 RobTrace has joined #webauthn 17:14:34 Vijay: there are clients (embedded) that have no use for extensions and will ignore those 17:14:54 i.e. for example 17:15:14 Vijay: then there might be clients (perhaps client that are wide open and pluggable) that will want to allow free use of extensions 17:15:38 Vijay: then maybe there is going to be a wide spectrum of clients and we should not mandate anything 17:16:07 Vijay: we should just be accepting this variety of clients 17:16:17 jeffH: we're in agreement 17:17:05 Vijay: Nitin, we all agree that the point of registering extensions is to have well-known extensions identifiers 17:17:23 Vijay: the questions is what happen when a client receives an extension it does not understand? 17:18:00 Vijay: the point that Wendy and Jeff made is that there are cases where client will not do anything with it, other clients will do something smarter 17:18:25 Vijay: one of the things you can choose to do is pass the extension on and not do anything 17:18:47 Nitin: Does the FIDO spec know what the extension means/do? 17:19:13 Nitin: you need to register extensions to avoid conflict 17:19:33 Jeff: there may be extensions that are private that nobody else needs to know about 17:19:40 Nitin: that's fair 17:20:16 Jeff: it's implicit that one can go and cook up a private extension that both Client and RP understand it amongst themselves 17:20:38 q+ 17:20:51 Hubert: Didn't Sam raise privacy concerns about it? 17:21:39 selfissued has joined #webauthn 17:21:49 Jeff: I did think about this and the basic scenario Sam uses, is that a generic ID is return to all RPs such that it creates a correlation handler - we should say in the spec that this is bad behaviour 17:22:01 Jeff: something to put in the privacy consideration section 17:22:17 q? 17:22:27 q+ 17:22:27 ack gmandyam 17:22:51 q? 17:23:25 giti: note that EME has addressed similar issues wrt privacy 17:23:25 Gmandyam: very clear privacy issue in DRM - the way they solved that is using secure context - this has been dealt with before 17:23:37 the W3C’s specification for Encrypted Media Extensions (i.e. DRM enabler for the browser), a MediaKeySession can result in opaque messaging being sent between the decryption module (external to browser) and license server. There was a clear recognition that such messaging can be privacy violating (https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332). The solution was to require a secure context for webpages that access EME. 17:23:40 -> https://www.w3.org/TR/secure-contexts/ Secure Contexts spec 17:23:55 Viajy: can you explain further - we already require secure context - how would that also provide privacy ? 17:24:39 gmandyam: if you feel that something more that secure context is require for privacy, then please explain. 17:24:45 q? 17:24:54 ack Rolf 17:25:14 q+ 17:25:15 Rolf: Jeff you mentioned some recourse: putting an extension in a black list? 17:25:54 Accommodating finer-grained permissions on an extension level is certainly possible through ongoing work like the Permissions API - https://www.w3.org/TR/permissions/. Currently WebAuthn is not in the spec but it could be. 17:25:57 q- 17:25:57 Wendy: filing legal complaints, putting out warnings that could be used to create a black list 17:26:04 ack gmandyam 17:26:31 q? 17:26:31 Rolf: this is part of the certification program (privacy) 17:26:31 Giri, this is the entire text of the Privacy Considerations section in Secure Contexts: 17:26:34 The secure context definition in this document does not in itself have any privacy impact. It does, however, enable other features which do have interesting privacy implications to lock themselves into contexts which ensures that specific guarantees can be made regarding integrity, authenticity, and confidentiality. From a privacy perspective, specification authors are encouraged to consider requiring secure contexts for the features they define. 17:27:06 so maybe this is a red herring - we should be looking elsewhere for privacy specifically? 17:27:14 Nity: this is the privacy of biometric ? 17:27:30 Jeff: in general, not being able to track users across RPs 17:27:52 Tony: where does that put us? not hearing everyone on the same page so far 17:28:12 To vgb: Cited secure contexts as the solution to the privacy issue in EME - see https://www.w3.org/Bugs/Public/show_bug.cgi?id=26332. 17:28:13 Jeff: I'm hearing that the status quo is OK 17:28:31 Dirk: is it ok then to pass on extension it does not understand? 17:28:49 Jeff: the way I see it is, it is honoring extensions it does not understand 17:29:30 Jeff: a client could ignore what extension payload is transmitted, others be smarter 17:30:03 -> https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0001.html Giri's "Opaque data" extension 17:30:48 Jeff: Giry wrote an extension proposal - if a different extension passes an unspecified payload - some client may chose to ignore it or not 17:30:56 q+ 17:32:09 Jeff: in other words it is OK to ignore extensions it does not understand - there is a related issue: there is language in the spec that says that if a client does not know about necessary client processing for that extension it should map the data into the authenticator extension and pass it to the authenticator 17:32:27 Jeff: there are some issues with client processing for this 17:33:06 Jeff: the RP can send arbitrary data to the the authenticator and back - the authenticator should not create tracking 17:34:02 Jeff: this has been used for innovation too - the user identification index is an example that was created by a vendor (FIDO) 17:34:11 q? 17:34:41 ack Ro 17:35:01 Rolf: question: we don't see a need to change the spec - if an authenticator adds an extension, then the client has too parse it through to the RP? 17:35:06 Jeff: yes 17:35:19 Vijay: there is no stripping out - because of signature 17:35:51 Dirk: according to current spec, authenticators can add such extension? 17:35:59 Jeff: yes, there are 3 of them today 17:36:45 Vijay: this is where there was a proposal that authenticators not be allowed to return an extension that it had not been requested with 17:37:25 Jeff: the argument is that adding that would create friction - making it harder to roll things out on the authenticators - we also have the legal recourse backstop if needed 17:37:30 q? 17:37:43 Dirk: which extensions do this? 17:38:13 Jeff: AAGUID - UVI - supported extensions extension (7.3-7.5) 17:38:56 Tony: Jeff, when you talk about clients, are you also including authenticators? 17:39:05 Jeff: just the layer above the authenticator 17:40:08 Tony: whatever is burning the client becomes the gatekeeper (embedded clients) 17:40:18 Jeff: yes 17:40:25 s/burning/burned into/ 17:40:37 Tony: they may never get updated 17:41:35 Tony: I'm not hearing real objection - but no vote of confidence either. 17:41:59 q+ 17:42:00 q? 17:42:03 Tony: if not hearing objections - could people tolerate leaving the doc as-is (with privacy concerns) 17:42:08 ack gm 17:43:04 gmandyam: are you referring to https://w3c.github.io/permissions/ when you say "permissions" ? 17:43:07 Giry: my feeling is that the use of certain extension does not require permission. I sense some people in the group feel there needs to be a finer grained permission mech 17:43:43 Giry: we've had discussion in W3C on the appropriate dialog boxes for granting permission etc. 17:43:53 s/Giry/Giri/G 17:44:17 PROPOSED: continue with what's in the document, potentially adding some privacy considerations 17:44:30 works for me 17:44:35 +1 17:44:35 Tony: not hearing any objection, I'd like to go ahead and proceed on this premise 17:44:56 Tony: extension draft submitted 17:45:00 Topic: Giri's draft extension proposal 17:45:18 https://lists.w3.org/Archives/Public/public-webauthn/2016Jun/0001.html 17:45:23 Giri: this was a container which the authenticator can communicate directly to the RP 17:46:00 Giri: I did think of making it more structured data - something like CBOR so the client could peek into it even if not understanding it... 17:46:45 Giri: I used the UIV extension as a model - UVI has left the format open so we already have a model of how this can work 17:46:52 q+ 17:47:09 Giri: I can create a pull request when ready 17:47:15 ack Rolf 17:47:17 Tony: any objection to add this? 17:47:26 q+ 17:47:35 Rolf: this extension will not be sent from RP to authenticator, correct? 17:47:39 Giri: yes 17:47:55 i suggest the term "authnr-produced extension" for this class of extensions... 17:48:03 Rolf:give previous conversation, why would we need such opaque extension? 17:48:26 Rolf: why the authenticator would not use UVI? 17:48:38 Giri: overloading the UVI? 17:48:43 q+ 17:49:08 Rolf: trying to understand why the authenticator would want to do this rather than add an extension to the signature 17:49:41 Giri: this is the problem with the spec - not really sure which this should fit 17:50:12 Giri: happy to bring more Qualcom folks to discuss offline for a more precise use case 17:50:30 Rolf: why dedicated opaque extension to do so since we could use UVI ? 17:50:50 Giri: what is the question? 17:51:02 ack selfissued 17:51:03 q+ 17:51:17 Mike: my reaction on reading this, is that it's not clear what it is for 17:51:55 Mike: it is certainly a legal extension but it seems too general - needs more knowledge 17:52:35 Mike: we should be adding example extension that would be of general applicability - this is confusing without knowing what the payload is 17:52:48 Giri: UVI already uses this approach 17:53:05 Mike: maybe I will also call out that UVI should also be better defined 17:53:29 Tony: we may not need to define too much detail for extensions 17:53:47 q? 17:53:53 Mike: agreed - but this extension raises more questions than it answers 17:54:10 Giri: what we had a CBOR object in this extension? 17:54:38 Mike: it would be more acceptable as the CBOR syntax could be used to describe what the data actually is 17:55:12 Giri: as mentioned, I had considered more structured data - I can revise the proposal. Not sure it is necessary to be more precise though 17:55:43 Mike: agreed - unspecified binary data left to agreement between RP and authenticator is the concern 17:55:57 q+ 17:56:07 Giri: ok 17:56:52 Wendy: we can ask for an update on creating a registry for extensions - having additional extensions seems fine 17:57:09 Mike: I don't see the string UVI anywhere? 17:57:16 Giri: section 6.5 17:57:26 ack vgb 17:57:27 q- 17:58:14 Vijay: to channel some of the uneasiness: as Jeff & Wendy said, there is the technical recourse and the non-technical recourse. The latter one only works if people know what is actually going on. 17:59:06 Vijay: the moment the authenticator passes opaque data, I suspect the second recourse would be to block it completely - hence the questioning of the wisdom of doing that - state the intent of the extension would help 17:59:31 Giri: UVI does not specify that - if opaque data is a problem, then what about UVI? 17:59:39 q? 17:59:50 ack Rolf 18:00:53 Rolf: UVI is often cited as using opaque data but it has a concrete semantic - what about this one? is it only a container for anything? If yes, we already have one (UVI). If it has a concrete semantic, then we should describe it. 18:01:08 Giri: not sure UVI has really a concrete semantic 18:02:40 Wendy: we've lost Giri... 18:03:27 Giri: because it is only listed as an example 18:04:10 q? 18:04:12 Giri: If I add the CBOR, my proposed extension won't be opaque but adding to many fields would diminish the flexibility 18:04:48 Tony: Giri will revised his proposed and we can take a look again. 18:04:55 Tony: any objections? 18:05:07 Tony: none - thanks 18:05:26 Tony: where do we stand on the intro and the summary areas? 18:05:47 Jeff: Vijay merged everything this morning - that's done 18:05:57 q+ 18:05:57 Tony: any other business? 18:06:20 Wendy: we published the first draft yesterday - congrats to all 18:06:29 Wendy: on to a wide review 18:06:41 Wendy: IPR clock started yesterday 18:07:18 End of call 18:07:26 [adjourned] 18:07:32 zakim, list attendees 18:07:32 As of this point the attendees have been weiler, wseltzer, Nitin, Rolf, Tony, gmandyam, vgb, dirkbalfanz, JeffH, apowers, Hubert, RobTrace, ChristiaanBrand, hubert-PayPal 18:07:39 rrsagent, draft minutes 18:07:39 I have made the request to generate http://www.w3.org/2016/06/01-webauthn-minutes.html wseltzer 18:09:03 s/JeffH: In// 18:09:18 s/In the thread/JeffH: In the thread/ 18:09:23 rrsagent, draft minutes 18:09:23 I have made the request to generate http://www.w3.org/2016/06/01-webauthn-minutes.html wseltzer 18:10:31 present+ ChristiaanBrand 18:10:40 s/WebEx says the call isn't started// 18:10:47 s/Are any of you somehow on the call?// 18:10:57 s/OK - false alarm. The call's at 10 Pacific Time.// 18:11:00 rrsagent, draft minutes 18:11:00 I have made the request to generate http://www.w3.org/2016/06/01-webauthn-minutes.html wseltzer