06:20:30 RRSAgent has joined #webauthn 06:20:30 logging to http://www.w3.org/2016/05/13-webauthn-irc 06:36:51 agenda: https://github.com/w3c/webauthn/blob/master/meetings/2016-05-13-Berlin-f2f.md 06:37:06 Meeting: Web Authentication WG F2F 07:00:16 JeffH has joined #webauthn 07:01:33 present+ 07:02:13 jcj_moz has joined #webauthn 07:02:43 gmandyam has joined #webauthn 07:04:33 apowers has joined #webauthn 07:04:35 juanlang has joined #webauthn 07:04:37 alexei-goog has joined #webauthn 07:04:48 dirkbalfanz has joined #webauthn 07:04:53 present+ Mike_Jones 07:05:01 present+ JuanLang 07:05:04 AxelNennker has joined #webauthn 07:05:04 present+ 07:05:09 present+ Axel 07:05:14 Rolf has joined #webauthn 07:05:14 present+ 07:05:16 Hubert-PayPal has joined #webauthn 07:05:18 present+ gmandyam 07:05:40 present+ 07:05:48 present+ 07:06:17 SamSrinivas has joined #webauthn 07:06:30 present+ 07:06:38 present+ 07:07:09 tony: Welcome 07:07:16 selfissued has joined #webauthn 07:07:29 ... looking at timeline, we have a year charter 07:07:43 Mike Jones 07:07:46 ... want to get issues closed by the end of the year 07:07:58 ... by TPAC, in September, we'd like to have our work finalized 07:08:13 https://www.w3.org/2016/09/TPAC/ 07:08:48 tony: we will have a WG meeting at TPAC 07:08:54 ... we'll also meet with WebAppSec 07:09:11 rbarnes has joined #webauthn 07:09:19 -> https://www.w3.org/2016/09/TPAC/schedule.html TPAC schedule 07:09:36 [[ Tuesday 20 September is Webauthn meeting]] 07:09:52 tony: we want to walk out with two things, FPWDs and a timeline for next steps 07:09:53 vgb has joined #webauthn 07:10:30 rbarnes: let's talk about status, how we got to now 07:11:19 Topic: Status 07:12:01 vgb: I'm going to review goals and status 07:12:07 ... feel free to interrupt 07:12:19 ... Diagram: user, client, relying party 07:12:56 ... at a high level, RP wants to ask the client, "does human user X want to do action Y?" 07:13:10 ... client should be able to ask permission, user give permission 07:13:39 ... RP gets crypto assurance that an actual human said yes; and an assertion of level of trust on that assurance 07:14:08 ... user authenticator 07:14:29 ... a black box the user interacts with, protected 07:15:26 ... user authenticators today include embedded authenticators 07:15:42 ... built into the device, e.g. fingerprint sensor, camera, code entry 07:16:09 ... there, user interacts directly with the client; maybe the device has an enclave 07:16:23 ... confidence in assertion depends on your confidence on level of protection 07:16:46 ... second type, external authenticator; hardware separate from the device 07:16:57 ... interact with client in different ways 07:17:05 ... they roam, to multiple different clients 07:18:00 ... hybrid, using the phone as authenticator for the laptop 07:18:14 ... Goals: provide end-to-end secure user authenticaiton for the web 07:18:38 ... enable RPs to trust that a human did something 07:19:08 ... reason to adopt this API is to interact with the existing devices out there as authenticators 07:19:20 ... encourage rapid adoption 07:20:00 ... At least 3 of us have built JS APIs on top of existing authenticators 07:20:47 ... we're not starting from a blank page, but learn from previous efforts 07:21:29 @@2: This doesn't preclude native clients? 07:21:46 vgb: no, it doesn't. We're talking at W3C about the Web platform 07:22:27 ... underlying OS has its own platform 07:22:56 ... if we capture the right level of abstraction, it's likely that native APIs will look similar 07:23:07 ... but that's not our charter 07:23:27 gmandyam: native apps can use webview 07:23:52 vgb: web platform isn't just web browsers; it's browser engines, libraries you can build into native apps 07:24:34 SamSrinivas: If we get work here done right, it's a strong incentive for others to use the APIs 07:24:51 ... so the same keys work across platforms 07:26:36 vgb: authentication is one step; it's important then to stitch together with other pieces 07:26:57 ... We want to bootstrap with existing authenticators, and also enable new capabilities 07:27:43 rbarnes: goal is to create a level of abstraction that's compatible with some of the past and what we want to enable in the future 07:27:49 ... incorporate and build on 07:28:03 vgb: we don't have to take along the authenticators that aren't good enough 07:28:26 ... but start with some 07:28:41 ... Where we started: FIDO specs submitted to W3C 07:29:07 ... FIDO realised, we should come to W3C for Web platform standards 07:29:39 ... contributed 3 specs, Web API, Signature format (proof of consent), Attestation (crypto statement saying how much to trust the authenticator) 07:30:21 ... FIDO continues work, developing the authenticators 07:30:39 ... protocols for talking to authenticators, hardware certification 07:31:19 vgb: very roughly, Webauthn is RP-Client interaction, while client-user communications are specified in FIDO 07:31:42 ... this group started in February 07:31:58 ... We got feedback that 3 docs together weren't clear 07:32:12 ... so first we (Dirk) combined the documents 07:32:18 ... a single document, with three logical parts 07:32:29 ... added a glossary 07:32:44 -> https://w3c.github.io/webauthn/ Webauthn editor's draft 07:33:01 vgb: renamed things, JC did lots of work there 07:33:10 ... bikeshed, fix WebIDL 07:33:29 ... ongoing: discussion with W3C TAG 07:33:45 ... technical architecture group, reviewing the design of the spec 07:33:56 ... working with them on RP separation issue 07:34:18 ... active dialog within WG on right level of abstraction, explanation 07:34:33 vgb: Three parts of the spec: API, Authenticator model, Extensions 07:35:40 ... API: for the developer; we're paying lots of attention to UX, security for the user, privacy; flexibility for extension 07:36:23 ... Authenticator: developers can skim it, coding the server back-end for validation 07:37:07 ... goal is to provide logical model, clarify how it's exposed to the platform; interop 07:37:18 @@3: No notion of FIDO server? 07:37:40 vgb: goal is to capture in the authenticator model all the things a server would need to know 07:37:47 ... W3C doesn't define business logic 07:38:08 rbarnes: goals isn't to specify what server should do, but what it should expect from the client (authenticator via the browser) 07:38:36 vgb: something a web developer can read and understand what's going on, interoperate 07:39:10 @@3: this comes from FIDO 2.0, which has the notion of server 07:39:17 tony: server doesn't provide attestation 07:39:34 ... other parts are still within FIDO Alliance 07:39:46 vgb: FIDO metadata service, a service that provides some side information 07:40:31 ... some info you can access in many different ways; we're not going to mandate where you get it 07:40:39 ... give you something as an identifier 07:41:08 rbarnes: as vgb said, this API is designed to have compatibility, with existing and new authenticators that fit the model 07:41:14 vgb: third part, Extensions 07:41:39 ... Extensions: advanced stuff, without advance determination what things might be there 07:42:05 ... we tried it out by trying to describe some extensios in the spec 07:42:27 ... in the future, anyone should e able to publish an extension, anywhere, and have it be interoperable 07:42:45 vgb: All our work is documented in github 07:42:56 ... with all the logs of commits and issues addressed 07:43:10 ... when we started, we gave issues milestones, FPWD or later 07:43:20 ... we have no remaining FPWD milestone issues 07:43:33 ... it's my understanding the group believes we're now at a point to invite wide review 07:43:42 ... we're confident in the direction fo the spec, ready for more eyes 07:43:55 ... remaining issues, but not fundamental changes of direction 07:44:10 ... e.g. top-level window or navigator, names 07:44:34 ... credentialType vs version 07:44:41 ... optional parameters -> dictionary? 07:44:56 ... but these issues don't change the basic abstractions 07:45:17 ... so implementers should review in detail to see if it's internally consistent, implementable 07:45:40 ... goal to do another few iterations 07:45:51 ... Next steps: get FPWD announced soon 07:46:08 ... expect at least one more rev where the API changes 07:46:38 ... goal to get to implementation quickly, talk to implementers about what obstacles remain 07:46:48 ... conclude by end of year 07:46:58 tony: I'd hope we can use TPAC to review implementations 07:47:18 vgb: we'd like to get a complete draft before TPAC, so we can discuss it there 07:48:23 @@ 07:48:27 vgb: lots of these authenticators are multi-factor 07:48:45 ... factors in the realm of the authenticator 07:49:00 ... these specs cover human consent, more than continuous authentication 07:49:13 ... strong privacy concerns about something that doesn't prompt the user 07:49:32 sridhar_muppidi: dialog among parties; not just giving permission 07:49:42 vgb: lots of business logic on the server side 07:50:06 ... e.g. at a bank, user giving consent is one signal among many 07:50:32 ... the goal here isn't to taxonomy all the things RPs could do, but to provide an ingredient 07:50:45 ... and to specify it completely and interoperably 07:50:56 adamkcooper has joined #webauthn 07:51:20 rbarnes: compare WebRTC, there are many components it takes to create a phone; goal is to create primitives 07:51:39 sridhar: simple scenario, authenticate, then want to send a push notification 07:51:55 ... how do we map the pieces, W3C, FIDO, OpenID Connect... 07:52:26 JeffH: in terms of how this composes with federated identity, all thosse specs say authentication fo the user to IDP is out of scope, this fits there 07:52:35 sridhar: you may want an additional level of challenge 07:53:05 ... e.g., embedding a policy for authentication 07:53:14 ... can we walk through a simple scenario? 07:53:53 selfissued: authentication context class references, adopted by OIDC 07:54:06 ... a place in the authentication request to say "please use this business policy" 07:54:24 ... authzn server (IDP) replies back with a token saying I did or did not use that policy 07:54:49 ... glue, with respect to FIDO, define one or two policies that use of authenticators with various characteristics would satisfy 07:55:35 vgb: we've tried to walk through a very simple scenario end-to-end and see how it would work 07:55:55 ... it would be valuable if people with more complex scenarios would work through them too 07:56:08 sridhar: I want to get rid of complex custom scenarios 07:56:18 ... where do I use webauthn? 07:56:45 Kamal: GSMA working on mobile authenticators, work with FIDO 07:57:01 vgb: if those scenarios reveal problems with this spec, bring them back 07:57:26 ... that's probably from review at the next level of detail 07:57:37 ... keep in mind scope of this group, not trying to specify federation, frameworks 07:57:51 rbarnes: we do have an issue to add an explainer doc 07:58:07 ... that could help 07:58:53 vgb: We're looking for volunteers 07:59:11 sridhar: I'll help 08:00:31 Kamal: can anyone use APIs, or is certification required? 08:00:43 wseltzer: anyone who can interoperate can use the API 08:00:49 vgb: we've written a JS shim 08:01:03 rbarnes: we'll talk about schedule and likely evolution in a bit 08:01:24 ... if you're writing to the API, think about how much churn will happen right now, and we'll send signals when things settle down 08:01:30 ... Moz is also implementing 08:01:47 Topic: FPWD 08:02:18 tony: we'd like to move to a consensus call to move this to FPWD 08:02:24 ... does anyone have any issues? 08:02:30 Soohyung has joined #webauthn 08:02:48 selfissued: I hear a lot of demand for a public draft 08:03:04 PROPOSED: Move webauthn to FPWD 08:03:09 selfissued: so moved 08:03:12 JeffH: second 08:03:42 +1 08:04:31 Hubert-PayPal has joined #webauthn 08:05:01 wseltzer: Process-wise, we CfC here, then send to ML 08:06:37 SamSrinivas: I think the attestation needs to be simplified dramatically. Does FPWD preclude that change? 08:06:46 wseltzer: no, we can still make techncal changes 08:07:02 gmandyam: patent exclusions here too 08:07:08 wseltzer: Patent policy @@ 08:07:26 SamSrinivas: we shouldn't take momentum from FPWD to keep things complex 08:07:32 tony: the group will decide that. 08:07:59 RESOLVED: Move webauthn to FPWD, put CfC to list 08:08:45 tony: we'll send to list with one week from today 08:08:58 gmandyam: even fi there are objections, you don't need to resolve them, just document them 08:09:18 tony: so a week from now, we should be able to put out FPWD 08:09:30 rrsagent, draft minutes 08:09:30 I have made the request to generate http://www.w3.org/2016/05/13-webauthn-minutes.html wseltzer 08:10:09 rrsagent, make logs public 08:10:12 rrsagent, draft minutes 08:10:12 I have made the request to generate http://www.w3.org/2016/05/13-webauthn-minutes.html wseltzer 08:10:38 Meeting: Web Authentication WG 08:10:46 Chairs: Tony Nadalin, Richard Barnes 08:11:53 rrsagent, draft minutes 08:11:53 I have made the request to generate http://www.w3.org/2016/05/13-webauthn-minutes.html wseltzer 08:15:21 [15 min break] 08:38:58 jcj_moz has joined #webauthn 08:39:32 [return] 08:39:35 alexei-goog has joined #webauthn 08:39:40 Topic: Token binding 08:40:31 Dirk Balfanz holding forth... 08:41:28 SamSrinivas has joined #webauthn 08:42:26 vgb has joined #webauthn 08:42:29 sangrae_ has joined #webauthn 08:44:10 https://tools.ietf.org/html/draft-ietf-tokbind-protocol 08:44:40 https://tools.ietf.org/html/draft-ietf-tokbind-https 08:51:33 giri: this? https://tools.ietf.org/html/draft-thomson-http2-client-certs-00 08:51:41 i don't think that's addressed at the same thing 08:51:42 Giri: asks about whether some present work ion client certs in http is relevant here 08:52:19 dirk: will have to familiarize with it and think about it.... 08:52:47 dirk: token binding specs superseed the prior channel id internet-drafts 08:53:32 gmandyam has joined #webauthn 08:54:07 A comparison to http://www.ietf.org/id/draft-thomson-http2-client-certs-02.txt would be useful. Seems to address the concern about client cert being sent via TLS. 09:00:43 i|going to review goals and status 09:01:30 i|going to review goals and status|-> https://www.w3.org/Webauthn/slides/WebAuthnAPIStatus-vgb.pdf Vijay's slides 09:04:38 hubert: asks how this is different from tls cert pinning 09:05:13 tony: looking for volunteers to review draft, write explainer text 09:05:42 Alexei, Adam, Mike, Jeff, Giri volunteer to review 09:06:32 adamkcooper has joined #webauthn 09:07:45 jdirk/jeffh: tokbinding is making replay of protocol objects detectable, where channel binding is about ensuring client can detect MITM when tls channel established 09:08:29 wseltzer: additional context wrt W3C process, what FPWD means, pub of subsequent WDs... 09:09:04 FPWD triggers "wide review", CR is next major milestone, attaining it reqs "wide review" 09:09:29 ...eg review by those listed in webauthn charter have indeed reviewed... 09:10:05 ...we are obliged to tug sleeves... 09:10:25 ...we will send explicit reqs to those groups soliciting review... 09:10:36 jin has joined #webauthn 09:11:56 FPWD gets us pub'd in w3.org/TR/webauthn/ 09:12:51 ...we can refresh w3.org/TR/webauthn/ as we go along...we are working towards CR...implementors should be warned that this is unstable 09:13:03 ...CR implies API stability 09:13:40 ...thus we can snapshot editors' drafts to /TR/webauthn as appropriate 09:14:08 ...the WG needs to decide criteria for such snapshots 09:14:48 ...eg can establish milestones for such snapshots and assign issues to milestones and do snapshot when the issues have been closed 09:15:01 rbarnes: any objs to this plan? 09:15:11 ... thus we'll do that 09:15:40 TonyN: so.... with that we'll have Adam Powers discuss his work on tests 09:16:01 RESOLVED: We will publish WD from "milestone" labels when all the issues for a milestone have been closed 09:16:29 AdamP: need to discuss what tests should do and what to test 09:16:42 ....should we be testing that sigs are verifiable ? 09:17:12 rbarnes: we should test what's defined in the spec, thus testing sigs is in scope 09:17:47 mikej: we need to test both good and invalid things.... 09:18:07 giri: how's webcrypto tests working? 09:18:24 rbarnes: they are working on fleshing out their test suite 09:19:27 wseltzer: they are yes dvlp'g more full-fledged tests .... overall goal of a test platform is that the w3c can determine whether we have useful test coverage 09:19:55 ....if we write good tests, it helps ensure consistency of the web platform 09:20:31 rbarnes: [something wrt webcrypto not being a good example at this time..] 09:21:34 Zakim has left #webauthn 09:21:37 rbarnes/adamp: ...maybe using webcrypto for our tests not good idea at this time.... 09:22:03 tonyn: what is w3c IP rules wrt contributed test tools ? 09:23:41 rbarnes: we do define an authnr model, so can test "underneath" the browser that verifies what is sent in to authnr is correct.... 09:25:03 ....can probably have two classes of tests what goes into authnr, and one is input from and output to the Webauthn RP's webapp client 09:26:13 rolf: webapi passes things thru from WRP code to authnr, and authnr output passed back thru webapi to WRP code 09:26:43 .. so some things, eg authnr itself, are outside scope of W3C 09:27:58 mikej: is impt to have test tools for the clients of webauthn api -- eg if we can emit bad sigs from webauthn api, we can test client behavior --- so for health of overall ecosystem we need such tests.... 09:29:20 vijay: i want to sep two things, (a) it is in scope to claim compliance with the spec that emitted sigs are correct, (b) ..?.. -- wrt mke's suggestion that is testing my test suite 09:29:29 s/useful test coverage/interoperable implementations of the spec's features/ 09:30:21 sam: we test against a known-good authnr.....a way to shake out all needed test cases, verify that all the data passed to API gens expected results 09:31:04 ...eg in chrome we support USB authnrs, possible to have known-good authnr, and all probs server has are server problems 09:31:44 mikej: w/o getting in to details i think it is impt to test both success paths and error-handling paths 09:32:53 rolf: we would not expct JS to verify sig -- it gets sent to svr to validate.... 09:33:18 rbarnes: but it is not in our scope to dictate that the JS sends to a server vs do things on its own.... 09:34:31 ....all we need to test is that the api is faithfully passing thru objects -- will be impt to use a authnr and verify that the results are as expected 09:35:16 ...ie anything the user agent does is in-scope, and part of what the authnr does is a;lso in-scope because it is spec'd in the spec 09:35:56 SamSrinivas has joined #WebAuthn 09:36:12 mikej: have a bunch of experience with eg saml federations, a bunch don't check sigs on assns..... 09:36:38 vijay: we are not spec'g the RP behavior so why are such tests in scope 09:37:41 mikej: it is impt that servers-side get tested at an ecosystem level 09:37:57 rbarnes: not sure how a generic test can be made for RPs 09:38:53 mikej: a way to do in practice is that you have a webauthn api impl that has a synthetic authnr that generates test sigs that have known properties and test whether they are properly detected by the RP impl.... 09:39:20 rbarnes: hm, things like that might be approp to include in the test suite.... 09:39:47 ...and spec out the sort of things that mike is talking about 09:40:47 adamp/mikej: framework for testing RPs is diff than one to test webauthn api, tho it is impt from ecosystem perspec 09:41:03 rolf: here in w3c we need to test the browser webauthn api impl 09:41:52 giri: fido is going to do cerification, might not address all of mikes goals but is step in that direction..... 09:42:14 adamp: tho we fido could possibly make some things broadly available 09:44:17 vijay: as mater of practicality, if we have some code that verifies assn emitted u have some useful assurance, it seems like having tests of your webauthn that depends on webcrypto is ok is reasonable because you'll run webcrypto tests too at some point 09:45:05 ...and there's way to automate things --- so we can separate some of these test suite problems 09:45:18 adamp: sure, works for me 09:46:03 rbarnes: volenteers JC to help adamp with some of this 09:46:53 SamSrinivas has joined #webauthn 09:48:01 vijay: we have tests in w3c context that tests webauthn api, and then over in [fido] we will have approp tests for other portions of ecosystem.... 09:48:31 tonyn: so at next F2F in sep, we'll be calling for impls and they'll need test suite 09:48:53 rbarnes: so btwn CR and PR is the window where tests will be used 09:49:24 adamp: ok so will start test plan 09:51:06 https://hiptest.net/ 09:51:40 ....will do it at hiptest.net 09:52:16 rrsagent, draft minutes 09:52:16 I have made the request to generate http://www.w3.org/2016/05/13-webauthn-minutes.html wseltzer 09:52:51 apowers: also, thanks a lot for working on this. as WebCrypto shows, it can be really hard to get people to work on tests 09:53:03 tonyn: we have further disc topics for the day, eg wrt Attestion, Srido's use cases 09:53:17 i/Token binding/scribenick: JeffH 09:53:51 Topic: Scenarios 09:54:49 sridhar: scenario 1, login, then push notification to the device 09:54:58 srido: wrt use cases, start small..... user goes to RP, get challenged for uname&pswd, employs a device that is previously registered (of variosu possible modalities) 09:55:27 ...how does this spec hope to address that... have a diagram that helps people understand.... 09:58:03 Present: Juan Lang, Mike Jones, Axel Nennker, Alexei Czeskis, Sam Srinivas, Vijay Bharadwaj, 09:58:22 Present: Juan Lang, Mike Jones, Axel Nennker, Alexei Czeskis, Sam Srinivas, Vijay Bharadwaj, SooHyung Kim, Sangrae Cho, Seung-Hun Jin, Sridhar Muppidi, Kamal Shah, Ketan Mehta, George Tang, Axel Nennker, Rolf Lindemann, Adam Powers, John Fontana, Aiki Matsushita, Atsuhiro Tsuchiya, Koichi Moriyama, Hubert Le Van Gong, Jeff Hodges, Giridhar Mandyam, J.C. Jones, Dirk Balfanz, Tony Nadalin, Richard Barnes, Wendy Seltzer; by phone: Adam Cooper 09:58:30 rrsagent, draft minutes 09:58:30 I have made the request to generate http://www.w3.org/2016/05/13-webauthn-minutes.html wseltzer 09:59:12 Note that FIDO produced an informative architecture specification 2 years ago: see https://fidoalliance.org/specs/fido-uaf-v1.0-ps-20141208/fido-uaf-overview-v1.0-ps-20141208.html. 10:00:05 i|tony: Welcome|scribenick: wseltzer 10:00:09 This could be an informative reference in the WebAuthn spec, as opposed to putting a whole "explainer" section into the specification. 10:03:43 rrsagent, draft minutes 10:03:43 I have made the request to generate http://www.w3.org/2016/05/13-webauthn-minutes.html wseltzer 10:04:03 I have to leave. Sorry. One of the drawbacks when meetings are in the town one works. See you on the phone and Lisbon 10:05:56 srido: authn, validation, followed by continuous monitoring and re-authn as necessary 10:06:35 alexei: this is interesting and perhaps you should raise these items in the fido alliance in their deployment at scale WG.... 10:07:40 tonyn: when we did xmldsig, we needed some of this explanatory info, a question is where is recorded, am fine with an explainer doc.... 10:08:28 sirdo: the above was the 1st scenario 10:09:01 SamSrinivas has joined #webauthn 10:09:24 srido: 2nd scenario: user going to RP, RP has risk engine, and based that he suddenly appears in .de and we don't trust that as much, i may want to demaind two-factor authn at this time to get started.... 10:10:07 ....once authn'd things proceed.....but then want to do a high-value transaction.....so RP wishes to do 'step-up' challenge-response 10:11:37 vijay: yes, we've talked about this in webauthn context, i'm RP, ask for consent, get back something that I don't think passes muster, then RP can make step up request, eg a non-webauthn challenge-repsonse, and this is natural in webauthn flows 10:12:00 ...so it is an impt and possible extension 10:12:34 tonyn: it will be the server that makes the decision whether the presented authn assn is sufficient 10:12:48 ....RP may accept it or request further authn 10:13:48 q+ 10:13:55 Zakim has joined #webauthn 10:16:05 srido: a bulid on this acenario is: rp says i need voice-based step-up, but am in noisy environm, so can switch to face-based 10:18:51 ....last scenario: have custs that belive some of the validation needs to be on sever-side, eg w/biometrics, FIDO isn't sufficient/approp, how do we do this in combo with webauthn 10:19:14 giri: well there is w3c device and sensors WG maybe that can provide means ? 10:20:35 srido: there are custs that are doing both client-side and server-side biometrics and how do we take advantage/combine them....? 10:20:37 dirkbalfanz has joined #webauthn 10:21:42 Topic: Issues 10:22:27 -> https://github.com/w3c/webauthn/issues Open issues in github 10:22:56 vgb: Major class of issues: errors are underspecified 10:23:07 ... also lots of editorial things that don't require much discussion 10:23:16 ... start with things marked discuss? 10:23:30 https://github.com/w3c/webauthn/issues?q=is%3Aissue+is%3Aopen+label%3Astat%3ADiscuss 10:24:23 tonyn [ ...tries to moderate unruly hungry hordes.... ] 10:26:00 tonyn: ok, we are on pre-lunch break now.... 10:28:18 rbarnes has joined #webauthn 10:35:22 [pre-lunch break] 10:35:25 rrsagent, make minutes 10:35:25 I have made the request to generate http://www.w3.org/2016/05/13-webauthn-minutes.html wseltzer 11:36:28 JuanLang has joined #webauthn 11:43:32 alexei-goog has joined #webauthn 11:45:19 rbarnes has joined #webauthn 11:46:38 dirkbalfanz has joined #webauthn 11:47:05 [meeting resumes] 11:47:25 Vijay is reviewing issue labels and deleting unnecessary labels 11:47:51 https://github.com/w3c/webauthn/issues 11:48:08 https://github.com/w3c/webauthn/issues?q=is%3Aissue+is%3Aopen+sort%3Acreated-asc 11:48:22 Topic: Issue review 11:48:35 jcj_moz has joined #webauthn 11:48:38 vgb: as we discussed earlier, we'll have at least one more draft with technical changes 11:48:43 ... before we hit CR 11:49:01 ... Candidate Rec is when we say we believe all technical issues are settled 11:49:31 ... We're aiming for one more draft to iron out issues 11:49:50 ... I'm going to close the FPWD milestone 11:49:54 [applause] 11:50:19 vgb: things that go into WD-01 are technical issues, or editorial issues so heinous we don't want to let the spec go with them 11:50:32 ... other things are CR 11:51:03 ... the two labels that are most useful: OKttoDo -- the group has decided it's ready, whoever wants to do it 11:51:21 ... Discuss, to flag for discussion before coding a pull request 11:51:31 ... 47 issues to go 11:51:48 https://github.com/w3c/webauthn/issues/6 11:53:16 vgb: I think we'd do this one differently today 11:53:30 ... we don't have a way for authenticator to hint to the platform how it's accessible 11:53:53 ... today, I think we'd call this request for extension 11:55:25 dirkbalfanz: you want to give a hint to the UA how to communicate with the authenticator 11:55:59 vgb: do we agree this should be in the next WD? 11:56:02 alexei-goog: yes 11:56:40 ... we should explain how to do it either in extension or parameter 11:57:06 https://github.com/w3c/webauthn/issues/8 11:57:44 vgb: let's try to close out RP-ID 11:58:13 https://github.com/w3c/webauthn/issues/11 11:58:24 editorial 11:58:36 https://github.com/w3c/webauthn/issues/12 11:58:49 editorial 11:58:56 https://github.com/w3c/webauthn/issues/13 11:58:59 editorial 11:59:14 https://github.com/w3c/webauthn/issues/14 11:59:54 alexei-goog: I think credential ID covers this 12:02:14 https://github.com/w3c/webauthn/issues/17 12:02:21 vgb: a request for delete 12:02:39 ... if we were to add a delete method, that would be a technical change 12:03:29 ... I don't know how to fix this ... authenticator may not be listening 12:03:51 ... also, many authenticators have no local state (U2F) 12:04:03 ... delete can do nothing 12:04:41 alexei-goog: think of bluetooth pairing; if you want to unpair phone from laptop, you do it from the phone 12:04:56 ... if the authenticator knows the credential, should be able to delete 12:05:03 ... but not a matter for the RP 12:05:54 tony: there should be some explanatory text 12:06:12 gmandyam: what is the harm from leaving the credential ID when it's been deleted from the server 12:06:18 ... I can't think of any harm 12:06:38 ... so if deleting isn't enforceable, and there's no harm to leaving, let's close 12:06:59 @@4: can you DOS the authenticator by storing too many keys? 12:07:14 vgb: every make credential requires user gesture 12:07:21