- From: Emil Lundberg via GitHub <sysbot+gh@w3.org>
- Date: Fri, 19 Mar 2021 21:51:43 +0000
- To: public-webauthn@w3.org
Ok, thanks a lot for clarifying! I'm glad I was mistaken about that, then. So in that case, like you said, the whole procedure from photo capture to signing happens in the system-level service, which in the WebAuthn model would correspond to the authenticator layer. The system you describe clearly requires support from the operating system and hardware, and there would be no way for a standalone browser to implement the feature without that support from the platform. Therefore it seems to me like this would be most appropriate as an [authenticator extension](https://w3c.github.io/webauthn/#authenticator-extension), and doesn't need any changes to the client-level `navigator.credentials` API. Making it an authenticator extension also reinforces that the whole procedure takes place within the secure "authenticator boundary". This will also prevent injection and replay attacks as long as each request uses a unique [challenge](https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-challenge). However, it also seems to me like this is conflating user verification and data signing. The model for biometrics in WebAuthn has so far been that biometric data is never directly exposed to the RP - instead the authenticator simply reports back whether biometric verification was successful. The flow you describe instead sends biometric data back to the RP server. Is that necessary? If the RP can trust the authenticator (TEE), is it not enough for the authenticator to verify the facial scan locally and only report the result as the [UV flag](https://w3c.github.io/webauthn/#flags)? -- GitHub Notification of comment by emlun Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1580#issuecomment-803154427 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 19 March 2021 21:51:45 UTC