RE: returning a multi-factor authenticator's factor-in-use and protection scheme to the server

Hi Rolf,
    Thanks for the info on the UVI extension’s history. The multiple finger use case is not quite apparent from the description text of that extension in the spec. The highlighted use case below would be an important one to support, especially given that some of the first and most common WebAuthn authenticators will be of this nature. I am open to a new extension altogether, like a UVM extension.  Having said that though it still looks like the UVI extension might be the best home for this data. As per the spec, the purpose of that extension is so it:
can be used by servers to understand whether an authentication was authorized by the exact same biometric data as the initial key generation. This allows the detection and prevention of "friendly fraud".
Using a different finger or a different biometric/user-verification-method altogether would both satisfy the above requirement. Can’t we add the factor and protection type data to this extension and have servers just query for one extension to detect a different finger or UVM being used?
I can send out a change proposal to the UVI extension if we are all ok with this approach.

Rahul

From: Rolf Lindemann [mailto:rlindemann@noknok.com]
Sent: Sunday, July 24, 2016 1:55 PM
To: Ghosh, Rahuldeva <rahuldeva.ghosh@intel.com>
Cc: W3C Web Authn WG <public-webauthn@w3.org>; Bakshi, Sanjay <sanjay.bakshi@intel.com>; Sarangdhar, Nitin V <nitin.v.sarangdhar@intel.com>
Subject: Re: returning a multi-factor authenticator's factor-in-use and protection scheme to the server


It is not the purpose of UVI to solve that.  The purpose of UVI is only to let tge server disambiguate different fingers (or other items of the same modality).
If one authenticator supports multiple user verification methods, the one that was used is not visible to the server (at this time).
If we want to support single authenticators supporting multiple user verification methods *and* want the server being able to distinguish them, we would have to add another extension for that, e.g. user verification method extension (UVM).

Note: several existing fingerprint based authenticators allow users to add fingers after entering an alternative password.  From a security perspective this is an alternative user verification method.  The lowest security level is relevant for the metadata statement and for potential security evaluations,

Kind regards,
   Rolf

On Jul 22, 2016 2:36 AM, "Ghosh, Rahuldeva" <rahuldeva.ghosh@intel.com<mailto:rahuldeva.ghosh@intel.com>> wrote:
Folks,
A bit late in the party but wondering if the following query has been discussed before or is covered in the WebAuthn spec already.
This is for the scenario where a single WebAuthn authenticator supports multiple user verification methods, each possibly with different security properties – e.g. pin verification without IO or TEE protection, and, fingerprint verification with IO and TEE protection. Such an authenticator will have multiple metadata statements for each userVerificationDetails-keyProtection-matcherProtection combo.
Given the difference in factor types and protection mechanisms Relying Parties will likely be interested in the user verification method and protection scheme that actually got used to execute a makeCredential() or getAssertion() request, especially for the latter. I can’t find a documented way in the current spec to get this information in either scopedCredentialInfo or webAuthnAssertion.
If this is not covered in the spec then it would be worth it to allow for the authenticator to provide this info to the RP, either in the core APIs themselves or in a published extension so RP’s webAuthn server can request for this data.
Seems like the UVI extension was meant to do this but as currently defined has no spec-ed format, so is not really of much use to the server.
Interested to see if others have an opinion on this.

Warm Regards,
Rahul

---------------------------------------
Rahul Ghosh
Senior Staff Architect
Platform Security Division
Intel Corporation
---------------------------------------