11:49:16 RRSAgent has joined #webauthn 11:49:16 logging to http://www.w3.org/2016/09/07-webauthn-irc 11:49:19 RRSAgent, make logs public 11:49:21 Zakim, this will be 11:49:21 I don't understand 'this will be', trackbot 11:49:22 Meeting: Web Authentication Working Group Teleconference 11:49:22 Date: 07 September 2016 11:51:36 weiler has changed the topic to: Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016Sep/0130.html 11:51:41 Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016Sep/0130.html 13:40:58 weiler has joined #webauthn 16:45:32 RRSAgent has joined #webauthn 16:45:32 logging to http://www.w3.org/2016/09/07-webauthn-irc 16:55:04 nadalin has joined #webauthn 16:56:29 jcj_moz has joined #webauthn 16:57:55 RobTrace has joined #webauthn 17:00:19 rbarnes has joined #webauthn 17:00:29 SamSrinivas has joined #WebAuthn 17:02:39 apowers has joined #webauthn 17:02:48 OK 17:02:51 present+ nadalin, rbarnes, jcj_moz, apowers 17:03:12 vgb has joined #webauthn 17:03:17 present+ 17:04:10 JeffH has joined #webauthn 17:04:18 present+ 17:07:03 present+ samsrinivas 17:07:28 I may be caller #1 (Rob Trace) 17:07:39 Rolf has joined #webauthn 17:08:09 +scribe: jcj_moz 17:08:17 scribenick: jcj_moz 17:08:23 present+ 17:08:55 nadalin: We have 4 PRs open, like to have a discussion about those to get them accepted. We postponed two from last week, so we can look at those. 17:09:02 gmandyam has joined #webauthn 17:09:42 gmandyam has joined #webauthn 17:09:48 vgb: 151 is on me. Rolf and I had some offline email discussion where we came up with a direction to take this, and as Rolf puts it, we're talking about having this kind of standard lvl 2 structure which standardizes the way the clientData is embedded and how authenticatorData are formatted, and that would go into the level 1 format which is specific to the attestation format. 17:09:58 ... We reached agreement yesterday, and I need to write it up 17:09:59 present+ 17:10:12 nadalin: So there will be a generalized structure in the document to hold the specific structures? 17:10:57 vgb: Right. In that sense, it'll be like the current PR where there's a standardization of the manner in which the individual assertions can be conveyed. There'll be more text around how the trust level of these gets determined, and I'll have to do a rewrite of the verification section. 17:11:31 JeffH: I have to point out a couple of process things. You guys basically have done a 2-person design time, but since the design rationale on the list, it'd be good to put all your messages on the list, or write up a design rationale and post it to the list. 17:11:41 ... Not just have a PR that modifies the spec w/o rationale. 17:11:51 Rolf: Happy to share the email conversation. 17:12:10 vgb: I was also going to write up the design rationale in the issue. That seems more comprehensible than the long, raw email thread. 17:12:31 JeffH: My process point is that the design rationale should be captured somehow. The email exchange is less effort. But it should be captured publicly somewhere. 17:12:37 vgb: I'll condense it into a summary in the issue. 17:12:52 ... I was going to do that while I update the PR. I'll put a cleaned up version of it in the issue. 17:13:12 nadalin: That should get us... after you update it, people can review it and we can get this one by next week. 17:13:21 JeffH: This has implications for PR #192. 17:13:32 nadalin: We can come back to #192 now and come back to the eTLD. 17:13:52 JeffH: #192 is ready to go to merge in, but there are known issues. #161 will have some effect on it, but not a lot. 17:14:30 ... But we could merge in #192 now and that shouldn't make anything harder for #161. It may be easier to finish up 161 with #192 already merged. 17:14:43 ... The one open issue is the syntax for the identifiers -- there's two open proposals. 17:15:25 ... We don't know who prefixed 'webauthn' on the identifiers, but we don't really need that because the registry will permit unambiguous lookups and deduplication 17:16:01 ... The recommendation to prefix with a company still causes collisions, so the Java-like reverse domain name is a way. 17:16:11 ... But it's a SHOULD because there's no mechanism to enforce 17:16:26 ... But it's probably a more workable suggestion than prefixing with just a company name. 17:16:38 ... This is not a big huge issue, but something to polish out. 17:17:30 gmandyam: I have a PR outstanding for the registry itself, and I expect it to merge, but about prefixes - they're also used to clearly designate formats that are proposed but haven't fulfilled criteria for inclusion 17:17:38 JeffH: I disagree with that. 17:17:57 ... If someone registers something, it will by the act of registering it, conform to the registry 17:18:23 ... If someone has an unregistered identifier that works in their implementation, they don't have to prefix it. It doesn't matter. We're just making a suggestion to avoid collisions at runtime. 17:18:53 gmandyam: OK, but the thing is if the prefix has already been taken, anyone who's implementing should look at the registry to avoid a clash 17:19:02 JeffH: But all you can do is suggest, there's no police. 17:19:08 gmandyam: Why are we suggesting in the text? 17:19:18 JeffH: Because we want to nail down the identifier syntax in a place that's hard to change 17:19:26 gmandyam: I believe it should be nailed down in the registry 17:19:38 JeffH: It is, and that's all that's necessary in the registry context 17:20:03 JeffH : Your outstanding proposal doesn't read on this discussion at all 17:20:14 ... I have some questions about it but I'll do that on email 17:21:35 ... I think the chairs need to figure [process for editorship of the registry document] out 17:22:07 nadalin: When people have authored documents that the WG has accepted, those people usually become the editors. We can change that process if there's interest. 17:22:36 gmandyam: I authored a w3 style registry, after discussion with JeffH we went with an IANA-style registry 17:22:59 JeffH: I'm not out of hand opposed to co-editing, but I haven't had time to fully look into it and have an outstanding comment 17:23:22 nadalin: OK, with that, are we done right now with this particular topic 17:23:34 JeffH: I don't think the chairs are done, but we don't need to discuss it this instance 17:23:40 * instant 17:24:02 nadalin: We still have #162, which comes back to vgb with a little discussion on the list. JeffH weighed in about eTLD+1 options here. 17:24:13 ... do we think that we have a WG consensus yet? 17:24:33 alexei-goog has joined #webauthn 17:25:19 vgb: I think Dirk has a good suggestion here, which I need to writeup. I was trying to research Yaron's comment here where he's talking about RFC7719 that eTLD+1 is not well-defined, which as JeffH has pointed out will again lead us again into the swamp of the IETF RFC with the WHATWG definitions of Origin aren't entirely identical, so we're going to have to resolve how this gets bound up with the Origin issue. 17:25:35 JeffH: I have thoughts on that. 7719 is a recent informational that's trying to make sense on DNS terminology. 17:25:45 ... I have feedback to give on their section on eTLD and such... 17:26:09 ... I was going to reply after the call to Yaron's comment. The term eTLD is generic, but a Public Suffix refers to a particular source of that information. 17:26:22 ... There are actually mulitple sources of that on the Internet, for example all the CAs maintain their own lists. 17:26:39 ... We're also not mandating in the spec that people use the PSL, which is just one source you can attain the information 17:26:50 ... which is exactly the kind of language we used in the Cookie spec 6265 17:27:21 ... The nominal reply here is that we're OK here, we're using the correct term in the correct way. But the whole thing is a swamp right now. 17:27:43 ... I think currently right now we're skirting that swamp effectively, but it is a swamp. 17:28:00 rbarnes: If a browser doesn't know what an eTLD+1 is, it can't survive in the world, so it's practical to assume this thing exists. 17:28:39 vgb: So, since we're on this topic, what is our definitive direction forward on Origin in general? Are we going with WHATWG HTML5 spec, or the official HTML5 spec? Right now we have RFC something-or-other, but someone objected/ 17:29:20 JeffH: I've done some looking into this and talked to Mike West about it; what he's doing in the Cookie specs in IETF and W3 is that he's citing the specs that the browsers are implementing 17:29:51 ... If the W3C needs to reference W3 specs, then W3 should figure out the impedance mismatch. 17:30:02 vgb: Do other browser implementers agree? 17:30:30 rbarnes: I don't have a strong opinion about this. I think whatever else the rest of the W3C is following, we should follow that. 17:30:34 JeffH: Problem is that it's not clear. 17:30:57 Dirk: We're not longer talking about 162 and the ETLD issue, it's a different problem? 17:31:11 JeffH: It's related, since we need to reference into the HTML URL in fetched specs, probably 17:31:20 Dirk: I don't understand the problem trying to solve. 17:31:55 ... I understand the problem with eTLD+1 and the browser already has to deal with these. Browsers make local decisions about that. I think we should in the spec say 'hey browser, use your normal approach' 17:32:09 ... but then you were saying that Origins were ill-defined, and that is confusing 17:32:43 vgb: We have several issues on this, they're all casting doubt on the notion that it's clearly understood what an Origin and an eTLD+1 is, and how to test an Origin for equality. 17:32:51 ... People's concern is that there may be more than 1 definition 17:32:58 Dirk: Where are we testing origins for equality? 17:33:08 vgb: We need to test that RPIDs match. 17:33:54 https://tools.ietf.org/html/rfc6454 17:33:56 JeffH: Obsoleted 6454 in the WHATWG. Also claiming to have obsoleted the URI spec 17:34:35 dirkbalfanz has joined #webauthn 17:34:39 gmandyam: He's obsoleted it, but has Gecko agreed? 17:34:53 JeffH: My understanding is the guts of the major browsers follow the WHATWG specs 17:35:14 rbarnes: I'm not aware of any policy change from Firefox; as far as I know we're still RFC-bound 17:35:21 https://fetch.spec.whatwg.org/#origin-header 17:35:36 rbarnes: Looking at the fetch RFC, maybe not a substantive change? 17:35:43 [apps-discuss] RFC6454 "the web origin concept" obsoleted? https://www.ietf.org/mail-archive/web/apps-discuss/current/msg14985.html 17:35:47 JeffH: 4-tuple not a 3-tuple. Added Domain. 17:35:59 rbarnes: The ABNF only has scheme-host-port from my link 17:36:11 JeffH: There's an underlying object that's now a 4-tuple 17:36:42 JeffH: I just pasted in my note to the Apps discuss list from July trying to raise consciousness as to what's going on with the impedance mismatch between all the specs. 17:37:12 ... I agree with Mike West that we don't need to solve this, we just need to reference something that works in our spec. If there's a problem when we try to go to Recommendation, it's the W3C's problem to fix that because we're doing the best we can do at this point. 17:37:26 gmandyam: When you say a 4-tuple vs. 3-tuple... 17:37:41 JeffH: Ane added Domain, which I'm not deep enough to understand yet 17:37:44 3-tuple = scheme/host/port, 4-tuple adds domain 17:37:53 (* Ona?) 17:38:25 vgb: Going to leave this open, but this whole discussion around Origin, but I want to be cognizant that if unresolved this will come back to bite us 17:38:47 here's the 4-tuple thing: https://html.spec.whatwg.org/#origin 17:38:48 ... any progress we can make on this, like a WG consensus on normative references or definitions, would be good. 17:39:07 nadalin: If people stopping in during TPAC when we discuss this may have some interesting views on this 17:39:18 [nadalin will buy beers] 17:41:08 Reference: https://www.cs.columbia.edu/~angelos/Papers/2014/redbutton-usenix-sec14.pdf 17:42:08 rbarnes: Returning to #162... 17:42:12 nadalin: OK, nice try Richard 17:42:17 Basically, receivers may"spoof" an origin when retrieving webpages delivered via broadcast access. In this case, I can see why a 4-tuple for origin is important to the browser. 17:42:24 rbarnes: Only open question is Dirk's proposal vs. this proposal 17:42:41 ... Dirk's got an alternative syntax for doing this. Dirk, do you want to persist with this general proposal or letting this land as-is? 17:42:49 JeffH: vgb is writing up Dirk's proposal as a PR 17:42:57 rbarnes: OK, lost track of that 17:43:08 rbarnes: OK we'll look for his writeup 17:43:19 ... I think we're done with this one then 17:43:24 nadalin: That gets us through the open PRs. 17:43:32 ... We still have a bunch of CR-issues to look at 17:43:48 [groaning] 17:44:08 JeffH: Maybe we should concentrate on WD-02 for now, so we can have it done by Lisbon 17:44:14 nadalin: Sounds fine to me. 17:44:33 nadalin: On to https://github.com/w3c/webauthn/issues?q=is%3Aopen+is%3Aissue+milestone%3AWD-02 17:45:01 vgb: we also have to do a self-asessment for Accessibility, too. 17:45:15 vgb: #6, what are we doing here? 17:46:08 alexei-goog : If I look at this correctly, how does the authenticator tell the RP what transports it supports. One answer was the MDS. 17:46:28 .. the other question is how does the RP tell the client about this information? There the MDS doesn't help much 17:47:12 Dirk: Need to know if this authenticator is something we need to talk to over Bluetooth or NFC or USB... no point telling user to turn on Bluetooth if the device is NFC. 17:47:23 gmandyam: In U2F, wasn't some of this encoded in the x509 cert? 17:47:54 alexei-goog: Right, so there are 2 parts: how does the authenticator tell the server, and 2( how does the server tell the client? #1 was in the cert 17:48:19 ... but now we're talking about the part that in U2F was in the API call so the client call 17:48:28 .. so that the client could know 17:48:51 gmandyam: Could overload the Crypto Key interface 17:48:58 Dirk: How are we doing this in U2F today? 17:49:26 alexei-goog: In U2F, during registration the Authenticator sends an X509 that has Key Handles in the response 17:49:53 s/x509/x509 cert/ 17:50:10 .. U2F devices, in their x509 cert, during registrations, send their list of supported transports. The server stores this alongside the Key Handle in the DB, and during API calls from the RP to the client, the RP tells the client what transports to use 17:50:45 ... In w3c language, the server tells the client here's a whitelist, and here's a list of transports for a given credential ID 17:50:54 dirkbalfanz: Does that work if we do the same thing here? 17:50:58 alexei-goog: It should ,yes 17:51:18 ... so that would be going into the Whitelist 17:51:36 vgb: I think you're suggesting adding an optional element to Credential Description 17:52:29 vgb: We need to decide what to do when the RP gives nonsensical values. The browser may even know it's wrong. 17:53:17 alexei-goog: Right now, for example, in U2F we have these authenticators that work over BLE, or USB, or over just one of those. In an API call, the server may ask a mobile browser to use a credential that's only available over USB which isn't doable, so the browser rejects it right away. 17:53:39 ... But some credentials may be available over multiple transports and so the browser sends the request over the transports that do exist 17:54:23 vgb: OK. Do you want to write it up, alexei-goog? 17:54:34 alexei-goog: Sure. I'll add a comment to that issue and then write it up. 17:55:12 JeffH: One thought that occurred to me that you might want to include: Might not some of this transport stuff be buried in the platforms' abstraction, so the client doesn't need to know it? Maybe it will matter where WebAuthn gets embedded in the stack? 17:55:17 alexei-goog: I don't think I follow? 17:55:34 JeffH: u2f knows about transport hints because the platform doesn't know about it. 17:55:53 alexei-goog: The way I understand this would work, platforms would propose an API to clients, and clients have to figure out how to talk about this 17:56:14 JeffH: This raises the question of, is CTAP the transport interface, and how does this get addressed in CTAP? 17:56:34 [egg-throwing] 17:57:18 alexei-goog: I think the answer is that CTAP would operate at a lower-level, so after you've already made a decision as to which transport to use, CTAP would be the protocol on that transport. And that decision has to be made beforehand. 17:57:33 JeffH: and what we mean by CTAP is the USB, BLE and NFC specs rolled together 17:57:53 nadalin: Issue #8, which JeffH opened. 17:58:15 JeffH: In terms of all our discussion of Origin we are chipping away at 17:58:31 vgb: Is there anything to do specific with this issue, or can we close this one and handle the others? 17:58:58 ... This one is about native apps vs. web platform, and maybe this should just be closed? 17:59:05 JeffH: I'll think about it, maybe this can be 17:59:40 nadalin: #53 17:59:53 vgb: That one just needs to be done, not controversial. 18:00:00 JeffH: Let's mark it OK to do and assign it to vgb 18:00:11 nadalin: We have the TAG review feedback, #60 18:00:29 ... Do we finally have a consensus on what to do here? 18:01:10 JeffH: vgb, mike west agreed that these are separate specs and not necessarily intersecting, and we need to consider changing names to not collide? 18:01:29 vgb: Yes, Mike was sad but agreed. And we have 3 things to do, and 1 and 3 are already sorted. 18:01:57 ... the middle one that remains is that we define an interface Credential and Mike West defines Credential and they're not the same thing. That's what really needs to be fixed. 18:02:02 JeffH: Sounds simple. 18:02:12 vgb : Yes, to the extent that naming things is simple. 18:02:31 nadalin: #86 18:02:41 vgb: This will be fixed with the attestation change. 18:03:00 ... this will get fixed as part of that PR that will be updated with Rolf's feedback 18:03:18 nadalin: Issue #99 18:03:56 vgb: It sounds like JeffH thinks this can be closed. 18:04:03 JeffH: Yes. I think it can. 18:04:42 [Rolf will look and let us know.] 18:04:55 nadalin: We've discussed 161, 162, we have... issue #178. 18:05:04 ... and no one has really commented on this one. 18:05:18 vgb: This is one of those that it depends on which reference you use for Origin and such. 18:05:22 JeffH: I'll assign it to myself. 18:05:47 JeffH : Issue #179. 18:06:23 gmandyam: I'm confused- do we have a rule of thumb on this? Do we use USVString when it originates outside the browser and intended to go to another entity, but DOMString ... ? 18:07:10 vgb: My understanding is that USVString is... let me paste into IRC a reference 18:07:42 one reference: http://heycam.github.io/webidl/#idl-USVString 18:07:55 JeffH: From the IDL spec it's hard to discern what they actually mean 18:08:04 alexei-goog: I need to drop off 18:08:09 SamSrinivas: me too 18:09:32 Rolf has joined #webauthn 18:09:45 I am ok with closing issue 99. 18:10:03 gmandyam: It's still not very clear as to when you use it and when you don't. 18:10:32 vgb: My understanding is that DOMString is a logical thing, it's abstract. USVString is a particular serialized implementation of that thing, particularly Unicode. 18:10:46 gmandyam: I understand that, but I don't see where you pick to use it 18:11:10 ... If it's internal to the browser and not shared externally, it seems DOMString is OK, but the comment suggests we shouldn't use it at all 18:11:37 vgb: In some places we say that you should take the UTF-8, or the lowercase utf, and that is sloppy terminology he's objecting to 18:13:39 JeffH: We use "UTF8 String" or "UTF-encoded string" in a few places... 18:13:43 vgb: This to me is editorial 18:13:50 ... The rest of it is mostly to do with Registry. 18:15:12 [topic change to the Registry comments] 18:17:34 [gmandyam is concerned that the spec data is spread across multiple sources, W3C, IANA] 18:18:13 [JeffH clarifies that mnot is intending that the process for submission of extensions would go into the registry, where it's easier to maintain than in the difficult-to-update spec] 18:18:28 nadalin: gmandyam, do you still want to work on this? 18:19:06 gmandyam: Yes, I do, but I'm waiting on vgb to finish his attestation proposal, I may have to post questions on the list 18:19:17 where "this" is #155 and PR #192 18:19:43 & pr #193 18:20:22 nadalin: As I understand it then, we're OK with going ahead with JeffH's proposal, and JeffH and gmandyam will take over editorship of the registry document. 18:20:44 ... So that gets us through the WD-02 stuff 18:20:47 ... for now! 18:21:26 vgb: Circling around to what we started at the beginning, does that mean we can merge in 192 and 193? 18:21:30 [agreement] 18:21:35 vgb: OK, I'll do that now. 18:21:58 nadalin: Thanks Mike Jones for writing the blog post 18:22:09 ... Looks like we're on schedule to make the TPAC date. 18:22:47 ... There was some discussion by Sam from W3C on trying to resolve conflicts between the Privacy and WebAuthn WGs 18:23:26 ... Is there anyone on this call who has the in-person TPAC calendar conflict with the PING group and WebAuthn? 18:24:01 ... I've gotten that one conflict notification, but if no one has that conflict I'm willing to let this go. 18:24:29 [ no real concern over that ] 18:24:51 nadalin: Does anyone have an objection to keeping the schedule as it is now? 18:24:55 [ no comments ] 18:25:04 nadalin: OK, leaving it as-is for an all-day Tuesday meeting at TPAC 18:25:09 ... that's all I have for the agenda today 18:25:16 ... Thanks everyone for being so interactive today! 18:25:19 ... Talk to you next week! 18:25:41 Zakim, list participants 18:25:41 As of this point the attendees have been nadalin, rbarnes, jcj_moz, apowers, vgb, JeffH, samsrinivas, Rolf, gmandyam 18:25:44 Zakim, list participants 18:25:44 As of this point the attendees have been nadalin, rbarnes, jcj_moz, apowers, vgb, JeffH, samsrinivas, Rolf, gmandyam 18:25:56 RRSAgent, generate minutes 18:25:56 I have made the request to generate http://www.w3.org/2016/09/07-webauthn-minutes.html jcj_moz