- From: Adam Langley via GitHub <sysbot+gh@w3.org>
- Date: Mon, 05 Jul 2021 20:33:36 +0000
- To: public-webauthn@w3.org
> When we prompt for assertion with an allow list and if credentials are not there, Browsers fall back to the default screen with the security key option. You can set the [transports](https://www.w3.org/TR/webauthn-2/#dom-publickeycredentialdescriptor-transports) member of the credentials to “internal” to tell the browser that the credentials cannot come from an external security key. It'll still show a dialog and wait for the user to close, but it shouldn't offer a external option that'll never work. > While the combination of persistent cookies and canceled assertions works as a workaround in most cases, I am wondering if we could get first-class support for such use cases. If not a status API, what are our options? The autofill integration is the current proposal for this. > In my case I know who the user is, I even have some possible credentials. I just want to be sure that credential exists before/during assertion. If you know who the user is, then you have state (e.g. cookies). If you have such state then you can record whether the user signed in with WebAuthn initially. If so, then you should request an assertion and pass all the credential IDs for that user. It's _possible_ that they deleted the applicable credential since signing in, but that seems like a very narrow case. If you're doing a sign-in from fresh state then the autocomplete proposal says that you'll be able to mark a text field as suitable for WebAuthn autocomplete and the assertion request will request a promise that will only be resolved if the user selects a WebAuthn credential to use. -- GitHub Notification of comment by agl Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1639#issuecomment-874317794 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 5 July 2021 20:33:38 UTC