Hi @filips123, I think standardization of support for soft authenticators within the WebAuthn specification falls a bit outside the scope of the specification, but perhaps specifying some best practices for handling soft authenticators would be a good addition. Also, assuming additions like CaBLE support are adopted, users could potentially use their phone to handle authentication in a way that would be "standardized", since it would be written into the spec as an extension, and I'll mention another non-standard example I know about below.

The reason I think it is out of scope to standardize the API for soft authenticators is because we don't need to add anything to the credential creation/assertion options/responses that would need to be specific for software authenticators, and I, as a developer, wouldn't want the WebAuthn API to reach out to potential 3rd party authentication brokers/routers on my behalf. Take, for example, two different types of soft authenticators I know of that support WebAuthn and how they handle things:

SoftU2F: This library emulates a hardware U2F HID device and performs cryptographic operations using the OS X Keychain. We don't need to add anything to the API for this soft authenticator to work and it would be the onus of the RP to handle allowing/disallowing this type of auth method.

Krypton U2F Extension: This library defines an extension that can be used with Krypton's iOS or Android libraries to override the WebAuthn API request and send the credential request to a mobile device for authentication.

Both methods are different, and I don't see how the WebAuthn API can be amended to better support these software-defined authentication methods. What I would say is that we could probably address in the spec are best practices and security guidelines for soft authenticators, but this could also be an addition for the CTAP spec rather than the WebAuthn one.

From implementation perspective, on windows, platform has a software authenticator built in which is free. I beleive the same for Android. Plus phones can be used as authenticators on other platforms. So argument of having hardware and not being free is not correct.

I would close this issue with no action.

Which software authenticator is in Windows? Do you mean Windows Hello?

And which are available in Android, Linux, maxOS?

@filips123 I think @akshayku is referring to Windows Hello and PIN support (correct me if I'm wrong), which isn't universal yet to all Windows devices but is available.

Android has support in Android Chrome for WebAuthn/FIDO2 login, and you can also handle WebAuthn requests like in the Android Library Duo created.

On Linux I don't know of any software-defined authenticators, although you could use the Krypton library (or Android library) I mentioned above to accomplish WebAuthn authentication on a Linux machine.

On MacOS, you have the SoftU2F library I mentioned above, also support for TouchID in Chrome and hopefully soon there will be support built into Safari.

@nicksteele wrote:

I don't see how the WebAuthn API can be amended to better support these software-defined authentication methods. What I would say is that we could probably address in the spec are best practices and security guidelines for soft authenticators, but this could also be an addition for the CTAP spec rather than the WebAuthn one.

I'm thinking I agree with Nick and a more appropriate spec for such considerations is the CTAP spec, so would be fine with closing this issue. thanks for bringing it up @filips123

@akshayku @filips123 @nicksteele

I am not an expert so please correct me if I am wrong. As far as I know the FIDO2 Authenticators of Windows uses the TPM and Android uses Secure Element which is like TPM for mobile devices. I don't know if they support software only CTAP2 compatible authentication. They is desktop, laptop and mobile hardware out there without TPM and Secure Element.

I don't know where a purely software based public key authentication solution would be located best (WebAuthn, FIDO2, CTAP2 or a new protocol) but I would like to appreciate action towards it. While I am currently still trying to understand the mentioned techniques, I have the notion that purely software based public key authentication is much more flexible on backup and sharing of keys between systems and users and having fewer dependencies. Also I think about if privacy is weakend when a RP is able to see from which device a user is connected by distinguishing the keys resulting from using different hardware authenticators for/of different computing systems.

FWIW: https://github.com/herrjemand/awesome-webauthn#software-authenticators has a list of FIDO2 software authenticators, perhaps that can be of help.

CTAP does not define anything about the platform authenticators. Where is the best place for discussing about platform authenticators? Since we have cases where the platform authenticator might be unavailable on some platforms or devices, it's better to leverage software based platform authenticator in this case rather than not supporting WebAuthn on such environments.

@Kieun: CTAP defines transport specific bindings, of which there are currently 3 fido interfaces: USB, NFC, and BLE. if you want a software authenticator, emulate a USB device (e.g., umdf driver on windows) that implements the CTAPHID protocol.

On Linux, this can be done via /dev/uhid (https://www.kernel.org/doc/Documentation/hid/uhid.txt).

From the call of 2021-01-06:

We are considering what issues might be addressed in WebAuthn Level Three and feel that this is premature. While it might be the case that wide-spread use of software authenticators motivate some WebAuthn-level changes, WebAuthn itself doesn't define how authenticators are discovered. That's a platform concern. Since WebAuthn is a Web API, it's not the place to define other authenticator transports.

(For example, the transport for physical authenticators is defined by FIDO, a separate body from the W3C.)

As such, the group doesn't feel that it wants to take on non-Web work in L3.