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

Hi Malcolm,
Did go through section 6 (Defined Attestation Formats) of the latest editor’s copy quite a bit and cannot find any info on user verification method or key/matcher protection type in the Packed or TPM attestation formats. The Android attestation format does have a userAuthentication field which is constrained to ‘none’, ‘keyguard’ and ‘fingerprint’, no key/matcher protection type info though.
Additionally the attestation data is only returned with makeCredential. For a multi-factor authenticator (i.e. single AAGUID with multiple factors with different security props) it would be necessary to know the factor that was actually used to service the getAssertion request which it seems is currently missing in the spec.
Again, the UVI extension seems to be the place for this data, just that the data format is not defined currently. So maybe this is just an exercise in defining the UVI extension’s data format to include the factor and protection type.

Rahul

From: Malcolm Young [mailto:malcolm.young@digital.gov.au]
Sent: Thursday, July 21, 2016 5:55 PM
To: W3C WebAuthn WG <public-webauthn@w3.org>
Subject: Re: returning a multi-factor authenticator's factor-in-use and protection scheme to the server

Hi Rahul,

Is what you're looking for not included in the attestation?

Malcolm Young

On Fri, Jul 22, 2016 at 10:33 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
---------------------------------------