16:59:42 RRSAgent has joined #webauthn 16:59:42 logging to http://www.w3.org/2016/07/27-webauthn-irc 16:59:44 RRSAgent, make logs public 16:59:46 Zakim, this will be 16:59:46 I don't understand 'this will be', trackbot 16:59:47 Meeting: Web Authentication Working Group Teleconference 16:59:47 Date: 27 July 2016 17:00:34 zakim, code? 17:00:34 I have been told this is WebAuthn 13 July 2016 17:00:52 present+ 17:01:18 zakim, this is webex 617.324.000 647951360 17:01:18 got it, wseltzer 17:01:25 gmandyam has joined #webauthn 17:01:34 present+ gmandyam 17:01:40 present+ 17:01:42 present+ 17:01:47 present+ 17:01:52 christiaanbrand has joined #webauthn 17:01:53 present+ 17:02:10 dirkbalfanz has joined #webauthn 17:02:19 rbarnes has joined #webauthn 17:02:26 present+ 17:03:31 nadalin_ has joined #webauthn 17:03:54 zakim, who is here? 17:03:54 Present: jcj_moz, gmandyam, vgb, apowers, dirkbalfanz, rbarnes, Rolf, ketan, weiler, wseltzer, christiaanbrand 17:03:57 On IRC I see nadalin_, rbarnes, dirkbalfanz, christiaanbrand, gmandyam, RRSAgent, vgb, weiler, nadalin, jcj_moz, adrianba, mkwst, slightlyoff, Zakim, trackbot, wseltzer 17:06:04 Not knowing who is chairing or who scribed recently, I propose christiaanbrand 17:07:39 scribenick: jcj_moz 17:08:25 nadalin_: Make sure everyone registers their attendance on IRC. 17:08:41 present+ 17:08:44 alexei-goog has joined #webauthn 17:08:52 present+ 17:09:05 ... we have a scribe, so let's go ahead. The agenda is to look at the open PRs, look at the issues that are outstanding: the attestations, and look at the schedule that's in place. 17:09:25 ... and look at the timing to produce another version. Vijay sent out a note on that earlier this week. So with that, we can look at the open PRs. 17:09:38 mike: I'm here on the phone. 17:09:40 present+ selfissued 17:10:12 Vijay: PR 147 has been out for a while. JeffH signed off on it. Anyone else want to look at it? Anyone else want to look at it? 17:10:44 ... The big thing is changing the HTTPS from a SHOULD to a MUST. 17:10:47 https://github.com/w3c/webauthn/pull/147 17:10:55 jcj_moz: I'll take a look and comment after this call. 17:10:58 #147 lgtm 17:11:00 https://github.com/w3c/webauthn/pull/145 17:11:29 Vijay: PR #145, I went ahead and merged. It's IDL technicality, so I assume there's no objection to that 17:11:46 ... It's basically just moving parameters around the IDL to fix up the API better 17:12:11 yeah, #145 was one i had wanted for a while, so 👍 17:12:20 Vijay: So the other issue is what do we do with the Credential type. I sent out a couple of possible approaches . You're welcome to comment on the two approaches or to produce a 3rd one. 17:13:00 ... The first is: What happens if we pull out Credential type entirely. In that approach there are two possible ways to add the moral equivalent of a type if we wanted to. One is through extensions, the other is through the algorithms dictionary. 17:13:37 ... The other possible approach is to go full-on through an Object, and embrace OO, create the object with a constructor. In doing it, it came out a little bit forced, so I'm not as fond of that approach after having gone through that exercise. 17:13:57 ... So if someone else has an alternate approach there. 17:14:56 Vijay: There are some things problematic in master. There are really 4 options. 17:15:08 ... Option 1: Keep what's in master, and fix what's wrong with it. 17:15:24 .... (I missed the other options) 17:15:42 ...We're looking for what alternatives are possible. 17:16:21 dirkbalfanz: I thought the question was whether this whitelist in getAssertion is necessary or not. Master still has the whitelist, though it's called an allowed list. And what you sent out still has it. 17:16:23 Vijay: Yes. 17:16:37 Vijay: The conversation started out with 'why do we need a whitelist?' 17:17:08 ... But the question was flavored more not 'why do we need a whitelist at all', but 'why instead of a whitelist couldn't we make the Credential an object, and make getAssertion a method on this object'. 17:17:21 ... In that case you'd pick the appropriate Credential object and call that your whitelist 17:17:39 dirkbalfanz: But what's in Master, nor what you sent out - indexWithNoCred - follows that 17:17:59 Vijay: Right, but indexWithCred does follow it. It's not exactly, but there's a change you could make to make it follow exactly. 17:19:17 gmandyam: So, if allowList is meant for the RP to say the type of authenticator is acceptable to it without being as specific as the AAGUID list, then we can make the syntax a little more expressive. I mentioned this before in the FIDO context. Right now we have slightly-better than an empty enum, so that seems to be what's the issue. If someone would come forward and define a syntax that provides a richer format. 17:20:07 Vijay: There's two separate issues bound up in this one conversation. One is we have this enum with one value, what good is it at all, which is what gmandyam raised. The other is what jcj_moz raised, which is can we just use an API paradigm instead of a list? Which specifically was making getAssertion a method on a Credential object. 17:20:37 ... So these things are obviously touching in that what you decide on one of them affects how you solve the other, but I'm more interested in solving the API paradigm first and then going on the enum issue 17:21:16 gmandyam: Let's get to the API then. What's the intention if we do it that way? If a makeCredential is called, would there be multiple credentials returned, each corresponding to a different type? 17:21:34 Vijay: No, makeCredential always returns one object, but getAssertion becomes a member function 17:21:57 rbarnes: Let me phrase it this way: Do we put the credential search logic into the browser, or let the API calling these functions do it. 17:22:28 gmandyam: OK, so this is really beyond the enum, this is how , this is where the getAssertion method hangs off of 17:23:22 Vijay: So in working through what if this were an object, then how does this object get created? If you're calling getAssertion, how does the script get the object from a list of IDs from the server. So you have to define a constructor for that object, and so I defined one (and there are other ways), but this is one way 17:23:36 gmandyam: So how does the reference to the Credential get persisted if you call from the RP and you go this route? 17:23:50 Vijay: The object still gives you an ID reference that you can store on the RP-side 17:24:25 rbarnes : The requirement we have here is to have some way to marshal out the Credential object and to unmarshal back. And it needs to be defined so you can unmarshal and remarshal in different browsers 17:24:51 ... The marshal, what's in the spec right now, is just grab the ID. The unmarshal is to put that ID in the makeCredential 17:25:26 Vijay: The object is never directly exposed. You marshal it out, but you never instantiate a Credential object directly. 17:26:01 rbarnes: But that seems sadly asymmetric. You should either have an opaque blobs in both cases, or a ... 17:26:24 Vijay: that's the train of thought I followed in the noCred approach, where you always get an ArrayBuffer, so that's all that ever happens 17:27:00 ... The other approach returns an Object for purely technical reasons, and so you return an Interface so that you can return multiple objects. 17:27:38 gmandyam: Right now the way the standard is defined, you get the ScopedCredentialInfo object back when you makeCredential. That ScopedCredentialInfo.Credential is r/o which could be an object 17:27:53 ... You could return something else. Do we want to actually allow such an object available in JS? 17:28:27 Vijay: That's the conversation. The thing is that's an object, it's a r/o attribute of type Credential. It's an object for purely technical IDL reasons, it has no hidden states, no functions, 17:28:34 ... It's not a method, it has no member methods 17:28:37 ... it's not a true object. 17:29:10 gmandyam: Say for instance that you're able to persistent this with local storage (which wouldn't work), but say it works so you have the object at the ready 17:29:32 Vijay: Not even that, there's just no particular advantage to keeping this object around that you couldn't do by just keeping the ID around 17:30:27 rbarnes : There's one conceptional advantage to my mind: You could say 'give me an assertion with this object' which seems slightly nicer than alternatives. Like Date, the way you get a Date object is to instantiate one from a string and then call methods on it. 17:30:58 Vijay: Let's take this common case. I log into Gmail, I have 10 IDs from the server, they are for devices I carry around 17:31:19 ... so for this the script creates 10 placeholder objects for them, then calls getAssertion on all of them 17:31:25 Promise.race(credentialIDs.map(x => (new Credential(x)).getAssertion()) 17:31:30 rbarnes : That's what i'm imagining 17:31:54 rbarnes: I agree that's more code for the JS than having the browser doing the work 17:32:18 Vijay: This is fairly compact but it's still a performance issue, it creates N objects where all but one is disposable. 17:32:36 rbarnes: But it seems like some degree of that has to happen internally to getAssertion anyway 17:33:01 Vijay: Yes, but internally there's already an issueRequest List that a client has to keep 17:33:02 q+ 17:33:05 ... So it can go cancel them 17:33:32 ... so it's true this does exist, but then again that's per-authenticator, O(num_authenticators), whereas your approach uses O(num_identifiers) 17:34:09 alexei-goog: There's also an advantage to having the browser receive all the credentials at once. The Promise method looks like it's in parallel, but the browser never knows if there's another one coming. 17:34:32 ... so if it has all the credentials at once, it can make decisions about reordering that it can't if it's handicapped 17:35:01 ... as an example: we're playing around on Android for U2F, user may have 5 different keys registered. If the user has NFC on, we can reorder them to try the NFC ones first. 17:35:22 rbarnes: Can you clarify the smarts the browser's applying in that case? 17:35:46 alexei-goog: Browser could be intelligent about how it looks for (remote) authenticators, based on all the requests, it can look for all remote ones in unison 17:36:30 ... We've been improving performance on Android for people interacting with U2F, and we can do smarter things if we can reorder those requests. We can try NFC first, before trying BLE 17:36:40 ... If we know NFC is enabled we can try that first before trying BLE 17:36:54 rbarnes: So we can take the ones that may have higher latency and try those first? 17:37:17 alexei-goog: Yes. Or we can know that the last time the user used this type of transport instead of that type, so we can be slightly more intelligent 17:37:56 ... but the point is that if we find out new ways to be intelligent in the future, we can apply those if we know all the requests at once, but not if we get them one at a tim 17:37:59 ... time 17:38:28 dirkbalfanz: One problem is that the Credential object may need a close (or cancel) function 17:38:31 https://chromium.googlesource.com/chromium/src.git/+/master/chrome/browser/resources/cryptotoken/ 17:39:14 ... I'm pasting (above) the current implementation for Chrome where all the logic is that we'd have to lift up into the Application logic 17:40:21 ... Perhaps we should get Juan to give an estimate of how complicated this would be to move into Application logic. 17:40:35 rbarnes: I'm not dogmatic on this, I just feel like we should move logic into the JS where we can 17:41:17 Vijay: The reason I added the logic I did was to avoid adding a cancel method to each object... the promises model doesn't really do that 17:41:32 ... The browser must maintain its own internal state as to how to cancel the others once one succeeds 17:42:34 jcj_moz: Dirk and Alexei make good points 17:42:47 ... pretty well explained why it can't be OO, happy keeping it as is 17:45:56 ... also note that an RP who wants to influence selection could call getAssertion multiple times to get multiple promises 17:46:23 alexei-goog: Also our implementation respects the order of the allowList from teh RP 17:46:29 alexei-goog: In our optimization, our browser tries to respect the order from the RP, but does override based on history and what's going on around it after that time 17:46:51 gmandyam: My point is that if the RP wants to indicate as part of makeCredential that it only wants credentials protected in a TEE, there's no syntax today do that. 17:47:06 alexei-goog: We're talking about getAssertion not makeCredential 17:47:34 gmandyam: It's not possible to do authenticator selection for RPs in this case 17:47:59 ... Credentials are created, but RPs can't select what kinds of authenticators it wants to use except outside the AAGUID extension 17:48:24 alexei-goog: The RP knows which credentials correspond to which kinds of authenticators, so it can just not include those in the whitelist. 17:48:49 gmandyam: The RP can say 'make a credential that satisfies this level of security otherwise fail' but we don't have anything like that 17:49:04 ... There is currently no clean mechanism in the API for this 17:49:13 alexei-goog: This is on purpose, so we don't create a policy language in the API 17:50:08 Vijay: There's also opinionated API. The problem is that it encourages people to put policy into their scripts which won't change over time, so we want to push people to getting an assertion which will be some level of goodness, and if it's not good enough for you, find a way to supplement it to move up 17:51:00 gmandyam: We circle back to, we don't have a meaningful credential type, we don't want anything beyond the ScopedCredentialType, so this is a rather worthless attribute. Given the group's purpose is not to produce a policy language to match to a type, I don't know what to... 17:51:31 Vijay: Yes, that's a separate conversation. The credential type right now stands for a separate type. If we were ever to rev that then the type would change. 17:52:03 ... If we wanted to rev this issue, you should look at the noCred experiement I made, where I did nothing but pull out the type. You can look at it, see if you like that better 17:52:29 ... in the future, if you ever need something like the type, we could do the same kind of thing where we could specify that there is a different format 17:52:42 ... take a look at that see if you feel having the type is better 17:53:54 Adam: About the promises.Race(). What if instead of doing a Promises.race() you do a custom method for submitting an iterable of Credentials for assertions, so basically pass in an array of credentials that you want to get assertions for, and so the RP has control, and the browser can still manage optimizing 17:54:25 ... I'm talking about instead of having getAssertion returning a Promise, adding a method someplace else that accepts an array of Credentials and then the Browser can figure out how to order and cancel them 17:54:39 Vijay: Isn't that what we already have in the spec today? 17:54:47 Adam: OK 17:55:16 rbarnes: any other questions or comments on that topic? 17:55:43 Vijay: One more thing I wanted to talk about, was this conversation we're having around Attestation. 17:56:09 ... I'll send an email on this. One of the problems we're having right now is that the different attestation formats are inconsistent with each other in the amount of support they have for different things 17:56:54 ... In the packed attestation structure, there's a lot of duplication between what goes into the rawData and what goes around the rawData 17:57:14 ... Does anyone know any reasons why the packed attestation should remain as it is? 17:58:00 gmandyam: One of the things that came up recently is the platform attestations. For Android, you get an either/or, you get either a packed attestation or a safetynet attestation 17:58:34 ... my suggestion is to throw everything except packed attestation into a registry 17:59:11 ... so my suggestion is to take these things that are partially proprietary, like Safetynet or Android-N, like the TCG spec, and throw those into the registry, and we just retain one type, packed attestation, because that's controlled within the spec 17:59:25 Vijay: Sure, that sounds fine to me 17:59:47 ... all I'm going to do for now is to make sure there's a clean separation, so we can lift it up and put it in your registry if you want to 18:00:01 ... I'd love to hear the opinions of the rest of the group about spec versus registry 18:00:30 wseltzer: Are we losing everyone from the call? 18:00:48 rbarnes: Vijay, maybe we can take this to the list. I may have some feelings on this but not from the top of my head. 18:00:54 Call closed; I will follow up via email. Thanks to the scribe! 18:00:58 Vijay: The registry vsersus spec question? 18:01:26 Mike: To me this not either/or, we should establish a registry, so that new docs can define new formats 18:01:47 Mike: Leave those in, it improves interoperability 18:01:50 Zakim, list participants 18:01:50 As of this point the attendees have been jcj_moz, gmandyam, vgb, apowers, dirkbalfanz, rbarnes, Rolf, ketan, weiler, wseltzer, christiaanbrand, alexei-goog, selfissued 18:01:57 rbarnes: we should continue this on the list, we're at time now 18:02:01 ... All right guys, thanks a lot 18:02:28 RRSAgent, generate minutes 18:02:28 I have made the request to generate http://www.w3.org/2016/07/27-webauthn-minutes.html weiler 18:02:53 RRSAgent, make log public 18:24:43 rbarnes has left #webauthn