W3C home > Mailing lists > Public > public-webauthn@w3.org > January 2020

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

From: Jiewen Tan via GitHub <sysbot+gh@w3.org>
Date: Thu, 16 Jan 2020 02:07:02 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-574946880-1579140421-sysbot+gh@w3.org>
> Other browsers currently working on iOS 12 cant talk CTAP over the normal HID transport as tat is blocked by the OS. Only if they receive a transport hint that tells them that the credential was created on an authenticator that can talk "CTAP_over_MFi" is it worth prompting the user to connect there authenticator.
> 
> For someone like Brave who is using WebAuthn this may improve the user experience.
> I think Google asked for it for similar reasons, with slartlock on iOS 12 it only makes sense to try the credentials that support BLE or "CTAP_over_MFi"
> 
> So removing the hint entirely will potentially have negative UI impacts on some WebAuthn clients and other applications doing CTAP2. It will still work but perhaps not as nicely.
> The hint has no relevance to Safari and should be ignored if received.

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.
 
> We can change the string to anything. We could change it to "yubicoMFi" for backwards MFi compatibility with pre iOS 13 devices. Though then when other vendors do the same thing they would want to make a new string, I would prefer the string to be a bit generic, so that others can use it if we change the name.

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.

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.

-- 
GitHub Notification of comment by alanwaketan
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1294#issuecomment-574946880 using your GitHub account
Received on Thursday, 16 January 2020 02:07:04 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:38:37 UTC