See also: IRC log
<trackbot> Date: 03 August 2016
<weiler> present=
<weiler> scribenick: wseltzer
<Nitin> Nitin: Trial
<Nitin> Anthony: Multi factor authentication factor
<Nitin> Nitin: Rahul prsenting the motivation behind the request
[[ Problem Statement: use case: a webauthn authenticator with a single AAGUID that supports multiple authentication methods]]
[[ 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 ]]
Rahul_Ghosh: support using UVI extension, quickest way to get this into the spec
gmandyam: looking at UVI in spec, it's opaque
... if authenticator is willing to define proprietary protocol that RPs can respect, you can override
... boils down to whether it shoudl be defined explicitly so browser can participate
Rahul_Ghosh: Vijay said client should be @@
gmandyam: can we define it future-proof, multi-modal authenticators
... soft combinations of authenticators
... that release just a score
Rahul_Ghosh: that's the intention
... future proof and factor agnostic
nadalin: so if you had an authenticator with 2 biometrics, you'd want to distinguish between the two
Rolf: to protect against what people calll friendly fraud, devices used by different people
... diff users might use diff biometrics
... you might want to tell server which user, which biometric
... must be different identifier, different per RP, so it can't be tracked
... if we overload and add meaning, syntax vs semantics.
... you can't use the same extension to do these two different semantics
... not sure that's a good idea, it will confuse people
... better to define a new extension for new purpose
... since it's orthogonal from semantic
nadalin: so you want to keep UVI as it is, and add a new one?
Rolf: Yes, option 2
gmandyam: I think UVI is opaque blob, semantics need to be defined in-line
... do you want UVI to be opaque? or more in the open for browser inspection?
... there seems to be opposition in group to opaque data extensions
Rolf: I don't think UVI is opaque
... identifier, never shared across RPs
... different for different biometrics
... just doesn't define a specific value
... because different RPs shouldnt' get it shared
gmandyam: but spec text doesn't say how UVI generates values
... nothing normative
... it's inscrutable to browser
Rolf: let's get UVI written down
... UVM as a different thing
<weiler> ... different semantics
jcj_moz: agree with Giri that UVI, as written, is opaque blob
... I want to reduce opacity
<jcj_moz> ack
<vgb> anyone else just lose audio or just me?
<nadalin> just u
<vgb> ok, will reconnect
<weiler> scribenick: weiler
Rolf: not overkill, does not require two operations. Good practice to keep separate.
nadalin: recap state: going over UVI proposal.
... objecting to opacity, want it more defined.
vgb: agree w/ Giri. agree that UVI as defined is very opaque. nothing client can do to tell if
... this is a legit identifier or is violating privacy
... opaqueness os UVI makes it hard for client and less useful for RP. Only thing RP is compare
... getcred and make assertion. find proposal better than current state.
Rahul: right now it's just a byte string. fine to define a specific format. proposal ... adds some more fields.
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.
Rahul: can do that, but @@
rbarnes: this spec will not normatively reference FIDO specs.
Rahul: this proposal references prior registry. fine w/ new registry.
rbarnes: if we're going to enumerate types, try to estimate future needs and see if we can limit to one octet
<rbarnes> me weiler: minimizing covert channel bandwidth
rbarnes: better to have a CBOR array than to have a bitmap
Nitin: are we leaning toward UVM / separate ext.?
giri: qualcomm will support UVM
... in agreement re: justification for UVM, may replace UVI going forward.
Nitin: Rahul will change UVM re: CBOR array and send it out.
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.
Rahul: @@
nadalin: to move forward, any objection to leaving UVI as-is and looking at UVM as new extension, perhaps more specific?
vijay: OK.
Dirk: OK to have separate ext.
Giri: OK.
JC: don't support it. but not sure I mind.
Giri: why?
JC: whole category of "things that aren't obvious". privacy concerns w/ non-obvious extensions.
Rahul: but we're trying to make it obvious
JC: @@... kind of an advanced use case.
barnes: any other comments?
Nitin: byte field or integer?
Rolf: CBOR array needs more space. existing values (from FIDO) would avoid confusion. would use FIDO values (defined somewhere) in a CBOR array.
... would be confusing to have different values in different registries.
nadalin: new proposal something this week or next?
rahul: yes.
<wseltzer> https://lists.w3.org/Archives/Public/public-webauthn/2016Aug/0004.html
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.
... second element is an array.
... different authenticators may return different attributes (e.g. elevation or not)
(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.
giri: i disagree. we're productizing it.
... the fact that is came over from FIDO was not by accident. several companies considering it.
... mozilla's objection still stands?
rbarnes: no formal objection at this moment. but our initial implementation would block this. we're not immediately comfortable exposing it.
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.
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.
... but ok with it, as Giri presented it.
nadalin: any objections to a pull req for this?
Dirk: separate doc or base?
giri: one of predefined in main doc.
nadalin: could we do 90 minutes next week?
<wseltzer> [regrets for next week, but no objection]
vgb: no objections,
... will send another msg to the list. think re: that message...
nadalin: please look at two open pull req.
giri: may I create pull req for location?
there was proposal for a separate call to separate the non-normative work from the normative work
nadalin: go ahead.
... next week will be 90.
<nitin> scribenick: nitin
Rahul: When authenticator is called it chooses the factor
As part of Make credential and Get Assertion this information is important to relying party
Three potential solutions are provided
Tony: Vijay is leaning towards 3 UVI extension
Rahul: Agrees with the proposal
Giri: UVI is defined as opaque data. Should authentication be defined explicitly?.
Nitin: Authentication should be defined explicitly.
Giri: Google has soft combinations should try to future proof, may not cover everything
Rahul: That is the intention
Rolf: To provide a way to protect against friendly fraud. Each person might register different biometrics, to pass user verification.
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
Tony: Does it mean keep UVI as it is and create a new extension. This is option 2.
Giri: UVI is not fully defined. So it is opaque
Rolf: UVI should be written down so everyone understands the same way. Rolf will write it down.
JC: UVI as written is an opaque blob.
Rahul: If we keep UVM and UVI as two separate extensions then the RP will need to ask for two extensions.
Rolf: The RP can ask for two extensions and does not have to make two separate calls,
Vijay: UVI as written is an opaque blob. This minimizes the value to the RP.
Rahul: Presenting the UVI extension proposal. Add three more fields: User verification methods: Security protection type, matcher protection type, protection method.
Richard: The size should be small
Rahul: These are small size protections
Richard: Should be a different registry, Look at how many we need.
Nitin: May need to take into account combinations.
Richard: Make it a CBOR array if we want list of things
Rahul: Yes we can do that. Will make that change and send it out.
Giri: Qualcomm will support UVM as an extension
Rahul: Should be byte field or integer/short/short
Richard: Should be constrained
Tony: Is anyone opposed to making a new extension.(UVM)
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.
Vijay: Byte values for CBOR array.
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.
Rahul: Will send out the proposal
Tony: Concludes the discussion on this proposal. Giri’s proposal for location proposal.
Giri: Described the location proposal.
Richard: Core specification should be put to the front of the agenda
Vijay: Should be valuable to receive feedback
Rahul should also send out teh slides