See also: IRC log
<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.
jcj_moz: I'll take a look and comment after this call.
<rbarnes> #147 lgtm
Vijay: PR #145, I went ahead and
merged. It's IDL technicality, so I assume there's no objection
... 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.
... 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
... 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
... 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
... 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
... 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
... 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
dirkbalfanz: One problem is that the Credential object may need a close (or cancel) function
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
... 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?
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
... 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
... 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
... 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
... 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[End of scribe.perl diagnostic output]