Safari's Touch ID / Face ID support and user activated event

664 views
Skip to first unread message

Yoshikazu Nojima

unread,
Jun 24, 2020, 11:27:04 PM6/24/20
to fido...@fidoalliance.org

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:

```
someElement.onclick = function(){
  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.
  });
}
```

Calling REST API before navigator.credentials.create.get invocation to fetch options parameters like challenge and credentialId(s) are common pattern in many sites (ex. google.com, webauthn.io), and this restriction is not desirable.

Is it defined behavior in WebAuthn specification that user agent must prohibits local authenticators not within user activated event?


--

YOSHIKAZU NOJIMA

Red Hat

8F, Ebisu Neonato, 4-1-18, Ebisu, Shibuya-ku

Tokyo, 150-0013, Japan

yno...@redhat.com     

TRIED. TESTED. TRUSTED.

Yoshikazu Nojima

unread,
Jun 25, 2020, 8:34:37 AM6/25/20
to fido...@fidoalliance.org
I filed a ticket in WebKit Bugzilla for this issue.

 

2020年6月25日(木) 12:26 Yoshikazu Nojima <yno...@redhat.com>:

Emil Lundberg

unread,
Jun 25, 2020, 9:06:49 AM6/25/20
to fido...@fidoalliance.org

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.

Emil Lundberg

Software Developer | Yubico


--
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.
signature.asc

Ackermann Yuriy

unread,
Jun 25, 2020, 9:30:42 AM6/25/20
to Emil Lundberg, fido...@fidoalliance.org
This maybe does not violate WebAuthn specs, but it does make WebAuthn API barely usable, lol

--
Yuriy Ackermann
FIDO, Identity, Standards
skype: ackermann.yuriy
github: @herrjemand
twitter: @herrjemand
medium: @herrjemand

Paul McNamara

unread,
Jun 26, 2020, 4:09:39 AM6/26/20
to FIDO Dev (fido-dev)
Yep - our implementation both does a fetch for the options and the get call is triggered on page load.

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?

Suby Raman

unread,
Jun 26, 2020, 3:19:55 PM6/26/20
to FIDO Dev (fido-dev), Paul McNamara
I think there in Apple's implementation there is a misunderstanding about the "user-activated" aspect of the WebAuthn ceremonies? User consent is guaranteed by the user interacting with an authenticator, not necessarily interacting with the browser/useragent in a particular way. 

Paul McNamara

unread,
Jun 26, 2020, 5:38:38 PM6/26/20
to FIDO Dev (fido-dev), mcnama...@gmail.com
I grabbed the beta of iOS 14 today and had a little play. I had to hack things about to remove our awaited fetch call from the mix (basically by pre-loading the credential create options) but got credential creation working. It does prompt for consent before launching Touch ID so I don't really see what the benefit of the in-browser user-activated behaviour is. It doesn't prevent nuisance popups as it'll still prompt for an external authenticator. 

Reply all
Reply to author
Forward
0 new messages