Re: [webauthn] Removing “lightning” from AuthenticatorTransport (#1294)

> So are you suggesting people that hesitate to upgrade to iOS 13 will have their Brave or whatever browsers updated such that the browser will understand a level 2 spec? Historically, iOS update rolls out very quickly over its user base. I really doubt the use case you mentioned lasts any longer.

All previous, current, and future announced versions of iOS do not support third party access to WebAuthn outside of the MFI transport. There are security considerations for generic WKWebView support (such as preventing javascript injection by a malicious parent process for requesting a token against another domain, effectively phishing the user), and applications which may want to use authenticators outside a web presentation/context.

For applications which wish to use MFI as the only current avenue to talk to authenticators, both in and outside a web context, knowing that the user has authenticators registered which support MFI usage is valuable from a user experience perspective.

If a future version of iOS provides WKWebView support and/or provides an app association like web credentials for direct app usage, the value of MFI-based authenticators does indeed become one of backward compatibility. 

We are not at backward compatibility yet. Today we are just at compatibility. It may be unfortunate that the name is 'lightning' vs 'mfi', but that is now a compatibility issue for real hardware being used in the wild.

> I don't understand why other security key vendors at this point would care this string anymore given WebKit, who ultimately controls the web experience over the devices that have a lightning port, won't make use of it at all.

Precisely because things which use webkit today, and future apps which do not depend on webkit (depending on Apple's feature releases) also cannot use the usb mode. In this sense, it is a transport being used exactly how it should be - to tell the relying party whether or not a registered credential is potentially available for use in the particular context. 

> I clearly see this transport hint could help in the use case you mentioned. However, the Level 2 spec is supposed to have improvement that either address some of the emerging issues or forecast future needs. It is NOT supposed to provide backward compatibility to something that does not even exist at Level 1. Having such term in the Level 2 spec is super confusing given the spec should be a guidance to the future development of WebAuthn.

Even if there was a commitment that the application needs being solved today via MFI would be solved by Apple at the platform level for USB/NFC/BLE keys at some point in the future - you will still have shipped authenticators that report a lightning transport, clients today that report that transport to the relying party, and relying parties that gain value today by having it reported.

Given that this transport value does and will appear in the wild, the question here is not whether it should be defined - but rather whether it should be defined in a standard by the W3C, a standard in the FIDO Alliance, or informationally by the vendors who ship keys leveraging it.

-- 
GitHub Notification of comment by dwaite
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1294#issuecomment-574974817 using your GitHub account

Received on Thursday, 16 January 2020 04:19:46 UTC