- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Sun, 15 Oct 2017 14:00:14 +0000
- To: public-webauthn@w3.org
The U2F behaviour is overridden by the Webauthn spec, see [§4.1.3. Create a new credential, step 21][make]: >If `options.authenticatorSelection` is present, iterate through _currentlyAvailableAuthenticators_ and do the following for each authenticator: > 1. If `aa` is present and its value is not equal to _authenticator_’s attachment modality, _continue_. > 2. If `rk` is set to true and the _authenticator_ is not capable of storing a Client-Side-Resident Credential Private Key, _continue_. > 3. If `uv` is set to true and the _authenticator_ is not capable of performing user verification, _continue_. > 4. Append _authenticator_ to _selectedAuthenticators_. Thus requesting credential creation with `requireResidentKey: true` will make authenticator create a resident key, and the authenticator will also be able to use that key in response to an assertion request with no `allowCredentials` - i.e. the resulting key would be usable as a first factor credential. See [§4.1.4. Use an existing credential to make an assertion, step 16][get]: >Note: In this case, the Relying Party did not supply a list of acceptable credential descriptors. Thus the authenticator is being asked to exercise any credential it may possess that is bound to the Relying Party, as identified by _rpId_. Of course the credential will _also_ be usable as a second factor if the RP so wishes, but as I understand your need it's enough that the RP can be guaranteed that the credential will be usable as a first factor credential. Correct? [make]: https://www.w3.org/TR/webauthn/#createCredential [get]: https://www.w3.org/TR/webauthn/#getAssertion -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/640#issuecomment-336713454 using your GitHub account
Received on Sunday, 15 October 2017 14:00:02 UTC