16:58:30 <RRSAgent> RRSAgent has joined #webauthn
16:58:30 <RRSAgent> logging to http://www.w3.org/2016/08/03-webauthn-irc
16:58:32 <trackbot> RRSAgent, make logs public
16:58:34 <trackbot> Zakim, this will be
16:58:34 <Zakim> I don't understand 'this will be', trackbot
16:58:35 <trackbot> Meeting: Web Authentication Working Group Teleconference
16:58:35 <trackbot> Date: 03 August 2016
17:00:56 <jcj_moz> jcj_moz has joined #webauthn
17:00:57 <weiler> present+
17:01:07 <gmandyam> gmandyam has joined #webauthn
17:01:14 <weiler> Zakim, who is here?
17:01:14 <Zakim> Present: jcj_moz, gmandyam, vgb, apowers, dirkbalfanz, rbarnes, Rolf, ketan, weiler, wseltzer, christiaanbrand, alexei-goog, selfissued
17:01:16 <Zakim> On IRC I see gmandyam, jcj_moz, RRSAgent, weiler, nadalin, adrianba, mkwst, slightlyoff, Zakim, trackbot, wseltzer
17:01:20 <weiler> present=
17:01:22 <weiler> present+
17:01:32 <weiler> Zakim, who is here?
17:01:32 <Zakim> Present: weiler
17:01:34 <Zakim> On IRC I see gmandyam, jcj_moz, RRSAgent, weiler, nadalin, adrianba, mkwst, slightlyoff, Zakim, trackbot, wseltzer
17:01:36 <jcj_moz> present+
17:01:43 <rbarnes> rbarnes has joined #webauthn
17:02:07 <weiler> present+ gmandyam
17:02:35 <weiler> present+ nadalin rbarnes
17:02:38 <weiler> Zakim, who is here?
17:02:38 <Zakim> Present: weiler, jcj_moz, gmandyam, nadalin, rbarnes
17:02:40 <Zakim> On IRC I see rbarnes, gmandyam, jcj_moz, RRSAgent, weiler, nadalin, adrianba, mkwst, slightlyoff, Zakim, trackbot, wseltzer
17:04:44 <Rolf> Rolf has joined #webauthn
17:05:33 <weiler> agenda: https://lists.w3.org/Archives/Public/public-webauthn/2016Aug/0006.html
17:06:31 <Rolf> present+
17:07:19 <Nitin> Nitin has joined #webauthn
17:07:29 <Rahul_Ghosh> Rahul_Ghosh has joined #webauthn
17:07:49 <weiler> present+ Nitin Rahul_Ghosh
17:07:56 <weiler> Zakim, who is here?
17:07:56 <Zakim> Present: weiler, jcj_moz, gmandyam, nadalin, rbarnes, Rolf, Nitin, Rahul_Ghosh
17:07:58 <Zakim> On IRC I see Rahul_Ghosh, Nitin, Rolf, rbarnes, gmandyam, jcj_moz, RRSAgent, weiler, nadalin, adrianba, mkwst, slightlyoff, Zakim, trackbot, wseltzer
17:08:31 <weiler> present+ dirk
17:09:20 <wseltzer> present+ wseltzer
17:09:35 <weiler> scribenick: Rahul_Ghosh
17:09:58 <alexei-goog> alexei-goog has joined #webauthn
17:10:02 <alexei-goog> present+
17:11:04 <Nitin> Nitin: Trial
17:11:15 <weiler> scribenick: Nitin
17:12:05 <wseltzer> Topic: returning a multi-factor authenticator's factor-in-use
17:12:31 <Nitin> Anthony: Multi factor authentication factor
17:12:57 <Nitin> Nitin: Rahul prsenting the motivation behind the request
17:17:06 <gmandyam> q+
17:17:26 <wseltzer> [[ Problem Statement: use case: a webauthn authenticator with a single AAGUID that supports multiple authentication methods]]
17:17:40 <alexei-goog> q-
17:18:53 <wseltzer> [[ Potential Solutions, update attestation statement and authenticator data to include factor and key/matcher... 2. create a new extension, UserVerificationMethod... 3. update the UserVerificationIndex extension to include factor and key/matcher protection type ]]
17:20:20 <wseltzer> Rahul_Ghosh: support using UVI extension, quickest way to get this into the spec
17:20:27 <wseltzer> ack gmandyam
17:20:45 <Rolf> q+
17:20:46 <dirkbalfanz> dirkbalfanz has joined #webauthn
17:20:49 <wseltzer> gmandyam: looking at UVI in spec, it's opaque
17:21:09 <wseltzer> ... if authenticator is willing to define proprietary protocol that RPs can respect, you can override
17:21:27 <wseltzer> ... boils down to whether it shoudl be defined explicitly so browser can participate
17:21:51 <wseltzer> Rahul_Ghosh: Vijay said client should be @@
17:22:05 <wseltzer> gmandyam: can we define it future-proof, multi-modal authenticators
17:22:15 <wseltzer> ... soft combinations of authenticators
17:22:20 <wseltzer> ... that release just a score
17:22:44 <wseltzer> Rahul_Ghosh: that's the intention
17:22:51 <wseltzer> ... future proof and factor agnostic
17:23:46 <wseltzer> nadalin: so if you had an authenticator with 2 biometrics, you'd want to distinguish between the two
17:23:49 <wseltzer> ack Rolf
17:23:52 <gmandyam> q-
17:24:14 <wseltzer> Rolf: to protect against what people calll friendly fraud, devices used by different people
17:24:34 <wseltzer> ... diff users might use diff biometrics
17:24:49 <wseltzer> ... you might want to tell server which user, which biometric
17:25:13 <wseltzer> ... must be different identifier, different per RP, so it can't be tracked
17:25:33 <wseltzer> ... if we overload and add meaning, syntax vs semantics.
17:25:36 <vgb> vgb has joined #webauthn
17:26:07 <wseltzer> ... you can't use the same extension to do these two different semantics
17:26:12 <weiler> present+ vgb
17:26:16 <wseltzer> ... not sure that's a good idea, it will confuse people
17:26:28 <wseltzer> ... better to define a new extension for new purpose
17:26:53 <wseltzer> ... since it's orthogonal from semantic
17:27:05 <wseltzer> nadalin: so you want to keep UVI as it is, and add a new one?
17:27:09 <wseltzer> Rolf: Yes, option 2
17:27:46 <wseltzer> gmandyam: I think UVI is opaque blob, semantics need to be defined in-line
17:28:00 <wseltzer> ... do you want UVI to be opaque? or more in the open for browser inspection?
17:28:22 <wseltzer> ... there seems to be opposition in group to opaque data extensions
17:28:29 <wseltzer> Rolf: I don't think UVI is opaque
17:28:38 <wseltzer> ... identifier, never shared across RPs
17:28:47 <wseltzer> ... different for different biometrics
17:28:56 <wseltzer> ... just doesn't define a specific value
17:28:56 <jcj_moz> q+
17:29:08 <wseltzer> ... because different RPs shouldnt' get it shared
17:29:21 <wseltzer> gmandyam: but spec text doesn't say how UVI generates values
17:29:24 <wseltzer> ... nothing normative
17:29:59 <rbarnes> q?
17:30:08 <wseltzer> ... it's inscrutable to browser
17:30:17 <wseltzer> Rolf: let's get UVI written down
17:30:25 <wseltzer> ... UVM as a different thing
17:30:36 <wseltzer> ack jcj_moz
17:30:38 <weiler> ... different semantics
17:30:51 <wseltzer> jcj_moz: agree with Giri that UVI, as written, is opaque blob
17:30:58 <Rahul_Ghosh> q+
17:31:14 <wseltzer> ... I want to reduce opacity
17:31:33 <jcj_moz> ack
17:31:42 <vgb> anyone else just lose audio or just me?
17:31:55 <nadalin> just u
17:31:57 <vgb> ok, will reconnect
17:32:34 <wseltzer> ack Rahul_Ghosh
17:32:37 <wseltzer> q?
17:33:03 <weiler> Rolf: not overkill, does not require two operations.  Good practice to keep separate.
17:33:47 <weiler> nadalin: recap state: going over UViIproposal.
17:34:02 <weiler> s/UViIproposal/UVI proposal/
17:34:16 <weiler> ... objecting to opacity, want it more defined.
17:34:49 <weiler> vgb: agree w/ Giri.  agree that UVI as defined is very opaque.  nothing client can do to tell if
17:35:01 <weiler> .. this is a legit identifier or is violating privacy
17:35:24 <weiler> ... opaqueness os UVI makes it hard for client and less useful for RP.  Only thing RP is compare
17:35:39 <rbarnes> q+
17:35:49 <weiler> ...  getcred and make assertion.  find proposal better than current state.
17:36:49 <weiler> Rahul: right now it's just a byte string.  fine to define a specific format.  proposal ... adds some more fields.
17:38:01 <weiler> rbarnes: no opinion.  browser has to treat as opaque field.  should minimize how big they are.  proposal: one octet instead of two.  don't need much code point space.
17:38:18 <weiler> Rahul: can do that, but @@
17:38:52 <weiler> rbarnes: this is spec will not normatively reference FIDO specs.
17:39:01 <weiler> s/is //
17:39:24 <weiler> Rahul: this proposal references prior registry.  fine w/ new registry.
17:40:00 <weiler> rbarnes: if we're going to enumerate types, try to estimate future needs and see if we can limit to one octet
17:40:37 <rbarnes> me weiler: minimizing covert channel bandwidth
17:41:39 <weiler> rbarnes: more elegant to have a bitmap
17:42:30 <weiler> Nitin: are we leaning toward UVM / separate ext.?
17:42:42 <vgb> s/more elegant/better to have a CBOR array than/
17:42:43 <weiler> giri: qualcomm will support UVM
17:43:37 <weiler> Giri: in agreement re: justification for UVM, may replace UVI going forward.
17:44:15 <weiler> Nitin: Rahul will change UVM re: CBOR array and send it out.
17:45:18 <weiler> barnes: from privacy POV, more enthused re: list (constrained to three?) rather than array.  and constrain values of list to ones registered.  to constraint the leakage potential.
17:45:46 <weiler> Rahul: @@
17:46:13 <weiler> nadalin: to move forward, any objection to leaving UVI as-is and looking at UVM as new extension, perhaps more specific?
17:46:20 <weiler> vijay: OK.
17:46:30 <weiler> Dirk: OK to have separate ext.
17:46:34 <weiler> Giri: OK.
17:46:45 <weiler> JC: don't support it.  but not sure I mind.
17:46:58 <weiler> Giri: why?
17:47:28 <weiler> JC: whole category of "things that aren't obvious". privacy concerns w/ non-obvious extensions.
17:47:52 <weiler> Rahul: but we're trying to make it obvious
17:48:44 <weiler> JC: @@... kind of an advanced use case.
17:49:02 <weiler> barnes: any other comments?
17:49:14 <weiler> Nitin: byte field or integer?
17:50:52 <weiler> Rolf: CBOR array needs more space.  existing values (from FIDO) would avoid confusion.  would use FIDO values (defined somewhere)  in a CBOR array.
17:51:10 <weiler> ... would be confusing to have different values in different registries.
17:52:02 <weiler> nadalin: new proposal something this week or next?
17:52:05 <weiler> rahul: yes.
17:52:38 <weiler> topic: Giri's proposal for location extensions
17:53:36 <wseltzer> https://lists.w3.org/Archives/Public/public-webauthn/2016Aug/0004.html
17:53:45 <weiler> gmandyam: tried to make it closer to conventions from other extensions (e.g. transaction confirmation).  if you go to authenticator data... defined two element map.
17:53:50 <nitin> nitin has joined #webauthn
17:54:05 <weiler> ... second element is an array.
17:54:12 <nitin> Rahul: When authenticator is called it chooses the factor
17:54:27 <weiler> ... different authenticators may return different attributes (e.g. elevation or not)
17:54:28 <nitin> As part of Make credential and Get Assertion this information is important to relying party
17:54:40 <nitin> Three potential solutions are provided
17:54:52 <nitin> Tony: Vijay is leaning towards 3 UVI extension
17:55:02 <nitin> Rahul: Agrees with the proposal
17:55:15 <nitin> Giri: UVI is defined as opaque data. Should authentication be defined explicitly?.
17:55:26 <nitin> Nitin:  Authentication should be defined explicitly.
17:55:36 <nitin> Giri: Google has soft combinations should try to future proof, may not cover everything
17:55:47 <nitin> Rahul: That is the intention
17:55:58 <alexei-goog> q+
17:55:58 <nitin> Rolf: To provide a way to protect against friendly fraud. Each person might register different biometrics, to pass user verification.
17:56:17 <nitin> Sometimes you want to classify the method so financial transaction can be pin-pointed to a specific user. UVI extension requires that the extension must be the same for the same user. So for symantic meaning of UVI changes if it is overloaded with this request. It is better to define a new extension that reports this
17:56:30 <nitin> Tony: Does it mean keep UVI as it is and create a new extension. This is option 2.
17:56:40 <nitin> Giri: UVI is not fully defined. So it is opaque
17:56:48 <weiler> (back to location extension)  barnes: better to have it be inspectable, not opaque.  not comfortable adding this to API in WebAuthn, since it seems afield from authentication.
17:56:51 <nitin> Rolf: UVI should be written down so everyone understands the same way. Rolf will write it down.
17:57:01 <nitin> JC: UVI as written is an opaque blob.
17:57:05 <weiler> giri: i disagree.  we're productizing it.
17:57:10 <nitin> Rahul: If we keep UVM and UVI as two separate extensions then the RP will need to ask for two extensions.
17:57:22 <nitin> Rolf: The RP can ask for two extensions and does not have to make two separate calls,
17:57:32 <nitin> Vijay: UVI as written is an opaque blob. This minimizes the value to the RP.
17:57:44 <nitin> Rahul: Presenting the UVI extension proposal. Add three more fields: User verification methods: Security protection type, matcher protection type, protection method.
17:57:51 <weiler> giri: the fact that is came over from FIDO was not by accident. several companies considering it.
17:57:56 <nitin> Richard: The size should be small
17:58:04 <weiler> giri: mozilla's objection still stands?
17:58:08 <nitin> Rahul: These are small size protections
17:58:19 <nitin> Richard: Should be a different registry, Look at how many we need.
17:58:34 <weiler> rbarnes: no formal objection at this moment.  but our initial implementation would block this.  we're not immediately comfortable exposing it.
17:58:38 <nitin> Nitin: May need to take into account combinations.
17:58:46 <nitin> Richard: Make it a CBOR array if we want list of things
17:59:00 <nitin> Rahul: Yes we can do that. Will make that change and send it out.
17:59:08 <weiler> giri: std is written so that extensions can be dropped (w/o even notifying user).  business decision of which to support is not addressed in std.
17:59:14 <nitin> Giri: Qualcomm will support UVM as an extension
17:59:25 <nitin> Rahul: Should be byte field or integer/short/short
17:59:36 <nitin> Richard: Should be constrained
17:59:40 <weiler> JC: I appreciate it being inspectable, too.  other than my general stance on extensions, I like this one. I'm not sure how to do the UI things.
17:59:48 <nitin> Tony: Is anyone opposed to making a new extension.(UVM)
17:59:51 <weiler> ... but ok with it, as Giri presented it.
18:00:03 <nitin> JC: The category of things are not obvious and privacy concerns come up with those. But will reluctantly support it. Skeptical for need for extensions at this stage and is an advanced use case.
18:00:10 <weiler> nadalin: any objections to a pull req for this?
18:00:17 <nitin> Vijay: Byte values for CBOR array.
18:00:31 <nitin> Rolf: CBOR array needs more space. Existing defined value from FIDO will be great. To avoid confusion. Keep W3C and FIDO registries should be consistent.
18:00:33 <weiler> Dirk: separate doc or base?
18:00:41 <weiler> giri: one of predefined in main doc.
18:00:45 <nitin> Rahul: Will send out the proposal
18:00:57 <nitin> Tony: Concludes the discussion on this proposal. Giri’s proposal for location proposal.
18:01:28 <nitin> Giri: Described the location proposal.
18:02:09 <weiler> nadalin: could we do 90 minutes next week?
18:02:09 <nitin> Richard: Core specification should be put to the front of the agenda
18:02:23 <wseltzer> [regrets for next week, but no objection]
18:02:34 <weiler> vgb: no objections,
18:03:03 <weiler> ... will send another msg to the list.  think re: that message...
18:03:06 <nitin> Vijay: Should be valuable to receive feedback
18:03:14 <weiler> nadalin: please look at two open pull req.
18:03:22 <weiler> giri: may I create pull req for location?
18:03:59 <weiler> there was proposal for a separate call to separate the non-normative work from the normative work
18:04:06 <weiler> nadalin: go ahead.
18:04:34 <weiler> ... next week will be 90.
18:04:41 <nitin> Rahul should also send out teh slides
18:05:38 <wseltzer> rrsagent, make minutes
18:05:38 <RRSAgent> I have made the request to generate http://www.w3.org/2016/08/03-webauthn-minutes.html wseltzer