W3C home > Mailing lists > Public > public-webauthn@w3.org > October 2017

Re: [webauthn] First factor authenticator selection

From: Ki-Eun Shin via GitHub <sysbot+gh@w3.org>
Date: Sun, 15 Oct 2017 13:10:14 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-336710577-1508072997-sysbot+gh@w3.org>
There is no such requirement that the second factor authenticator must not store user private keys. So if the RP sets requireResidentKey to **true**, some second factor authenticators **may not** reject the request.
You can refer following [U2F Spec](https://fidoalliance.org/specs/fido-u2f-v1.2-ps-20170411/fido-u2f-overview-v1.2-ps-20170411.html#allowing-for-inexpensive-u2f-devices).

> A U2F device allows for this. The Key Handle issued by the U2F device does not have to be an index to the private key stored on board the U2F device secure element chip. Instead, the Key Handle can 'store' (i.e., contain) the private key for the origin and the hash of the origin encrypted with a 'wrapping' key known only to the U2F device secure element. When the Key Handle goes back to the secure element it 'unwraps' it to 'retrieve' the private key and the origin that it was generated for.

Thus, the RP can only confirm the fact that the platform selects the 2nd factor authenticator when it sets _requireResidentKey_ to **false**. But, it cannot make sure that the selected authenticator is a first factor authenticator in case _requireResidentKey_ is **true**.

We need to clarify the way to allow only first factor authenticator registration for some RPs.

-- 
GitHub Notification of comment by Kieun
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/640#issuecomment-336710577 using your GitHub account
Received on Sunday, 15 October 2017 13:10:02 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 07:26:28 UTC