Re: [webauthn] Add new isPasskeyPlatformAuthenticatorAvailable() method (#1901)

If we step back from the name discussion slightly, what are we trying to help the RP decide?

1) can the browser/platform the user is currently on make a credential that will work in my loginflow?
   This is tricky because there is more than one type of login flow.  Some require discoverable credentials.  
Others may require UV but we can probably safely assume that most authenticators capable of discoverable credentials are also capable of UV even if they prefer not to do it by default.

2) If a user has registered a credential should they provide conditional mediation or a login with passkey button.
I suspect that conditional mediation should be done on any browser that supports it every time.   
For the login with passkey button that is tricky before knowing who the user is and if they have credentials registered.

Without knowing the user what info is actually useful to a RP? 
Are there any browser/platforms that support WebAuthn but don't have a useful CAP2/platform authenticator option?

1) Windows 
     Win 11 is all good all browsers that I know of support platform and CTAP2 roaming authenticators.  All browsers other than Fire Fox support Hybrid.
     Win 10 other than some early releases the story is the same as win 11
     Win 7 and early Wun 10 support external authenticators and Hybrid on Chrome (and Edge if installed).  Fire Fox supports  CTAP2.

On Windows the combination of isUVPAA, conditional Mediation and FF CTAP2 support flag probably tells the RP everything useful.

2) Android 
    Support for platform credentials is there, but CTAP2 support is still being developed. It also doesn't support Hybrid out to another device like an iPhone.  So despite being a bit broken I think RP would want to show the passley login option on Android

3) iOS /iPadOS Safari and the other browsers use the built in API and support everything including Hybrid out.  So Gold star for most consistent platform, if only it could set a pin:)

4) MacOS Safari is all good, Chrome is all good (will improve with native UVPAA), Firefox has CTAP2 but no Hybrid or UVPAA until integrating with Apple's API.
So no reason for RP to block anything with the possible exception FF for the moment.

5) Linux. Chrome and FF have CTAP2 support and Chrome has Hybrid.  UVPAA is being developed by some people but your guess is as good as mine.   

So most browser/platforms shouldn't be blocked.  
Which ones do RP not want to use and why?  
Can those be identified by existing mechanisms?

I have the feeling that other than with Linux these are all short term problems. 

An indication that Hybrid is supported might be useful but can be determined with a bit of logic by the RP.

The thing with Hybrid is that you can't know if the user has another device, so it is at best a hint.
There are no browser platforms that don't support some sort of discoverable credential.

Lets agree on the property we are trying to identify with this.   

Is it that the Hybrid transport is possible, or that one of UVPAA or Hybrid is possible?

I think at this point the discoverable or not question is probably not useful as everything will reply yes.

Once we all agree on the property and that it is useful and not just creating more confusion then we can pick a name.

John B.
I might go with something like isUVPAA+ to show that there is a possibility of UVPAA but that it may be on a different physical device, and move to deprecate isUVPAA over time.



-- 
GitHub Notification of comment by ve7jtb
Please view or discuss this issue at https://github.com/w3c/webauthn/pull/1901#issuecomment-1586267162 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 11 June 2023 18:05:51 UTC