Making PublicKeyCredentialDescriptor.transports mandatory

[arshadnoor]

When John Doe registers a new key with an RP, using a platform authenticator on a computing device, his newly generated private key is bound to that platform authenticator on that computing device. Clearly, when he attempts to authenticate to the RP site from another computing device, he is not going to succeed.

The transports member of PublicKeyCredentialDescriptor, has the ability to signal the RP that the registered key was generated from an internal authenticator (as opposed to one using transport protocols of external authenticators, namely: usb, nfc or ble).

Since transports is currently OPTIONAL, it prevents the RP from properly signaling John Doe in the use-case defined above: that, in order to authenticate with his FIDO key to the RP site, he must use the original computing device - or use an alternate method to login into the RP's site.

Secondly, if the RP knew that John Doe has a second registered credential, whose transports identified one of usb, nfc or ble, it would also allow the RP to suggest he use that external authenticator to login to the RP site. But since transports is currently optional, this information is not consistently available to the RP.

It is recommended to make transports mandatory, have RPs store them on the FIDO server, and use that information within their applications to present messages that provide a better user experience.

[jonathan-Mastercard]

It is indeed confusing for a user to get a message inviting to insert a security key when they never used one (and may not even know what that means)

[agl]

From the call of 2021-01-06, the group doesn't believe that a change should be made here.

Browsers do not always know the transports supported by an authenticator. Making the transports field mandatory would only cause them to either have to fail such requests or to make something up. It's already the case that browsers pass on the information that they do have and changing the spec doesn't look like it it would result in RPs getting any more (accurate) data. There could be specific issues with some browsers but those are more usefully considered as browser bugs.

Also, RPs would still need to handle the case where the transports parameter was not provided because L1 clients would still be able to omit it.

So, while we agree that browsers should always pass on transports information when available, we don't think that making the field mandatory in the IDL would further that goal.

[timcappalli]

2023-09-12: it is not always possible for the client to access information to derive transports.