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:56 <angelo> I will scribe
17:16:02 <jcj_moz> scribenick: angelo
17:16:02 <jcj_moz> topic: https://github.com/w3c/webauthn/issues/321
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: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> topic: 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 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> topic: Dirk's presentation of the elationship between CredMan and WebAuthn
21:05:14 <jeffh> dirk: preso cred mgmt vs. webauthn
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:05:31 <weiler> scribenick: jeffh

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: jcj, apowers, jeffh, nadalin, selfissued, angelo, DickHardt, KazuakiArai, YaronSheffer, KimPaulhamus, ChristianBrand, alexei, Dirk, JakobEhrensvard, JerrodChong, vgb, rbarnes 
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]

00:00:57 <weiler> dirk: a well-behavng UA should not pass through extensions it doesn't understand.
00:10:23 <jeffh> jeffh has joined #webauthn
00:10:45 <weiler> rbarnes: I like angelo's idea of stripping the ext's from the main doc.
00:17:27 <weiler> conclusion: no change; keep the ext's in the docs.  need somone to review doc (selfissued. and jeffh.)
00:18:52 <kpaulh> kpaulh has joined #webauthn
00:22:13 <weiler> topic: milestones
00:22:49 <weiler> [some discussion of having fido maintain a list of well-liked extensions]
00:24:57 <weiler> tony: CR not in 1Q.  maybe in 2Q.
00:27:08 <jeffh> all: long discussion (yet again) wrt extensions and whether they are honored/supported/passed-thru by browsers.  result for now is keep extns in spec as-is, ensure the "they are optional" language is there, and also language that the browser can drop unprompted extension emitted by authnr. note: there is non-trivial pushback in room wrt this -- some (RPs, authnr vendors) want browsers to (best case) agree to a list of extensions that are supported.
00:27:31 <jeffh> all: mike jones to review present spec text in this light with JeffH
00:27:38 <weiler> no mtg this week; next call 22 Feb
00:27:43 <weiler> rrsagent, draft minutes
00:27:43 <RRSAgent> I have made the request to generate http://www.w3.org/2017/02/14-webauthn-minutes.html weiler
01:29:18 <rbarnes> rbarnes has joined #webauthn
01:48:50 <weiler> weiler has joined #webauthn
01:52:32 <rbarnes> rbarnes has joined #webauthn
02:12:00 <rbarnes> rbarnes has joined #webauthn
03:29:15 <apowers> apowers has joined #webauthn
05:03:22 <weiler> weiler has joined #webauthn
05:21:59 <Zakim> Zakim has left #webauthn
05:25:16 <apowers> apowers has joined #webauthn