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.
<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[End of scribe.perl diagnostic output]