- From: Shane Weeden via GitHub <sysbot+gh@w3.org>
- Date: Fri, 24 Dec 2021 00:26:36 +0000
- To: public-webauthn@w3.org
> They can, however, request a second device-specific, hardware bound key and ignore the passkey, if they have a use case that requires this (and results in a degradation of user experience). Can you really "ignore the passkey"? Shouldn't the RP during registration actually store both the passkey user credential, *and* the device-bound key, verifying the attestation of both, then on subsequent authentication flows request the device-bound key extension, verifying the authentication signature of the both the passkey public key and that in the extension, and make sure both the authenticating passkey credential is a property of the user's account, plus the credential in the extension is already associated with the user's passkey credential? That's how I understood the requirements of the extension to work, which is actually quite complicated for RPs to implement. As a related topic, what would happen if the credentialID of the device-bound credential observed in extension output during creation was used as a credentialID in the allowCredentials list of a subsequent authentication flow? I don't know of any currently defined behaviour for such a thing. -- GitHub Notification of comment by sbweeden Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1688#issuecomment-1000578251 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 24 December 2021 00:26:37 UTC