IRC log of webauthn on 2017-02-13

Timestamps are in UTC.

17:10:59 [RRSAgent]
RRSAgent has joined #webauthn
17:10:59 [RRSAgent]
logging to http://www.w3.org/2017/02/13-webauthn-irc
17:11:01 [Zakim]
Zakim has joined #webauthn
17:11:20 [vgb]
scribenick: angelo
17:11:39 [vgb]
Hi Wendy!
17:13:46 [apowers]
apowers has joined #webauthn
17:13:46 [jcj_moz]
present+ jcj
17:13:51 [angelo_]
angelo_ has joined #webauthn
17:13:55 [Rolf]
present+
17:13:55 [apowers]
present+ apowers
17:14:17 [jeffh]
jeffh has joined #webauthn
17:15:06 [jeffh]
present+ jeffh
17:15:46 [angelo]
angelo has joined #webauthn
17:15:52 [angelo]
I will scrib e
17:15:56 [angelo]
I will scribe
17:16:02 [jcj_moz]
scribenick: angelo
17:16:40 [angelo]
We will start by looking at 321
17:17:18 [angelo]
Vijay is leading the discussion for PR 321
17:17:37 [rbarnes]
rbarnes has joined #webauthn
17:18:46 [angelo]
Vgb: we will look at the diff first instead of going through all of the changes
17:20:23 [weiler]
weiler has joined #webauthn
17:21:33 [weiler]
present+
17:21:34 [rbarnes]
present+
17:22:48 [angelo]
Dirk: the public key is no longer returned by makeCredential
17:23:21 [angelo]
Now the returned object from makeCredential is only clientDataJSON and attestationObject
17:23:58 [angelo]
The logic behind the change is that the client shouldn't have to worry about the key parsing. It'd be best if only a blob is returned.
17:25:32 [angelo]
Another change is regarding U2F attestation format
17:26:24 [angelo]
Alexei: credential ID is missing
17:27:03 [angelo]
Vgb: he will ensure the Cred ID is available there and will fix this problem later
17:28:22 [angelo]
Richard Barnes: I think the logic is backward
17:30:51 [angelo]
Richard's main concern is that there are certain common attributes cross all authenticators.
17:34:00 [angelo]
JeffH: there have been discussions where we decide to push the complexity back to the server side
17:34:54 [angelo]
Richard: I agree that for the browser, it should just give back the attestation blob
17:35:41 [angelo]
Vgb: what we learned is that most servers are already equipped to handle the complexity
17:36:26 [angelo]
Richard: the assumption of Vgb"s argument is all the relying parties care about attestation
17:39:14 [angelo]
Vgb: however, we have to think about what the solution to this problem is. Which step will take care of the complexity, the RP, browser, authenticator?
17:40:24 [angelo]
Dirk: the browser should take care of the complexity. Another point is that we shouldn't have to worry about making a distinction between server and the frontend JS.
17:41:38 [angelo]
Because whether server and JS script takes care of the compleixty is going to shift over time
17:42:02 [yaronf_]
yaronf_ has joined #webauthn
17:44:42 [angelo]
Vgb: we are looking at figure 3
17:45:09 [Axel_Nennker_DT]
Axel_Nennker_DT has joined #webauthn
17:45:25 [angelo]
All parts of the attestation data is standard component
17:47:16 [angelo]
Alexei: why the attestation format, data, and statement is in binary format instead of JS object
17:48:08 [angelo]
Alexei: U2F attestaiton has additional complexity because it doesn't have AAGUID, counter, etc.
17:51:36 [jeffh]
The Concise Binary Object Representation (CBOR) data format (RFC7049) implemented in pure JavaScript: https://github.com/paroga/cbor-js
17:53:10 [angelo]
Vgb: the complexity is either going to be on the authenticator or the RP either way.
17:55:20 [angelo]
wendy, do you mean who is at the F2F
17:57:22 [weiler]
rrsagent, draft minutes
17:57:22 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/02/13-webauthn-minutes.html weiler
17:57:45 [weiler]
rrsagent, make minutes public
17:57:45 [RRSAgent]
I'm logging. I don't understand 'make minutes public', weiler. Try /msg RRSAgent help
17:58:43 [weiler]
RRSAgent, make log public
18:00:45 [angelo]
Vgb: one point made in the past: should we make the API a bit opninate to force people to parse attestation to have additional secuirty protection
18:01:31 [angelo]
For RPs who don't care about attestation, they don't have to parse it.
18:02:40 [weiler]
chair: rbarnes, nadalin
18:02:53 [weiler]
meeting: WebAuthentication WG F2F, 13 Feb 2017
18:05:11 [angelo]
Richard: let's land 321 first. I and Dirk will look at it and see if we can make it better
18:05:45 [weiler]
q?
18:05:57 [weiler]
q+ for administrivia
18:09:06 [kpaulh]
kpaulh has joined #webauthn
18:09:15 [christiaanbrand]
christiaanbrand has joined #webauthn
18:09:22 [samsrinivas]
samsrinivas has joined #webauthn
18:09:26 [samsrinivas]
present+
18:09:58 [Aiki]
Aiki has joined #WebAuthn
18:21:23 [rbarnes]
rbarnes has joined #webauthn
18:23:12 [apowers]
apowers has joined #webauthn
18:27:54 [Aiki]
present+
18:29:49 [Rolf]
Rolf has joined #webauthn
18:32:15 [vgb]
vgb has joined #webauthn
18:34:20 [jcj_moz]
scribenick: jcj_moz
18:34:32 [jcj_moz]
nadalin
18:34:38 [weiler]
weiler has joined #webauthn
18:34:57 [jcj_moz]
nadalin: We're going to merge 321, and then people can comment on it, and we'll resolve the comments in WD-05. We can merge this and put out WD-04.
18:35:13 [weiler]
https://github.com/w3c/webauthn/issues/334
18:35:16 [jcj_moz]
angelo: [brings up #334]
18:35:52 [jcj_moz]
.... There are some concerns about use cases after browser implementations have started
18:36:11 [jcj_moz]
... We want to ship an API that's compatible between all browsers so RPs can start to implement
18:36:59 [jcj_moz]
... This is a set of use cases I've identified [in 334]
18:37:18 [jcj_moz]
... First is bootstrapping two-factor [see issue[
18:38:26 [jcj_moz]
... Also used the terminiology of "cross-platform" rather than portable/not portable
18:38:47 [jcj_moz]
... There are also devices that identify via biometrics, vs. devices that you just happen to have
18:39:19 [jcj_moz]
.... That's the very first scenario. The device needs to be portable, but doesn't need to identify the users.
18:39:48 [jcj_moz]
... One example is Github.com; if you sign up for U2F, the site gives you a password prompt first and then prompts for the second factor
18:40:24 [jcj_moz]
... [2nd case] The device can be built in or portable, but doesn't have to be positively identifiable
18:41:05 [jcj_moz]
... [Passwordless re-auth]: While a user has a password - it's a fall back. The device has to identify the user, but can be portable or not
18:41:24 [jcj_moz]
... [ correction, says it has to be portable]
18:41:39 [jcj_moz]
... You have to be able to carry it around to bootstrap other machines
18:41:57 [jcj_moz]
... Fourth case: User signs in without even a user name. The device can always be used to log in
18:42:29 [jcj_moz]
... This is relevant use case for retail employees - the employee uses a card to punch in, you never see your username
18:42:52 [jcj_moz]
... That case the authenticator is portable and has to be able to produce an assertion without a username, using only an RPID
18:43:02 [jcj_moz]
... so those are the use cases we should consider for the doc
18:43:06 [weiler]
q-
18:43:33 [jcj_moz]
Yaron: From an editorial POV it's confusing, because it has a normative and informative section that move back and forth w/o transition
18:43:47 [jcj_moz]
angelo: This will be rewritten to be added to the oc
18:43:48 [jcj_moz]
doc
18:45:11 [jcj_moz]
angelo: [Discussion re: should the RP always show the same credential UI? Potentials of using local storage to keep track of how the user authenticates]
18:45:15 [weiler]
present+ nadalin, selfissued, angelo, DickHardt, KazuakiArai, YaronSheffer
18:46:13 [jcj_moz]
nadalin: Where do you put the 2FA case?
18:46:30 [jcj_moz]
angelo: That's the first case
18:47:05 [Rolf]
present+
18:47:12 [weiler]
present+ Paulhamus
18:48:08 [jcj_moz]
Yaron: Do you see this as a purely editorial change, even if some of the use cases aren't covered by the current protocol?
18:48:38 [jcj_moz]
angelo: All 5 of these use cases should be part of the spec
18:48:47 [jcj_moz]
Rolf: I'd argue that all 5 of these use cases are already supported
18:49:53 [jcj_moz]
vgb: One of the things I learned from this was that if I knew I was going to call getAssertion w/o a credential ID...
18:50:17 [jcj_moz]
Rolf: This is somehow pre-selecting which authenticators can satisfy...
18:50:39 [jcj_moz]
vgb: Some of these use cases require that selection
18:51:05 [jcj_moz]
... if you want these use cases to work smoothly, you want filter criteria
18:51:30 [jcj_moz]
... I counted 3 criteria: 1) positive ID, 2) portable vs builtin, 3) being callable w/o a credntial ID
18:52:00 [jcj_moz]
jeffh: We should use consistent terminology
18:52:23 [jcj_moz]
vgb: This is angelo saying that 'I as a browser vendor want to support RPs these use cases'
18:52:42 [alexei-goog]
alexei-goog has joined #webauthn
18:55:12 [weiler]
rrsagent, draft minutes
18:55:12 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/02/13-webauthn-minutes.html weiler
18:58:00 [jcj_moz]
[discussion over those 3 criteria above, re: whether they are dependent on each other]
19:08:06 [Aiki]
Aiki has joined #WebAuthn
19:13:53 [weiler]
present+ ChristianBrand, alexei, JakobEhrensvard
19:15:32 [weiler]
present+ JerrodChong
19:29:07 [jcj_moz]
alexei-goog: [draws a description of how the 3 criteria can be used as a filter]
19:33:01 [yaronf_]
yaronf_ has joined #webauthn
19:43:58 [weiler]
scribenick: weiler
19:45:47 [weiler]
Yaron: we're setting up a choice between two difference bad user experiences.
19:46:34 [weiler]
jeffH: hopefully only a minor fraction of RPs care about the authenticator
19:46:45 [weiler]
... vast majority of web won't care
19:47:06 [weiler]
jakob: can we simplify?
19:50:41 [weiler]
...
19:52:14 [weiler]
angelo: do we need a new method to let an RP know if a certain (type of?) credential is available on a device?
19:54:41 [weiler]
scribenick: jcj_moz
20:04:22 [jcj_moz]
vgb: [discussion about interruption during login upon calling a getAssertion]
20:07:09 [jcj_moz]
[[ Breaking for lunch ]]
20:14:40 [apowers]
apowers has joined #webauthn
20:44:02 [rbarnes]
rbarnes has joined #webauthn
21:02:31 [weiler]
weiler has joined #webauthn
21:03:09 [jeffh]
jcj_moz: :)
21:05:14 [jeffh]
dirk: preso cred mgmt vs. webauthn
21:05:31 [weiler]
scribenick: jeffh
21:05:51 [Zakim]
Not knowing who is chairing or who scribed recently, I propose angelo
21:07:04 [angelo]
angelo has joined #webauthn
21:07:21 [angelo]
I will scribe
21:08:20 [angelo]
We are looking at the relationship between CredMan and WebAuthn
21:09:08 [weiler]
scribenick: angelo
21:09:24 [jeffh]
angelo: thx
21:09:43 [angelo]
Dirk is introducing us to the CredMan API
21:10:05 [angelo]
The concern: as a developer, I am looking at the APIs and the names are confusing
21:10:31 [angelo]
Even if a dev doesn't care about the names, the two APIs are also very similiar in terms of intent and type
21:22:50 [angelo]
Dirk has a deck. We will refer to the deck for this part of discussion
21:30:10 [rbarnes]
rbarnes has joined #webauthn
21:32:25 [jeffh]
angelo: sees some RPs using both CredMgmt (CM) and WebAuthn (WA) together to address varioius use cases
21:33:00 [jeffh]
e.g. a webapp may use CM to store the moral equivalent of a cookie upon user authn using WA
21:34:00 [jeffh]
vgb: CM api is intended for webapps that are not super picky wrt the sec level of the user login/consent, and their 1st priority is low-friction UX.
21:34:18 [jeffh]
vgb: posits not prompting user much or at all
21:35:00 [jeffh]
vgb: Webauthn posits that it will prompt the user (eg swipe your finger)
21:36:02 [jeffh]
dirk: CM is structured where the methods are static....
21:36:39 [jeffh]
dirk: but not seeing appetite in room for doing approach B (making webauthn types part of CM class hierarchy)
21:37:01 [jeffh]
angelo: there are analogues in various places between CM and WebAuthn
21:37:08 [jeffh]
dirk: yes
21:39:14 [jeffh]
rolf: CM dictates the protocol for conveying the cred to the RP, where in webauthn we leave it up to the RP to figure out how to do
21:39:31 [weiler]
rrsagent, draft minutes
21:39:31 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/02/13-webauthn-minutes.html weiler
21:41:24 [jeffh]
vgb: when u create a pswd cred the RP doesn't know about it (or have to), but in webauthn we have to register the cred with the RP
21:42:40 [jeffh]
vgb: in webatuhn case calling makeCred() is just the beginning of a fairly complex dance
21:43:19 [jeffh]
jcj_moz: store() is not correct msthod for creating a 'cryptoCredential'
21:48:10 [angelo]
thank you jeff
21:48:39 [jeffh]
jcj_moz: thihnks semantics of webauthn is enough different from CM that it is difficult to figure out how to really merge them...
21:49:03 [jeffh]
dirk: one of the constraints is (obviously) not to re-start from square-one...
21:49:36 [jeffh]
rolf: make CM clear that it is about bearer tokens
21:51:32 [jeffh]
dirk: if we just do approach A which is 'rename' scopedCredential -- what do we call it/them? AuthenticationKeyPair ? something else?
21:52:44 [christiaanbrand]
christiaanbrand has joined #webauthn
21:53:08 [jeffh]
axel_nennker_dt: perhaps using terms like "import" (ie improt challenge) and u get something back...
21:53:51 [jeffh]
dirk: that's a proposal for redoing the methods so they work for both bearer tokens and for our scoped creds....
21:54:39 [jeffh]
dirk: < wondering about what we can simply change in webauthn that clarifies the diffs betwn CM and webauthn>
21:54:56 [jeffh]
angelo: what about device bound?
21:56:07 [jeffh]
dirk: likes idea of creds being assoc w/authnr, and the bearer ones can just float around...
21:56:54 [jeffh]
dirk: (assessing): not seeing appetite for merging into CM, but we need to think about what/how to rename in order to clarify....
21:59:33 [jeffh]
all: going around brainstorming terminology...
22:00:39 [jeffh]
alexei: CM has store() and get() -- how about it changes to "token storage" API and it keeps the store() / get()
22:01:21 [jeffh]
rbarnes: its really about "pswd store" and its special
22:01:35 [jeffh]
vgb: and it's write-only
22:03:25 [jeffh]
jeffh: they shud rename CM to be "Legacy Cred Mgmt" :)
22:04:03 [jeffh]
rbarnes: what's the minimum to actually merge the APIs? (it is approach B in slides)
22:05:00 [jeffh]
rbarns: we could just stick the webauthn methods over the on nav.credentials
22:06:30 [jeffh]
dirk: no appetite for de-merge -- seems we have appetite for simple re-name, need to do soon if so....
22:07:35 [jeffh]
rbarnes: clearly we have storeCred() and exerciseCred() which are similar to store() get() -- if we were to shim into that hierarchy, do we want to steer dvlprs away from using
22:07:49 [jeffh]
...: our creds with get() and store() ....?
22:08:27 [jeffh]
jcj_moz: we did discuss that we have to return errors if one passes the wrong cred type into any of those four methods....
22:11:14 [jeffh]
all: brainstorming....
22:12:04 [rbarnes]
rbarnes has joined #webauthn
22:12:28 [jeffh]
dirk: as we went from option A to C, appetite decreased....
22:14:45 [jeffh]
tonynad: thinks this is coming too late in the game....
22:15:53 [jeffh]
mbjones: unless there's a proposal that is *clearly* better than the status quo, do nothing...
22:21:02 [jeffh]
vgb: notes that if i'm web dvlpr and there's these two apis -- credentials and authentiction -- which do i use?
22:21:56 [jeffh]
angelo: so maybe we rename all four methods and hang them all off of navigator.credentials.
22:22:06 [jeffh]
all: more brainstorming
22:22:25 [jeffh]
?: nav.credentials.store.better() ???
22:23:04 [jeffh]
rolf: what do we do about siteboundCred vs ScopedCred ?
22:23:17 [jeffh]
dirk: both are bound to origins, but are different...
22:24:31 [jeffh]
axel_nenneker_dt: thinks we need to rename the CM methods...
22:26:28 [jeffh]
axel_nennker_dt: does not think they webappsec have appetite to put "bearer" in their names
22:27:07 [jeffh]
alexei: what do we want to propose to mkwst?
22:27:39 [jeffh]
rolf: differentiate "credential" as being "bearertokens"
22:27:51 [jeffh]
all: brainstorming....
22:29:30 [jeffh]
dirk: ok, we can propose that to them, in the meantime what do we rename our methods to be ?
22:32:41 [jeffh]
all: brainstorming, no clear winner. yaronf_ does not like CryptoCredential because 'crypto' is generic
22:40:32 [rbarnes]
rbarnes has joined #webauthn
22:48:59 [rbarnes]
rbarnes has joined #webauthn
22:49:39 [weiler]
weiler has joined #webauthn
22:52:15 [weiler]
rrsagent, draft minutes
22:52:15 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/02/13-webauthn-minutes.html weiler
22:59:44 [weiler]
topic: testing
22:59:58 [weiler]
scribenick: weiler
23:00:06 [weiler]
Adam: not planning to test crypto bits
23:00:31 [weiler]
Mike Jones & Tony: advocating for testing crypto bits
23:01:46 [weiler]
Jakob: we have some HW bits we could use for this.
23:02:59 [weiler]
[Mike Jones volunteers to review]
23:03:28 [weiler]
[-04 will get pushed tomorrow or next day]
23:06:06 [weiler]
rbarnes: should we do the 321 changes before the freeze?
23:07:18 [weiler]
... I'd rather have those simplifications (not having to parse authenticator data) before we commit to a version to test.
23:08:22 [weiler]
[two bigs changes on the horizon: that + the afternoon topic re: credapi naming changes]
23:10:47 [weiler]
s/bigs/big/
23:11:19 [weiler]
[browser vendors agreeing, in principle, to locking donw on wd-04 for testing.]
23:11:26 [weiler]
s/donw/down/
23:11:48 [rbarnes]
maybe wd-04++ -- with the developer-friendliness changes we discussed this morning
23:12:03 [rbarnes]
(or wd-04 itself, if it gets those changes
23:12:04 [rbarnes]
)
23:12:05 [weiler]
angelo: we're about ready to run tests.
23:12:46 [weiler]
adam: any reason to not write tests at the same time as the plan?
23:12:58 [weiler]
A: no.
23:13:35 [weiler]
adam: i'll start writing once wd-04 is out; will take me 2-3 weeks for first cut.
23:14:47 [weiler]
rrsagent, draft minutes
23:14:47 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/02/13-webauthn-minutes.html weiler
23:15:03 [weiler]
topic: et al
23:15:56 [weiler]
tony: future of wg? other topics? (e.g. touchless auth)
23:16:25 [weiler]
... extensions?
23:17:54 [weiler]
selfissued: I want iana registry created before we finish, so spec can point to it.
23:19:05 [weiler]
jcj: issue 290 - i don't like extensions.
23:19:16 [weiler]
angelo: +1
23:19:48 [weiler]
alexei: the only one we want is appID.
23:20:15 [weiler]
tony: emvco?
23:20:45 [weiler]
alexei: use case for appid: existing u2f deployments using chrome u2f api. eventually want to move them to webauthn.
23:21:04 [weiler]
... can't move users w/o asking them to reenroll unless you have appID.
23:22:30 [weiler]
jcj: for me to do this, I have to do the hard parts of the u2f implementation.
23:23:07 [weiler]
rbarnes: cost of not doing appid is a rocky transition path for users.
23:25:47 [weiler]
selfissued: we've heard good biz cases for other extensions. we can't cut extensions completely.
23:26:00 [weiler]
yaron: can we make extensions transparent to browseer?
23:26:17 [weiler]
jc: could, but extensions could be bad for user; browser needs to be able to filter
23:29:12 [weiler]
alexei: google doesn't need private channel between device and RP; we use attestations (for corp side), and that's sufficient.
23:30:23 [weiler]
yaron: sees strange to publish such a complex spec w/ no extensibility.
23:30:48 [weiler]
[discussion of normalcy of having extensions from the start.]
23:31:02 [weiler]
selfissued: different biz/use cases justify it.
23:32:55 [weiler]
[example of kid's fingerprint for unlocking phone for candy crush, then draining retirement accts. neither ios nor android allow diff privileges based on the finger.]
23:32:59 [Zakim]
Zakim has left #webauthn
23:33:23 [Zakim]
Zakim has joined #webauthn
23:33:34 [weiler]
zakim, who's here?
23:33:34 [Zakim]
Present: (no one)
23:33:36 [Zakim]
On IRC I see weiler, rbarnes, apowers, Aiki, Axel_Nennker_DT, RRSAgent, Jove, adrianba, slightlyoff, mkwst, schuki, jcj_moz, wseltzer, trackbot
23:34:39 [weiler]
angelo: let's get core api out (and working) and move ext to another doc.
23:35:53 [weiler]
tony: i'm not sure we want to stick around to maintain ext's. wanted to push out ext's as we know them now and wash our hands of it.
23:36:45 [weiler]
rbarnes: what I'm hearing from browsers is that nothing but appid will be supported for now.
23:37:14 [weiler]
jakob: enterprise/proprietary....
23:37:25 [weiler]
[reference back to transparency...]
23:37:37 [weiler]
rolf: we sgreed before that we'd pass things though by default
23:37:44 [weiler]
everyone: NO.
23:40:38 [weiler]
jeffh: we haven't heard re: "bad" u2f extensions yet...
23:40:55 [weiler]
jakob: what do you do w/ extensions you don't understand?
23:41:06 [weiler]
... what's default behavior?
23:42:47 [weiler]
rrsagent, draft minutes
23:42:47 [RRSAgent]
I have made the request to generate http://www.w3.org/2017/02/13-webauthn-minutes.html weiler
23:44:02 [weiler]
rolf: I'm fine w/ passing through by default and blacklisting as needed.
23:44:52 [weiler]
[passing through unknown ext's]
23:54:37 [weiler]
[discussion of UVM and what happens if it's not supported]