Hi folks,
You may have heard that Safari started Touch ID/Face ID support on their WebAuthn implementation in their beta release. That’s super exciting news. It promotes WebAuthn adoption.
https://developer.apple.com/videos/play/wwdc2020/10670/
But Safari restricts Touch ID/Face ID usage only within user activated events (Security keys are not restricted). If navigator.credentials.create or .get is not called within user activated events, only security keys are available for authentication.
It seems reasonable regulation at first glance, but it also restricts calling WebAuthn within a callback of promise based asynchronous API invoked within user activated event.
Here is a pseudo code that Touch ID/Face ID is not available for registration:
var optionsRequest = {
// set some parameters
};
fetch('http://example.com/webauthn/attestation/options', {
method: "POST",
body: JSON.stringify(optionsRequest)
})
.then(function(response) {
var options = generateOptionsFromServerResponse(response);
return navigator.credentials.create(options); // WebAuthn is not directly called by user activated event.
});
}Is it defined behavior in WebAuthn specification that user agent must prohibits local authenticators not within user activated event?
YOSHIKAZU NOJIMA
8F, Ebisu Neonato, 4-1-18, Ebisu, Shibuya-ku
Tokyo, 150-0013, Japan
![]() | TRIED. TESTED. TRUSTED. |
No, this restriction is not required by WebAuthn. In fact, something similar has previously been proposed and rejected: https://github.com/w3c/webauthn/issues/1293
That said, I don't think Apple is violating the spec by
implementing this additional restriction.
--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/CAD67rCiueQkJNpyKXuaBrp7i94XzxvQCHCCbEObRh%3DFcL%2BPOkg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/fd22ebcb-9388-b5ef-6c09-7621353c4b49%40yubico.com.
It must be possible for safari to preserve that context and know that a redirect or fetch continuation were originally triggered by a user interaction.
On a related note, does this support include resident keys?