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>
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
>
> ---------------------------------------
>