16:34:27 <RRSAgent> RRSAgent has joined #webauthn
16:34:27 <RRSAgent> logging to http://www.w3.org/2016/08/17-webauthn-irc
16:34:29 <trackbot> RRSAgent, make logs public
16:34:31 <trackbot> Zakim, this will be
16:34:31 <Zakim> I don't understand 'this will be', trackbot
16:34:32 <trackbot> Meeting: Web Authentication Working Group Teleconference
16:34:32 <trackbot> Date: 17 August 2016
16:34:37 <weiler> present=
16:34:44 <weiler> Agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016Aug/0080.html
16:36:10 <weiler> weiler has changed the topic to: https://lists.w3.org/Archives/Public/public-webauthn/2016Aug/0080.html
16:40:03 <weiler> Chair: rbarnes, nadalin
16:51:13 <Nadalin> Nadalin has joined #webauthn
16:51:23 <Nadalin> +present
16:51:43 <weiler> present?
16:51:58 <weiler> Zakim, who is here?
16:51:58 <Zakim> Present: present
16:52:00 <Zakim> On IRC I see Nadalin, RRSAgent, weiler, adrianba, mkwst, slightlyoff, Zakim, trackbot, wseltzer
16:52:08 <weiler> present=
16:52:14 <weiler> present+ nadalin
16:52:19 <weiler> Zakim, who is here?
16:52:19 <Zakim> Present: nadalin
16:52:21 <Zakim> On IRC I see Nadalin, RRSAgent, weiler, adrianba, mkwst, slightlyoff, Zakim, trackbot, wseltzer
16:53:31 <wseltzer> present=
16:53:38 <wseltzer> present+ nadalin
16:55:49 <Nadalin> figures
16:57:58 <wseltzer> present+
16:58:35 <gmandyam> gmandyam has joined #webauthn
16:58:45 <jcj_moz> jcj_moz has joined #webauthn
16:58:50 <wseltzer> present+ weiler, gmandyam, ketan
16:59:49 <rbarnes> rbarnes has joined #webauthn
17:00:14 <wseltzer> present+ jcj_moz, rbarnes
17:00:31 <gmandyam> present+ gmandyam
17:00:54 <apowers> apowers has joined #webauthn
17:01:23 <wseltzer> present+ Christiaan
17:01:47 <wseltzer> present+ apowers
17:01:57 <apowers> thx :)
17:02:14 <Rahul> Rahul has joined #webauthn
17:02:37 <wseltzer> present+ Rahul
17:03:18 <vgb> vgb has joined #webauthn
17:04:06 <vgb> present+ vgb
17:04:16 <wseltzer> present+ JeffH
17:04:47 <JeffH> JeffH has joined #webauthn
17:05:18 <JeffH> present+
17:05:45 <wseltzer> zakim, who is here?
17:05:45 <Zakim> Present: nadalin, wseltzer, weiler, gmandyam, ketan, jcj_moz, rbarnes, Christiaan, apowers, Rahul, vgb, JeffH
17:05:47 <Zakim> On IRC I see JeffH, vgb, Rahul, apowers, rbarnes, jcj_moz, gmandyam, Nadalin, RRSAgent, weiler, adrianba, mkwst, slightlyoff, Zakim, trackbot, wseltzer
17:06:19 <Rolf> Rolf has joined #webauthn
17:07:15 <weiler> scribenick: apowers
17:07:40 <apowers> I am honored to be scribe today
17:07:50 <Rolf> present+
17:08:07 <wseltzer> q+
17:08:10 <apowers> tony: please read Wendy's note
17:08:31 <apowers> weiler: patent disclosure, please don't discuss patents on the list
17:08:48 <weiler> s/weiler/wseltzer/
17:08:50 <RobTrace> RobTrace has joined #Webauthn
17:08:54 <selfissued> selfissued has joined #webauthn
17:08:54 <apowers> thx
17:09:06 <wseltzer> q-
17:09:12 <wseltzer> q- alexei-goog
17:09:29 <apowers> Nadalin: note sent to mailing list for review, appreciate people looking at those
17:09:52 <alexei-goog> alexei-goog has joined #webauthn
17:09:56 <apowers> Nadalin: discuss open pull requsts
17:10:02 <alexei-goog> present+
17:10:33 <apowers> gmandyam: happy to discuss my pull request, looking for decision that it's ready to be incorporated
17:10:47 <Rahul> q+
17:11:19 <apowers> Nadalin: my understanding was that you and Rahul were going to create pull requests
17:11:32 <apowers> gmandyam: created several weeks ago
17:12:00 <apowers> vijay: merge 154?
17:12:07 <wseltzer> https://github.com/w3c/webauthn/pull/154
17:12:12 <apowers> JeffH: I was in the process of reviewing... but... cool
17:13:08 <dirkbalfanz> dirkbalfanz has joined #webauthn
17:13:27 <apowers> vijay: please take a gander, and I can merge it in later today
17:13:47 <apowers> [is Vijay on IRC?]
17:13:57 <vgb> i'm here
17:13:58 <apowers> thx
17:15:54 <apowers> vgb: would like to go through issues to address gmandyam's comments
17:16:32 <apowers> alexei-goog: Giri, were you asking if the PayPal app and the PayPal website would have access to the same key material
17:17:07 <apowers> vgb: yes, determined by eTLD+1 for web and different for platform with access determined by RPID
17:17:25 <apowers> JeffH: no concern with changing facet to origin
17:17:48 <apowers> rbarnes: would need to change that in the dictionary
17:18:23 <apowers> JeffH: okay with merging
17:18:39 <apowers> vgb: Alexei -- okay with merging? need to review?
17:18:44 <apowers> alexei-goog: not all the way through yet
17:18:51 <apowers> ... if others have looked, I'm fine
17:18:56 <apowers> ... don't want to hold it up
17:19:13 <apowers> vgb: just merge it when you're done reviewing
17:19:16 <apowers> ... today or tomorrow?
17:19:20 <apowers> alexei-goog: yes
17:19:47 <apowers> jcj_moz: looked at it, no issues... haven't reviewed most recent changes, but wouldn't change my mind
17:19:51 <apowers> vgb: mostly editorial
17:20:12 <apowers> Nadalin: any other PRs that people have questions on?
17:21:44 <apowers> vgb: core spec, what to do with credential object (143, 158)
17:21:58 <wseltzer> https://github.com/w3c/webauthn/pull/143
17:22:05 <wseltzer> https://github.com/w3c/webauthn/pull/158
17:22:25 <apowers> ... both in the same direction of getting rid of type in cred object
17:22:47 <apowers> ... follow up on these? close them out? more thinking?
17:23:07 <apowers> rbarnes: seem to be moving away from creds being objects
17:23:16 <apowers> ... opaque blobs of data
17:23:27 <apowers> vgb: in favor of 158?
17:24:02 <apowers> rbarnes: don't need an object / interface, just cred IDs
17:24:13 <apowers> vgb: only other thing in the object is type
17:24:33 <apowers> ... stands for algorithm type, formatting signature, authnr data, method of signature generation
17:25:09 <apowers> ... what would future implementations do without a type
17:25:38 <apowers> rbarnes: specific version with a specific ID
17:25:51 <apowers> JeffH: type != version
17:26:46 <apowers> rbarnes: set an option?
17:27:41 <apowers> vgb: close out these PRs with no action = Cred ID is always paired with type
17:27:51 <apowers> ... almost like a namespace
17:28:38 <apowers> ... moving type to somewhere else divorces type from ID, may mean that IDs are unique across all types
17:28:51 <apowers> rbarnes: can't assume that there is a binding to ID anyway
17:30:57 <apowers> vgb: type provides a few things, e.g. - RPID hash is a SHA256 hash of RPID; different browser / cred type, uses ROT13 for RPID hash
17:31:19 <apowers> ... RPIDs hashes don't match, problems ensue
17:32:00 <apowers> rbarnes: things don't blow up until they hit the authenticator
17:32:10 <apowers> ... just put the type in when you're talking to the authenticator
17:32:18 <apowers> vgb: true, but how
17:32:25 <apowers> ... currently a list of creds
17:33:16 <apowers> ... put in options would mean you'd have to say "I'm okay with ID-A of Type-A, ID-B of Type-B..."
17:33:24 <apowers> rbarnes: that makes sense for pairing them
17:33:44 <apowers> JeffH: would want to keep them together as is at this point
17:33:59 <apowers> *** tumbleweeds ***
17:34:22 <apowers> vgb: happy to abandon this PR
17:34:33 <apowers> JeffH: 143 and 158?
17:34:43 <apowers> jcj_moz: fine with closing 143
17:35:03 <apowers> rbarnes: okay with this, maybe minor clean-ups
17:35:14 <apowers> Nadalin: both, 143 and 158
17:35:29 <apowers> vgb: two more things
17:35:52 <apowers> ... 1) Andre, TokenID
17:36:02 <apowers> PR 164
17:36:08 <apowers> https://github.com/w3c/webauthn/pull/164
17:36:25 <apowers> alexei-goog: internal version structure?
17:36:37 <apowers> JeffH: identifier, effectively
17:36:47 <apowers> ... string of bytes
17:37:07 <apowers> alexei-goog: spec that says how one arrives at the string of bytes, should we indicate which of the two methods is being used?
17:37:20 <apowers> ... being handled at the other layer?
17:37:24 <apowers> JeffH: correct
17:37:55 <apowers> dirkbalfanz: token binding spec indicates RSA, EC, followed by key
17:38:09 <apowers> ... if a future version puts the key first, we wouldn't be able to know
17:38:22 <apowers> JeffH: doesn't matter to WebAuthn, just checking for a match
17:38:53 <apowers> alexei-goog: attacker, same string of bytes
17:39:01 <apowers> ... different versions
17:39:14 <apowers> vgb: putting that in our spec doesn't fix that problem
17:39:22 <apowers> ... could have other information in key for disambiguation
17:40:07 <apowers> ... separate problem for token binding people to look at, versioning
17:41:22 <apowers> JeffH: andere's assertion is that you just do a byte-by-byte compare, and that's all you care about for this spec
17:42:02 <apowers> vgb: if the two sides don't match, you already have a problem that will be caught at the token binding level
17:42:54 <apowers> alexei-goog (?): object strongly, could mean different things, could cause problems
17:43:13 <apowers> vgb: goal here is to be more aligned with token binding draft
17:44:07 <apowers> ... up to the token binding people to make sure that there's no way to derive the same token in two different ways, introduces MITM attack against token binding
17:44:57 <apowers> gmandyam: client isn't going to be interpreting token binding, just server
17:45:02 <apowers> vgb: good question
17:46:01 <apowers> alexei-goog (?): seems a little adventurous to do it that way
17:46:42 <apowers> JeffH: maybe feedback to token binding spec
17:46:57 <apowers> thx, I couldn't figure out which of you it was
17:47:13 <wseltzer> https://github.com/w3c/webauthn/pull/162
17:47:15 <apowers> s/alexei-goog (?)/dirkbalfanz/g
17:48:07 <apowers> gmandyam: would have to implement authnr to accept either
17:48:23 <apowers> vgb: authnr doesn't know
17:48:41 <apowers> ... just uses RPID hash
17:51:09 <apowers> ... if caller specifics strict matching, no matching across multiple origins
17:51:37 <apowers> alexei-goog: seems like this works on a call-by-call basis
17:51:41 <apowers> ... request strict or not
17:52:03 <apowers> ... might get RPs into trouble? forget to add strict sometimes and end up with a non-match?
17:52:22 <apowers> selfissued: more choices = more developer problems, just pick one
17:53:24 <apowers> vgb: alexei arguing that we should have that option?
17:54:14 <apowers> alexei-goog: what's the benefit?
17:54:22 <dirkbalfanz> dirkbalfanz has joined #webauthn
17:54:22 <apowers> rbarnes: be more conservative
17:54:53 <apowers> ... eTLD+1 shouldn't be the only option
17:55:11 <apowers> dirkbalfanz: more of a privacy concern
17:56:00 <apowers> gmandyam: get more explicit / concrete examples in text
17:57:02 <apowers> vgb: point of PR was to show concretely what the change would look like
17:57:14 <apowers> vgb: disagree with the change in principal?
17:57:33 <apowers> s/principal/principle/
17:57:54 <weiler> weiler has joined #webauthn
17:58:27 <apowers> rbarnes: not concerned about adding one flag
17:58:46 <apowers> vgb: two different cred types (strict vs loose)?
17:59:07 <apowers> JeffH: adding to the already long list of attributes
17:59:50 <apowers> dirkbalfanz: didn't think this would be boolean, eTLD+n
18:00:00 <apowers> JeffH: term is "domain lowering" (?)
18:00:33 <apowers> vgb: why don't we just reuse that mechanism?
18:00:42 <apowers> ... infer it from the context
18:01:00 <apowers> rbarnes: not going to like the implications of that, then everything in JS gets scoped to that
18:02:07 <apowers> vgb: how do we make progress?
18:02:27 <apowers> christiaan: sharing between app and website, e.g. - Android
18:02:48 <apowers> rbarnes: option is still there with relaxed mode
18:03:21 <apowers> christiaan: e.g. - bank would use strict rather than relaxed because it sounds better, would take away some of the usability
18:03:28 <apowers> rbarnes: how does it work on Android?
18:04:15 <apowers> alexei-goog: how is app "foo" related to TLD of "bar"
18:04:46 <apowers> ... specified by app developers
18:05:22 <apowers> ... not clear how strict would be handled in that situation
18:06:08 <apowers> JeffH: eTLD+1 should be default, current deployed practice
18:06:30 <apowers> ... making strict the default would hinder deployment
18:06:44 <apowers> selfissued: agreed
18:07:20 <apowers> alexei-goog: not sure how we describe to developers how to do it right
18:08:12 <apowers> vgb: other remaining issue is attestation, will summarize next time where we landed
18:09:16 <apowers> Nadalin: do we want to discuss any extensions?
18:09:43 <Rolf> have to leave now.
18:09:44 <apowers> alexei-goog: I will come back with a more strongly informed opinion on strict next time
18:09:58 <apowers> Nadalin: for 162?
18:10:03 <apowers> alexei-goog: yes
18:10:08 <apowers> Nadalin: next week?
18:10:14 <apowers> alexei-goog: we can try
18:11:14 <apowers> Nadalin: leaves us with PR 169, 157
18:11:18 <apowers> ... extension discussions
18:12:14 <apowers> gmandyam: I've got something that can be incorporated
18:12:28 <apowers> ... CBOR mappings
18:12:51 <apowers> ... examples of formatting of lat / long
18:13:53 <apowers> jcj_moz: I'm good with it when complete, just wouldn't know how to implement right now
18:15:42 <apowers> Nadalin: adjourn
18:16:45 <wseltzer> rrsagent, draft minutes
18:16:45 <RRSAgent> I have made the request to generate http://www.w3.org/2016/08/17-webauthn-minutes.html wseltzer
18:16:51 <wseltzer> rrsagent, make logs public
18:16:57 <wseltzer> trackbot, end meeting
18:16:57 <trackbot> Zakim, list attendees
18:16:57 <Zakim> As of this point the attendees have been nadalin, wseltzer, weiler, gmandyam, ketan, jcj_moz, rbarnes, Christiaan, apowers, Rahul, vgb, JeffH, Rolf, alexei-goog
18:17:05 <trackbot> RRSAgent, please draft minutes
18:17:05 <RRSAgent> I have made the request to generate http://www.w3.org/2016/08/17-webauthn-minutes.html trackbot
18:17:06 <trackbot> RRSAgent, bye
18:17:06 <RRSAgent> I see no action items