<wseltzer> scribenick: jcj_moz

nadalin_: Make sure everyone registers their attendance on IRC.
... 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.
... 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.

mike: I'm here on the phone.

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?
... The big thing is changing the HTTPS from a SHOULD to a MUST.

<wseltzer> https://github.com/w3c/webauthn/pull/147

jcj_moz: I'll take a look and comment after this call.

<rbarnes> #147 lgtm

<wseltzer> https://github.com/w3c/webauthn/pull/145

Vijay: PR #145, I went ahead and merged. It's IDL technicality, so I assume there's no objection to that
... It's basically just moving parameters around the IDL to fix up the API better

<rbarnes> yeah, #145 was one i had wanted for a while, so 👍

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.
... 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.
... 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.
... So if someone else has an alternate approach there.
... There are some things problematic in master. There are really 4 options.
... Option 1: Keep what's in master, and fix what's wrong with it.
... (I missed the other options)
... We're looking for what alternatives are possible.

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.

Vijay: Yes.
... The conversation started out with 'why do we need a whitelist?'
... 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'.
... In that case you'd pick the appropriate Credential object and call that your whitelist

dirkbalfanz: But what's in Master, nor what you sent out - indexWithNoCred - follows that

Vijay: Right, but indexWithCred does follow it. It's not exactly, but there's a change you could make to make it follow exactly.

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.

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.
... 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

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?

Vijay: No, makeCredential always returns one object, but getAssertion becomes a member function

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.

gmandyam: OK, so this is really beyond the enum, this is how , this is where the getAssertion method hangs off of

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

gmandyam: So how does the reference to the Credential get persisted if you call from the RP and you go this route?

Vijay: The object still gives you an ID reference that you can store on the RP-side

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
... The marshal, what's in the spec right now, is just grab the ID. The unmarshal is to put that ID in the makeCredential

Vijay: The object is never directly exposed. You marshal it out, but you never instantiate a Credential object directly.

rbarnes: But that seems sadly asymmetric. You should either have an opaque blobs in both cases, or a ...

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
... The other approach returns an Object for purely technical reasons, and so you return an Interface so that you can return multiple objects.

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
... You could return something else. Do we want to actually allow such an object available in JS?

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,
... It's not a method, it has no member methods
... it's not a true object.

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

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

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.

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
... so for this the script creates 10 placeholder objects for them, then calls getAssertion on all of them

<rbarnes> Promise.race(credentialIDs.map(x => (new Credential(x)).getAssertion())

rbarnes: That's what i'm imagining
... I agree that's more code for the JS than having the browser doing the work

Vijay: This is fairly compact but it's still a performance issue, it creates N objects where all but one is disposable.

rbarnes: But it seems like some degree of that has to happen internally to getAssertion anyway

Vijay: Yes, but internally there's already an issueRequest List that a client has to keep
... So it can go cancel them
... so it's true this does exist, but then again that's per-authenticator, O(num_authenticators), whereas your approach uses O(num_identifiers)

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.
... so if it has all the credentials at once, it can make decisions about reordering that it can't if it's handicapped
... 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.

rbarnes: Can you clarify the smarts the browser's applying in that case?

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
... 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
... If we know NFC is enabled we can try that first before trying BLE

rbarnes: So we can take the ones that may have higher latency and try those first?

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
... 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
... time

dirkbalfanz: One problem is that the Credential object may need a close (or cancel) function

<dirkbalfanz> https://chromium.googlesource.com/chromium/src.git/+/master/chrome/browser/resources/cryptotoken/

dirkbalfanz: 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
... Perhaps we should get Juan to give an estimate of how complicated this would be to move into Application logic.

rbarnes: I'm not dogmatic on this, I just feel like we should move logic into the JS where we can

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
... The browser must maintain its own internal state as to how to cancel the others once one succeeds

<vgb> jcj_moz: Dirk and Alexei make good points

<vgb> ... pretty well explained why it can't be OO, happy keeping it as is

<vgb> ... also note that an RP who wants to influence selection could call getAssertion multiple times to get multiple promises

<vgb> alexei-goog: Also our implementation respects the order of the allowList from teh RP

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

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.

alexei-goog: We're talking about getAssertion not makeCredential

gmandyam: It's not possible to do authenticator selection for RPs in this case
... Credentials are created, but RPs can't select what kinds of authenticators it wants to use except outside the AAGUID extension

alexei-goog: The RP knows which credentials correspond to which kinds of authenticators, so it can just not include those in the whitelist.

gmandyam: The RP can say 'make a credential that satisfies this level of security otherwise fail' but we don't have anything like that
... There is currently no clean mechanism in the API for this

alexei-goog: This is on purpose, so we don't create a policy language in the API

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

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...

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.
... 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
... 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
... take a look at that see if you feel having the type is better

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
... 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

Vijay: Isn't that what we already have in the spec today?

Adam: OK

rbarnes: any other questions or comments on that topic?

Vijay: One more thing I wanted to talk about, was this conversation we're having around Attestation.
... 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
... In the packed attestation structure, there's a lot of duplication between what goes into the rawData and what goes around the rawData
... Does anyone know any reasons why the packed attestation should remain as it is?

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
... my suggestion is to throw everything except packed attestation into a registry
... 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

Vijay: Sure, that sounds fine to me
... 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
... I'd love to hear the opinions of the rest of the group about spec versus registry

wseltzer: Are we losing everyone from the call?

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.

<gmandyam> Call closed; I will follow up via email. Thanks to the scribe!

Vijay: The registry vsersus spec question?

Mike: To me this not either/or, we should establish a registry, so that new docs can define new formats
... Leave those in, it improves interoperability

rbarnes: we should continue this on the list, we're at time now
... All right guys, thanks a lot

This is scribe.perl Revision: 1.144  of Date: 2015/11/17 08:39:34  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: jcj_moz
Inferring Scribes: jcj_moz

WARNING: No "Topic:" lines found.

Default Present: jcj_moz, gmandyam, vgb, apowers, dirkbalfanz, rbarnes, Rolf, ketan, weiler, wseltzer, christiaanbrand, alexei-goog, selfissued
Present: jcj_moz gmandyam vgb apowers dirkbalfanz rbarnes Rolf ketan weiler wseltzer christiaanbrand selfissued

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

Found Date: 27 Jul 2016
Guessing minutes URL: http://www.w3.org/2016/07/27-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