16:52:10 <RRSAgent> RRSAgent has joined #webauthn
16:52:10 <RRSAgent> logging to http://www.w3.org/2016/05/25-webauthn-irc
16:52:19 <wseltzer> Meeting: Web Authentication WG
16:52:25 <wseltzer> Chair: Tony Nadalin
16:52:30 <wseltzer> regrets+ rbarnes
16:53:03 <wseltzer> Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016May/0247.html
17:01:51 <wseltzer> present+ wseltzer
17:02:17 <wseltzer> present+ tonynad
17:02:22 <SamSrinivas> SamSrinivas has joined #webauthn
17:02:24 <weiler> weiler has joined #webauthn
17:02:29 <SamSrinivas> present+
17:02:53 <wseltzer> present+ gmandyam
17:02:53 <weiler> present+
17:03:53 <wseltzer> zakim, who is here?
17:03:53 <Zakim> Present: wseltzer, tonynad, SamSrinivas, gmandyam, weiler
17:03:55 <Zakim> On IRC I see weiler, SamSrinivas, RRSAgent, Zakim, slightlyoff, mkwst, wseltzer, adrianba
17:04:27 <wseltzer> present+ alexei
17:06:29 <wseltzer> present+ JeffH
17:07:17 <vgb> vgb has joined #webauthn
17:07:29 <vgb> hi, sorry i'm late
17:07:47 <wseltzer> present+ vgb
17:07:51 <vgb> present+
17:08:49 <weiler> hakim, who is here?
17:08:55 <selfissued> selfissued has joined #webauthn
17:08:58 <Rolf> Rolf has joined #webauthn
17:09:05 <weiler> zakim, who is here?
17:09:05 <Zakim> Present: wseltzer, tonynad, SamSrinivas, gmandyam, weiler, alexei, JeffH, vgb
17:09:07 <Zakim> On IRC I see Rolf, selfissued, vgb, weiler, SamSrinivas, RRSAgent, Zakim, slightlyoff, mkwst, wseltzer, adrianba
17:09:12 <selfissued> Mike Jones here, but still downloading WebEx
17:09:25 <weiler> 8 present.  8 total on the call.
17:09:46 <dirkbalfanz> dirkbalfanz has joined #webauthn
17:09:59 <wseltzer> present+ Rolf
17:10:08 <dirkbalfanz> present+
17:10:28 <selfissued> present+
17:11:18 <wseltzer> tony: On today's agenda, status of blog post, publication, and open issues for the next draft
17:11:29 <wseltzer> ... discussion about extensions
17:11:37 <wseltzer> ... some people have made review passes through the document
17:12:09 <wseltzer> ... and registration for TPAC F2F in Lisbon
17:12:14 <wseltzer> ... AOB?
17:12:21 <wseltzer> Topic: FPWD
17:12:35 <wseltzer> tony: we called consensus for FPWD on Monday
17:12:45 <wseltzer> ... hearing no objections
17:12:55 <vgb> q+ for update on fpwd editorial prep
17:12:59 <wseltzer> ... we also gave Mike Jones action to write blog post
17:13:24 <wseltzer> ack vgb
17:13:24 <Zakim> vgb, you wanted to discuss update on fpwd editorial prep
17:13:52 <gmandyam> gmandyam has joined #webauthn
17:13:54 <selfissued> I've circulated a blog post to the chairs and W3C reps
17:14:07 <selfissued> Received two pieces of feedback that I'll incorporate
17:14:24 <selfissued> Wendy asked whether the blog post wants to talk about future timeline
17:14:31 <wseltzer> SamSrinivas: I sent some comments
17:14:34 <selfissued> Once I'm on WebEx (still downloading) let's talk about that
17:14:50 <selfissued> Yes - Sam - I agree with your comments and will incorporate
17:15:34 <selfissued> (WebEx download at 53% :-( )
17:16:13 <wseltzer> vgb: the link-checker reports 404, on FIPS reference, there's a PDF there though
17:16:19 <wseltzer> q+
17:16:31 <wseltzer> vgb: and a second 404 at the /TR link, since that doesn't yet exist
17:16:55 <wseltzer> ... also bikeshed boilerplate lacked FPWD status. I'm happy to add it to the HTML manually
17:17:04 <wseltzer> ... since we'll never have another FPWD
17:18:04 <wseltzer> wseltzer: we can deal with those 2 404s; the /TR is expected
17:18:17 <wseltzer> JeffH: we need to fix the shortname in the metadata
17:18:38 <wseltzer> q-
17:18:53 <wseltzer> vgb: I can send a tarball to weiler
17:19:04 <wseltzer> ... I'll check the shortname into the repo
17:19:19 <wseltzer> ... in bikeshed, you can manually override on the command line
17:19:44 <wseltzer> q?
17:20:01 <wseltzer> weiler: We'll publish next Tuesday, May 31
17:20:12 <wseltzer> ... sounds as though we're on track
17:20:39 <wseltzer> ... webmaster publishes Tuesdays and Thursdays
17:20:47 <wseltzer> tony: blog post at the same time?
17:21:17 <wseltzer> weiler: we will make that happen at the same time
17:22:20 <wseltzer> selfissued: I will send to the list; I was going to incorporate SamSrinivas's change (not "passwordless" but reducing reliance on password)
17:22:52 <wseltzer> ... Wendy had suggested a forward looking statement about our timeline for CR
17:23:11 <wseltzer> ... but I was concerned about guessing about dates
17:23:31 <wseltzer> tony: it helps people understand we're on a rapid pace, when they need resources for implementation and review
17:23:40 <wseltzer> SamSrinivas: I agree, add some urgency to the review
17:23:58 <wseltzer> selfissued: wanted to run by WG; is September the right date?
17:24:14 <wseltzer> tony: @@
17:24:36 <wseltzer> vgb: We agreed in Berlin to aim for CfC on CR at TPAC
17:24:43 <wseltzer> ... encourage people to look at things now
17:24:48 <wseltzer> tony: any concerns?
17:25:05 <wseltzer> selfissued: I'll make those changes and send to WG list
17:25:27 <wseltzer> tony: Comments to Mike by Friday, please, so we can post Tuesday after long weekend
17:25:55 <wseltzer> ... thanks, Mike
17:26:01 <JeffH> JeffH has joined #webauthn
17:26:12 <JeffH> present+
17:26:21 <wseltzer> ... vgb will send a tarball to SamW, who will publish
17:26:58 <wseltzer> ... and Mike will send blog post to SamW
17:27:06 <wseltzer> Topic: Beyond FPWD
17:27:24 <wseltzer> tony: extensions, vgb and JeffH had some comments
17:28:16 <wseltzer> vgb: summarizing Berlin discussion: informal conversation saying spec should say "all extensions are optional" and point to registry for extensions
17:28:27 <wseltzer> ... e.g., IANA registry with open process for inclusion of extensions
17:28:46 <wseltzer> ... and also remove the extensions we have in the predefined extension section, move them to registry
17:28:49 <wseltzer> q+ JeffH
17:29:14 <wseltzer> vgb: JeffH and I have been discussing; two pieces of text in the spec contradict one another
17:29:29 <wseltzer> ... one part saying extension can be requested by the caller, authenticator constructs
17:29:49 <wseltzer> ... another part says if you ahve extension you dont' recognize, client should forward as-is
17:29:59 <wseltzer> ... but it might require processing by client
17:30:14 <wseltzer> ... so either we take out part saying clients will forward unrecognized
17:30:29 <wseltzer> ... or make no extensions require client-side processing
17:30:45 <wseltzer> JeffH: some basic misunderstanding of registries
17:30:56 <wseltzer> ... you define extension in a spec, not in registry
17:31:03 <wseltzer> ... and then register a pointer in the registry
17:31:09 <wseltzer> ... to that spec
17:31:10 <gmandyam> q+
17:31:15 <wseltzer> ack Jef
17:31:30 <wseltzer> ... so we can register things in an IANA registry while they sit in the WebAuthn spec
17:32:03 <gmandyam> Options exist within the W3C to create registries as well:  see https://dvcs.w3.org/hg/html-media/raw-file/306bb395f94e/media-source/byte-stream-format-registry.html
17:32:04 <wseltzer> selfissued: we can create a RFC to create an empty registry, leave extensions in the webauthn spec and register them with IANA
17:32:22 <wseltzer> ... so whether we have a registry or not is independent of whether extensions stay in spec
17:32:32 <wseltzer> ... I'm not convinced that removing extensions would help developers
17:32:52 <wseltzer> ... though we should be clear that spec-defined extensions have no special status, they're optional, on a par with other extension
17:33:03 <wseltzer> tony: we need to do the registry-creation anyhow
17:33:30 <wseltzer> alexei: I hear 2 things being discussed, technical issue of what clients should do with unrecognized extensions
17:33:38 <wseltzer> ... and second, where extensions are registered
17:34:01 <wseltzer> vgb: 3 things: technical, where should ext defns live, should any extns be required?
17:34:04 <wseltzer> q?
17:34:26 <wseltzer> SamSrinivas: I suggest first hard stuff, then registry, then any mandatory extensions
17:34:50 <JeffH> what do you mean by "mandatory" ?  do you actually mean "pre-defined" ?
17:35:00 <wseltzer> alexei: one thing we talked about in Berlin: requiring clients to pass through things they don't understand would be a tough self for clients
17:35:28 <wseltzer> selfissued: protocol practice, if you don't understand something, you ignore it
17:35:40 <wseltzer> ... otherwise if you add an extension that won't be ignored, you break things
17:35:43 <wseltzer> s/self/sell/
17:36:27 <wseltzer> JeffH: we have multiple kinds of extensions
17:36:57 <wseltzer> alexei: question on the table, should a UA that doesn't know what the extension is forward data to the authenticator?
17:37:05 <alexei-goog> alexei-goog has joined #webauthn
17:37:15 <wseltzer> selfissued: "ignore" means pass the data through
17:37:43 <wseltzer> ... and talking to an authenticator that doesn't understand does no harm
17:38:14 <weiler> q+ with some suggested terminology
17:38:19 <wseltzer> giri: I filed an issue to do a pre-defined extension, "opaque" to pass through to the authenticator
17:38:28 <weiler> q+ to suggest some terminology
17:38:35 <wseltzer> dirkbalfanz: in Berlin, we had a fairly short discussion on the subject
17:38:49 <wseltzer> ... because browser-makers seemed to agree that it's the user-agent's job to protect the user
17:39:07 <wseltzer> ... and if it doesn't knwo what an extn is doing, it can't do its job
17:39:19 <wseltzer> ... so "ignore" meant to us "drop on the floor"
17:39:29 <wseltzer> giri: Qualcomm makes browsers, and we dont' agree
17:39:35 <JeffH> per https://w3c.github.io/webauthn/#extensions -- extensions can operate at just the clientplatform level, and/or at authnr level
17:39:50 <JeffH> q?
17:39:57 <wseltzer> ... there will be permissions the user should be responsible for
17:40:52 <wseltzer> SamSrinivas: I thought we'd reached consensus that the "give me a unique ID" would be problematic, and that's possible with opaque
17:41:00 <selfissued> selfissued has joined #webauthn
17:41:05 <wseltzer> giri: I agree with Mike, but it's pretty clear we won't have consensus
17:41:24 <wseltzer> ... so I wanted a way to define an extension that carries data meant to be passed through without client processing
17:41:35 <wseltzer> ... there's not extn defined that way so far
17:42:34 <wseltzer> alexei: giri, is your goal captured by taking extensions out and put them into an IANA registry?
17:42:51 <wseltzer> ... make all the extensions optional
17:43:10 <wseltzer> giri: Jeff's point is valid, the registry itself doesn't specify the extensions
17:43:22 <wseltzer> ... the IANA route makes it lightweight after we've set up the registry
17:43:32 <wseltzer> ... e.g. some places where there's just pointer to a website
17:43:54 <wseltzer> selfissued: we're not conflating issues
17:44:13 <wseltzer> ... Can we define an extension, someplace, that lets data be passed thjrough?
17:44:16 <gmandyam> q-
17:44:26 <wseltzer> vgb: I want to be clear what we're talking about
17:44:38 <JeffH> selfissued actually said "we /are/ conflating issues"
17:45:00 <wseltzer> ... some people who make UAs feel that they can't be agents of the user unless they understand all extensions
17:45:20 <selfissued> q+
17:45:27 <wseltzer> ... so we could say, in order for an extension to work, both client and authenticator must understand it.
17:45:45 <wseltzer> ... if you send an extension, in order to reach authenticator, you have to have at least one UA understand it
17:45:57 <wseltzer> s/we're not c/we're c/
17:46:12 <wseltzer> ... Wouldn't that work for Qualcomm, if it worked in qualcomm browser?
17:46:23 <JeffH> q?
17:46:27 <wseltzer> ack weiler
17:46:27 <Zakim> weiler, you wanted to suggest some terminology
17:46:49 <wseltzer> weiler: glad we're talking about "should we be passing data"
17:46:58 <wseltzer> ... terminology from BGP: "transitivie"
17:47:11 <weiler> ack Weiler
17:47:17 <wseltzer> ... transitive attributes, get passed on whether or not you understand them; non-transitive don't
17:47:20 <wseltzer> ack selfissued
17:47:53 <wseltzer> selfissued: in answer to vgb, if you don't require UAs to pass things through they don't understand, then a new extension never makes it through to an authenticators
17:48:07 <wseltzer> ... it gets dropped on the floor, so can't be acted on by authenticator
17:48:23 <wseltzer> vgb: why si that a problem? if you have an upgraded UA, you have better results.
17:48:47 <wseltzer> selfissued: protocols that enable extensions work in practice when they're not tampered with by default
17:49:07 <wseltzer> ... if having an extension requires everyone to act, then generally extension mechanism doesn't work and isn't used.
17:49:14 <wseltzer> s/transitivie/transitive/
17:49:23 <wseltzer> q?
17:49:31 <vgb> q+
17:49:47 <wseltzer> JeffH: clarification, does "dropping on the floor" = screwed with?
17:49:57 <wseltzer> selfissued: yes, if it's dropped, the extension doesn't work
17:50:17 <wseltzer> JeffH: part of the problem, the way the extension mechanism works, in order for transitive pass-thorugh
17:50:27 <wseltzer> ... the UA needs to know it to marshal data for authenticator
17:50:38 <wseltzer> ... we don't have standard framing
17:50:53 <wseltzer> ... to client platform, it's JSON; to authenticator, it's CBOR
17:51:06 <wseltzer> ... so the UA needs to know how to treat
17:51:08 <weiler> the value of transitive whatever seems greater when data is passing through many processing hops.  It's not clear to me the this is such a case.
17:51:23 <wseltzer> Rolf: that's not the only issue
17:51:38 <wseltzer> JeffH: in order to pass data, client seems to need to "understnd" extn
17:51:48 <wseltzer> vgb: 2 points
17:51:59 <wseltzer> ... in general, in protocols, it's perfectly fine to drop extensions
17:52:07 <weiler> here, we're talking about a relatively small number of steps in a client's stack.  Not disparate servers scattered around the net.
17:52:31 <wseltzer> ... secondly, it seems that requiring UAs to pass-through extns impoverishes the extn mechanism
17:52:44 <wseltzer> ... we have at least one where UA receives extension but passes nothing on
17:52:59 <wseltzer> ... authenticator selection mechanism, meant to trigger actions in UA, nothing sent to authenticator
17:53:22 <wseltzer> ... rich mechanism, the things sent to the authenticator are function of what's sent to the client
17:53:30 <wseltzer> ... we shoudlnt' require the fn always to be the identity fn
17:53:41 <JeffH> what vgb just said wrt client passing data to authnr is what I was trying to also clarify
17:54:06 <wseltzer> ... to Giri's point, Qualcomm phone UAs can understand and pass on Qualcomm extensions
17:54:21 <wseltzer> ... and if it's useful, other clients will have incentive to understand that extension too
17:54:32 <wseltzer> ... today, RPs already do that, suggest you upgrade your browser
17:54:51 <wseltzer> ... I'd rather not impoverish the extn framework and create requirements by the back door
17:55:02 <wseltzer> ... i.e., create mandatory extensions "pass through"
17:55:20 <wseltzer> JeffH: we could alter the API
17:55:42 <wseltzer> ... such that you can pass through data, without making any extension mandatory
17:55:49 <wseltzer> ... not sure it's a good idea, but it could be done
17:55:56 <wseltzer> q?
17:56:04 <wseltzer> ack vgb
17:56:33 <wseltzer> alexei: Giri, what do you think of vgb's point?
17:56:45 <wseltzer> ... do you still feel strongly that you want UAs to pass through?
17:56:45 <vgb> s/alexei/dirk/
17:57:09 <wseltzer> giri: Jeff said we could change API, that would satisfy our use case
17:58:14 <wseltzer> ... as I said in email yesterday, I'd like something like FIDO UAF, client doesn't drop what it doesn't understand
17:58:20 <wseltzer> ... I don't think that gets consensus here
17:58:25 <wseltzer> ... so I'm looking for next best
17:58:50 <wseltzer> dirkbalfanz: I thought you had your own browser that could understand the extension
17:59:10 <wseltzer> giri: browser could understand it enough to know that it doesn't need to process the data
17:59:22 <wseltzer> ... parallel to clearkey exchange for EME
17:59:33 <wseltzer> ... but we don't need to adopt that mechanism
17:59:39 <wseltzer> ... there's preceden
17:59:46 <wseltzer> s/preceden/precedent/
18:00:07 <wseltzer> dirkbalfanz: if you make the browser and you pass through the extensions, that's fine, right?
18:00:08 <JeffH> q+
18:00:12 <wseltzer> giri: we'll live with that
18:00:33 <wseltzer> ... I'm assuming the chrome side, all extensions are optional, so client can drop any as unsupported
18:00:45 <wseltzer> JeffH: there's no mandatory-to-implement in the spec
18:01:05 <wseltzer> dirkbalfanz: you're ok with "UAs drop extensions thye don't undersatnd"
18:01:11 <wseltzer> giri: I'll live with, not happy
18:01:14 <wseltzer> dirkbalfanz: Mike?
18:01:38 <wseltzer> selfissued: I'm willing to go with the group; meta-point, think about how we make extensions usable
18:02:09 <wseltzer> ... could be that if UAs drop data they dont' understand, new extns don't break the protocol flow
18:02:12 <wseltzer> q?
18:02:29 <gmandyam> I'm going to have to drop now.  I'll check the minutes for any further discussion on this topic.
18:02:37 <wseltzer> JeffH: given current design, whether or not there was breakage, in the eye of RP
18:02:55 <wseltzer> ... when it evaluates result from makeCredential or getAssertion
18:03:12 <wseltzer> ... if it doesn't get what it wants, then it knows something didnt' work
18:03:20 <wseltzer> ... though protocol operates
18:03:44 <wseltzer> selfissued: if you use an extn no one understands, it should function same as if you'd used no extension
18:04:06 <wseltzer> Rolf: challenge is that you need two entities who understand the extension, the client and the authenticator
18:04:23 <wseltzer> ... it's one thing to go to browsers, and another to go to authenticator
18:04:29 <wseltzer> ... substantial effect on the ecosystem
18:04:30 <wseltzer> q?
18:04:55 <wseltzer> JeffH: Support what Rolf just said, good point
18:04:59 <JeffH> q-
18:05:56 <wseltzer> Rolf: it seems to slow things down, harder to get additional functionality in devices
18:06:09 <wseltzer> dirkbalfanz: we don't want arbitrary functionality creep either
18:06:17 <wseltzer> ... extreme, arbitrary code execution
18:07:08 <wseltzer> Rolf: yet we always said implementing authenticator left to authenticator vendors; now we're saying it requires browser cooperation too
18:07:23 <wseltzer> dirkbalfanz: client has a role to protect user's privacy, to enforce restrictions between RPs
18:07:47 <wseltzer> ... makes the job of the client harder if it doesn't understand semantics of API call
18:08:02 <wseltzer> ... if semantics are clear, then give flexibility to the authenticators
18:08:02 <vgb> s/dirkbalfanz/alexei/
18:08:46 <selfissued> q+
18:08:48 <wseltzer> tony: want to get some agreement to move on
18:08:59 <wseltzer> ... we have options: defining no extensions in the spec
18:09:19 <wseltzer> ... defining extensions with semantics vgb and Jeff are advocating, optional
18:09:32 <vgb> q+
18:09:37 <wseltzer> JeffH: whether or not extensions are defined in the spec is separate issue still
18:10:34 <wseltzer> selfissued: the business property I've been advocating, that if you use a new extn, things work at least as well as if you'd use no extn, works under vgb's semantics
18:10:44 <wseltzer> ... that if the browser doesn't understand, it drops
18:10:53 <wseltzer> ... so long as spec is clear that all extns are option,
18:11:01 <Rolf> Sorry, had to drop-off.
18:11:06 <wseltzer> ... it provides documentation value to implementers to leave them there
18:11:24 <wseltzer> ... finally, I think we shoudl est IANA registry. separately
18:11:45 <wseltzer> vgb: it sounds as though we have broad agreement on IANA registyr
18:11:52 <wseltzer> JeffH: I can draft that
18:11:58 <wseltzer> s/registyr/registry/
18:12:11 <selfissued> +1 to all extensions being optional
18:12:11 <wseltzer> vgb: General agreement that all extns should be optional
18:12:44 <wseltzer> ... and it sounds like tentative agreement to leave pre-defined extns in the spec
18:12:47 <wseltzer> q+
18:13:08 <wseltzer> JeffH: I don't understand why we'd want to pull pre-defined extensions out
18:13:21 <wseltzer> ... we could also invite Giri to draft a 6th predefined extension
18:13:42 <selfissued> I think leaving some extensions in the spec adds documentation value to implementers
18:13:51 <wseltzer> q-
18:14:18 <wseltzer> alexei-goog: if we're making extensions optional, we might want a name better than pre-defined
18:14:27 <wseltzer> JeffH: I have some proposed text to clarify
18:15:15 <wseltzer> weiler: we could give developers the example of what to do with an unsupported extension
18:15:38 <wseltzer> ... opportunity to give an example of what happens if you don't understand the extension
18:15:59 <wseltzer> JeffH: I have a bunch of clarifications, terminology in a pull request
18:16:18 <wseltzer> vgb: I sent some comments last night
18:16:34 <wseltzer> ... suggest discussing on-thread
18:16:38 <wseltzer> tony: let's wrap up
18:16:54 <wseltzer> ... I'll summarize on-list and maybe we can close extension piece
18:17:00 <wseltzer> [adjourned]
18:17:04 <wseltzer> rrsagent, make logs public
18:17:07 <wseltzer> rrsagent, draft minutes
18:17:07 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webauthn-minutes.html wseltzer
18:17:43 <wseltzer> zakim, list attendees
18:17:43 <Zakim> As of this point the attendees have been wseltzer, tonynad, SamSrinivas, gmandyam, weiler, alexei, JeffH, vgb, Rolf, dirkbalfanz, selfissued
18:17:45 <wseltzer> rrsagent, draft minutes
18:17:45 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webauthn-minutes.html wseltzer
18:18:10 <wseltzer> Present: wseltzer, tonynad, SamSrinivas, gmandyam, weiler, alexei, JeffH, vgb,  Rolf, dirkbalfanz, selfissued
18:18:13 <wseltzer> rrsagent, draft minutes
18:18:13 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webauthn-minutes.html wseltzer
18:19:52 <wseltzer> s/shoudl/should/G
18:20:00 <wseltzer> s/doesnt'/doesn't/G
18:20:07 <wseltzer> s/shouldnt'/shouldn't/G
18:20:11 <wseltzer> rrsagent, draft minutes
18:20:11 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webauthn-minutes.html wseltzer
18:20:40 <wseltzer> s/dont'/don't/G
18:20:41 <wseltzer> rrsagent, draft minutes
18:20:41 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/25-webauthn-minutes.html wseltzer
21:40:36 <Zakim> Zakim has left #webauthn