See also: IRC log
<wseltzer> scribenick: jcj_moz
<wseltzer> Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2017Apr/0244.html
wseltzer: We have a pretty detailed agenda, so the team can help move things forward
angelo: Maybe we can just start,
we are all looking at #384
... jeffh has given his stamp of approval, does anyone have
comments? are we ready to move forward?
vgb: I put in a minor comment
this morning that is not really blocking
... It's a thing we need to address down the road but we don't
need to block the PR on it
<wseltzer> https://github.com/w3c/webauthn/pull/384
vgb: I'd like to get dirk and alexei-goog to chime in as well because they had the most coherent counter to the proposa
alexei-goog: My understanding is
the call on Friday ended with alexei-goog and dirk agreeing to
merge this in and deal with the fallout
... We reserve the right to tel you 'we told you so' multiple,
multiple times
jeffh: Yeah, so I've a couple minor nit comments that if mikewest agreed could fix up before merging
mkwst: I'll get those after this call
jeffh: We need a real, proper security considerations section somewhere
angelo: So, after mkwst makes the change that jeffh requested, are we ready to merge?
(jeffh will do the merger)
angelo: mkwst, you'll be able to make the change today?
mkwst: Yes.
<wseltzer> https://github.com/w3c/webauthn/pull/409
angelo: We're talking about things blocking CTAP, PR #409, I want to clarify that this is everything in PR 384, the only addition is having a new bit
alexei-goog: I took a look at the current CTAP spec and I don't see any reference to 'TUI'
vgb: There's an outstanding PR from Alex Rudisky
alexei-goog: There's a PR out in CTAP that has TUI in it?
vgb: Yes, I can dig up the number
jeffh: We shouldn't be using the
term 'identity'
... we should stay away from the term, we're only doing
authentication
angelo: The idea here is the authenticator tests the fingerprints...
jeffh: Doesn't User Verification Method signal that?
vgb: #1 this is in the core
thing, so even if you don't implement UVM it's there
... #2 the TUP only shows if the user is present, this
stands-in for when the user is identified
angelo: So Jeffh wants to avoid the name...
jeffh: I didn't say I was OK with
adding the bit, either
... this is an ad-hoc piece
angelo: We have about 7 bits left, are you saying we should not use them?
jeffh: No, I'm saying this is an ad-hoc approach
angelo: This is the kind of use case we have, and based on that use case we've added this new hting
selfissued: We shouldn't block on
this
... (we should do it)
<selfissued> This is an important distinction between any person present and a specific person present. Unless we have a specific counter-proposal that has support, we should do this.
<weiler> https://github.com/w3c/webauthn/pull/217
alexei-goog: I need to read it, and it assumes changes to CTAP which I also haven't read
vgb: I hear jeffh's concern that
we might be doing things in a less methodical way than we
want
... We did go through a certain approach to try and get
agreement about the use cases for this, and TUI - badly named
though it may be - helps with one of those use cases we came up
with
... One of the things we need to figure out is: either we're
missing something in our use case classification (which we did
a long time ago) or this does not implement that
classification
... I'd like to get a better sense of the objection
jeffh: OK, but we're not trying to merge this today?
angelo: No, we're just trying to
have the discussion
... PR 378 is another one that I'm looking at right now
gmandyam: I have a question --
TUI... So the user verification bit is part of the auth data
and it goes to a discrete auth. Is the idae that there might be
authenticators that might support two modes of authentication?
Like a touch and also a fingerprint?
... Is this for multi-mode authenticators?
angelo: The intent of this is if it's a multi-mode authenticator, then as long as this can identify the user that's fine
gmandyam: No...
vgb: The intent of this bit is no
different than TUP
... The existence of this doesn't mean we're postulating about
the mechanics of autheticators, we just want to know what it
did
... User Verification is supposed to be used the same way, it's
signed over that says I actually verified the user's
identity
jeffh: You performed user verification
vgb: Yes, that. This may lead to
developers that find it useful to be multi-mode like that
... but this is to define when I established presence, vs when
verified identity
selfissued: Process point- we should do the priority implementation PRs
angelo: The reason I want to handle 409 is that it's blocking CTAP
alexei-goog: I think it'll be easier to handle after the CTAP PR merges
angelo: moving on to 378
https://github.com/w3c/webauthn/pull/378
angelo: I believe jeffh made some comments
jeffh: I need to review this in
the same ...
... 378 and 409 are related in my nominal perspective
... but I've been distracted with 384 of late, and I'll commit
to reviewing this stuff in the next couple of days
vgb: it's actually 378, 348, and 409
selfissued: At the request of the WG, I've done a lot of work in 389 to clarify extensions, and jeffyasskin believes its ready to merge
jeffh: I was trying to review it before the call
credman: Are 407 / 408 going to break anything?
vgb: They're just adding things to enums and specifying additional behavior
alexei-goog: The attestation
format and the UAF...?
... You might see another one coming down for U2F
jeffh: I don't think those are necessarily... we'd like to get those by CR timeframe, but not WD-05
credman: I agree it's late in the game, but I'm afraid they'll break implementation
alexei-goog: We're doing things that are restructuring the APIs completely. Adding the enum is the least destructive thing we've done this month.
jeffh: Let's review before the next call
<jeffh> 409, 384, 378 -- that is Angelo's list for WD-05
angelo: After 409 and 384 and 378
are merged in, we can apply wd-05 to them later if we
want
... we can have a WD-05 version there, and that'll be the Edge
implementation
... and we'll match the Chrome and Firefox implementations
later on
... and as long as there's no breaking change we'll be fine
<weiler> https://github.com/w3c/webauthn/pull/389
selfissued: I think we should merge in 389 because it's not breaking aknig and it makes a bunch of stuff clearer.
jeffh: I tend to agree
... can I review it ?
... I'm happy to get it merged before next call.
angelo: I don't think it's a priority for implementation
jeffh: I think it is
selfissued: It is a priority for
implementation
... I want the decision on the call that unless jeffh thinks it
is terrible, that he'll merge it by tomorrow
credman: (agrees with the
above)
... We want the WD-05 as soon as possible
... I want jeffh to look at it ASAP so we can close down
WD-05
jeffh: OK
angelo: That's fine
vgb: How do you feel about 350?
<weiler> https://github.com/w3c/webauthn/pull/350
angelo: I think that's important, but it's a fix
jeffh: still some vgb comments.
I'll take a look at that also
... it's stale, it needs a merge
angelo: for 350 I have less of concern
alexei-goog: Looking at 350, it says throw NotFoundError and that seems great, but then it says Key Storage and ....
angelo: That's a mishap
jeffh: So we're not going to review until angelo polishes PR 350
angelo: that's all of the things that I think, that I consider blocking us
credman: I'd like some explanation on 407 and 408
jeffh: I talked with you about those face-to-face
credman: I understood they were coming
alexei-goog: Can you make sure the face-to-face discussion makes it on the list?
jeffh: OK
credman: Is there something you want to tell us?
jeffh: Both Rolf and I have mentioned this in the not too distant past - if you have a UAF-enabled smartphone, you should be able to have a CTAP shim added to it and then use it as a roaming authenticator for a WebAuthn-enabled device
gmandyam: It doesn't even have to be CTAP, it can be <something else>
jeffh: Yes, but there's a zillion devices in the field, so it seems good to enable this
gmandyam: Qualcomm is in favor of this
alexei-goog: When we were
deciding if we needed a separate credential type for U2F, we
decided we didn't need to
... we decided (the metadata) was enough
... Is that not the case for UAF? Is it not possible to
indicate you're OK with a UAF device given what's there?
jeffh: That's a good question, as part of review we'll have to answer that
alexei-goog: We did think about this, adding a U2F type, and we decided we didn't need to
The list of PRs to go through before the end of the week, and close, is 409, 384, 378
Consensus is that should close out WD-05
Meeting adjourns with the acknowledgement that we should be releasing WD-05 next
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/eus is/is/ Default Present: jfontana, weiler, jochen___, wseltzer, battre, jcj_moz, jeffh, mkwst, vgb, angelo, jyasskin, kpaulh, selfissued, alexei-goog, apowers, gmandyam, nadalin Present: alexei-goog angelo apowers gmandyam jcj_moz jeffh jfontana jochen___ jyasskin kpaulh mkwst nadalin selfissued vgb weiler wseltzer Found ScribeNick: jcj_moz Inferring Scribes: jcj_moz Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2017Apr/0244.html Found Date: 19 Apr 2017 Guessing minutes URL: http://www.w3.org/2017/04/19-webauthn-minutes.html People with action items:[End of scribe.perl diagnostic output]