Removing “lightning” from AuthenticatorTransport

[alanwaketan]

In WebKit’s implementation, Lightning is treated the same as USB, see Bug 201084. Therefore, adding a “lightning” transport doesn’t seem to be useful. Also, since the spec doesn't differentiate USB C and USB A, there isn’t a good reason for calling out Lightning.

[agl]

The transport values are recorded by the site during registration and echoed back the browser when an assertion is requested. They are intended to guide the browser about hopeless cases, for example a credential with “internal” transport when the browser knows that it doesn't have any internal authenticators.

The “lightning” transport is intended for the same reason. Many authenticators support “usb” but USB HID devices cannot be used by iOS apps, even assuming that the user has some dongle that takes care of the physical connection. (Unless you want to update our understanding on that point.)

USB-A and USB-C are merged into a single transport because, in practice, converters between the two are common and widely used. Thus it would be excessive to drop a credential just because a laptop only has USB-C, but the authenticator reports that it's USB-A.

[ve7jtb]

in an ideal world any Fido key would work with any iOS app via HID and a simple lightning to USB-A adaptor like the cámara connector kit. Currently that isn't the case on iOS 13 and older. The lightning hint helps RP know if a previously registers credential is from A Apple certified MFi lightning device that can work with Brave , Dashlane and others on iOS. I am encouraged that from the Safari point of view lightning is just like USB and will be using the HID endpoint. The Yubikey 5Ci will work just fine that way. We should discuss this at the W3C meeting in Japan coming up shortly.

[alanwaketan]

The transport values, in my opinion, is only useful to reduce the burden of a user agent to search a credential over multiple transports if the credential can only be reached via a limited number of transports that is lower than the maximum number of transports the user agent supports.

Given most of the user agents will not be able to communicate via the Lightning port, I don't see the value of having it in the AuthenticatorTransport enum. It might be useful if a credential can be searched via Lightning only but not USB, then it could help user agents that don't support Lightning to either skip searching or removing it from the allow list. However, I don't see this as a trend.

Also, WebKit has landed support for NFC authenticators on iOS, see Bug 188624. Comparing to Lightning dongles, NFC dongles, in my opinion, will be more common to be used with iPhones in the future.

[Kieun]

@alanwaketan I'm not sure that this the right place to mention this. By the way, do you have any plan to provide the platform authenticator leveraging Touch Id or Face Id for Webkit? I think most of folks are interested in the platform authenticator for iOS and macOS.

[alanwaketan]

@Kieun I don't think this is the right place. Could you reach me via jiewen_tan@apple.com? We should discuss it offline.

[ve7jtb]

I am loading 13.2 on my test phone now. When you say landed what release will that show up in?

I believe the goal is to not prompt the user to tap if there are no NFC credentials and not prompt to plugin if there are no USB credentials.

I think the idea is that for something like brave on iOS the goal is to only prompt the user to insert a key if they have one or more credentials marked as lightning.

I don't personally think most RP are going to collect the transports and send the hints. However I do know of atleast one that is doing that.

If standard usb-c keys can work with iPad pros and with an adaptor on lightning devices then the hint has less value.

Right now I don't think that it hurts anything. The YK 5Ci identified as both USB and lightning.

I would like to understand why you think it is a problem, or do you just think it is unneccicary for Safari?

It should be noted that in WebAuthn level 2 this string is also used in CTAP to report the transports to the platform and from the platform to the RP. This allows the RP to get the transport hints without a attestation. . So it touches a couple of places.

I know some people really wanted it listed as a separate transport. There was also talk of listing the External Accessory framework separately as a transport. We decided to go with one hint that implies both the phisical and logical connection.

Again I hope that atleast for new versions of iOS it may become irelivent once the HID interface is available, or iOS provides a API like windows and Android for native apps (best solution in my opinion). John B.

[dwaite]

in an ideal world any Fido key would work with any iOS app via HID and a simple lightning to USB-A adaptor like the cámara connector kit.

Of course, there are several platforms already which go beyond this and abstract the interface for communicating with CTAP endpoints - both for security reasons as well as to expose any platform authenticators. Examples would include Windows Hello and the Fido2ApiClient class in Android.

On these platforms, a typical app would only have an entitlement to request credentials for web domains that the app can 'prove' it is associated with. On an Apple platform for example, one might expect this to be done via a mechanism like the .well-known/apple-app-site-association resource.

On platforms which expose such APIs, there also is usually an entitlement for apps which require the ability to request credentials against all domains (such as web browsers)

The reason I point this out here is that such platforms may not consider alternative transports to be under the same API or be restricted the same way in use. An authenticator using MFi IAP for instance already has a mechanism in case where the vendor restricts which apps have access to the accessory. Even in the presence of platform support which would never use the "lightning" transport, advertising availability of such a transport may still provide value.

[alanwaketan]

@ve7jtb What I mean HID in the implementation means USB-HID.

As for Brave or other WebKit clients, they will probably switch to our implementation once it is available for them.

[ve7jtb]

When you say USB HID I am assuming that is over both lightning and USB-C for iOS depending on device. That is what I have been hoping. Any timeframe on availability and how far back it would be supported? As an example will iOS 12 support it for older iPhone 6 etc, or will Brave and Google still need there own stacks to talk to authenticators.
Yubico has a SDK now that enterprises are intigrating with to support the 5Ci on iOS. The sooner we could get people on to Webkit the better.

Are you coming to TPAC?

John B.

[othermaciej]

USB-A and USB-C are merged into a single transport because, in practice, converters between the two are common and widely used. Thus it would be excessive to drop a credential just because a laptop only has USB-C, but the authenticator reports that it's USB-A.

So assuming iOS WebKit's support for USB authenticators via lightning also worked through USB-C and USB-A dongles, would it make sense to merge it into the generic "usb" transport?

[agl]

So assuming iOS WebKit's support for USB authenticators via lightning also worked through USB-C and USB-A dongles, would it make sense to merge it into the generic "usb" transport?

The transports are purely to enable smarter client-side behaviours, so I don't believe that having an enumeration for Lightning hurts anything. If it's truly useless, then clients will simple end up ignoring it.

Here's an example of where it might be useful, even in a world where iOS works with USB authenticators attached via a dongle: If an iOS client receives a GetAssertion that has a credential with transports {USB, NFC} then, on an iPhone, guiding the user to use NFC is probably the way to go because Lighting↔USB dongles aren't that common. However, if the transports where {USB, NFC, Lightning} then the client would probably be better off suggesting to use the Lightning connector.

[alanwaketan]

@agl To me, it seems Lighting↔USB is more common than YubiKey 5Ci. https://www.amazon.com/s?k=lightning+to+usb+adapter&crid=3TE8GERL9YKRO&sprefix=lighting+to+usb%2Caps%2C191&ref=nb_sb_ss_sc_3_15

[agl]

To me, it seems Lighting↔USB is more common than YubiKey 5Ci

While that's probably true, I think the pertinent comparison would be the prevalence of USB-A and USB-C interchange. Also, as noted, I don't think it hurts anything to have this information and don't understand the motive to remove it.

[othermaciej]

We want to say "usb" anywhere we'd say "lightning" because to us lightning is just another funny flavor of USB connector, like USB-A, USB-C and micro-USB. If we do that but the spec includes "lightning", that will confuse people. There is an argument that separating lightning will lead to a better use experience, but we, who are ultimately in charge of the user experience on the only devices with a native lightning connector, do not think so.

If the argument is maximum information, then "usb-a" and "usb-c" should be separate. The response was that those are folded together because they are widely cross-adaptable, so it hurts more than it helps to treat them as different. We feel the same way about lightning, and we believe lightning and other flavors of USB are also widely cross-adaptable. The counter argument is that maybe lightning adapters are not as common. Is there some objective threshold of adapter availability that we could use as the dividing line?

[emlun]

we, who are ultimately in charge of the user experience on the only devices with a native lightning connector, do not think so

I'm not favouring either side of the argument here, but this is arguably more about the user experience on devices that do not have a lightning connector than on devices that do.

[dwaite]

The "lightning" transport as spelled today can be interpreted three ways:

1. That the authenticator has a physical lightning male connector. This would be different from the USB transport, which is connector-agnostic.
2. That the authenticator speaks a CTAP2-over-MFi protocol. This could be via an alternate connector (such as USB-C) or even hypothetically over bluetooth.
3. Yubikey's specific hardware implementation of CTAP2-over-MFi

I believe @alanwaketan 's argument would be that WebKit/Safari don't see the value in advertising the first interpretation, nor would they support the second one.

There's an argument to be made that third party browsers may wish to advertise they support the second interpretation, as they may not be able to support USB as a transport. It is worth directly asking @alanwaketan and @othermaciej whether a third party browser could be expected to be capable of supporting USB transport around the timeline if/when WebKit supports it - but these browsers are shipping today, and the "lightning" transport is providing a flag to RPs to which credentials could work on iOS/iPadOS hardware.

There's also an argument to be made that the third interpretation is correct, and there never should have been a generic transport name. Access for an app to a MFi device is granted not based on protocol but on device vendor. It is certainly possible an enterprise app might have access to talk to Yubico keys over MFi, but not access to talk to a hypothetical Project Titan key.

[ve7jtb]

The problem is to this point applications like Brave or smartlock can't access CTAP2 over regular HID. Applications currently need to use CTAP2 over a MFi encapsulated transport using an apple lightning security chip as part of the authenticator.

I hope that is not required going forward so that a standard key can be used with an adaptor.

The push back we get comes from some applications that don't want to prompt the user to insert a key if it cant work. Those applications want a transports flag to indicate that a credentialID could possibly work.

On iOS 13.1 or whenever WebAuthn support becomes available Applications should all use system API for invoking WebAuthn and not be talking to the lightning device directly as an accessory.

The applications running on iPhone 6 etc that won't be getting iOS 13 + are really the ones at issue.and the ones that will find the hint useful.

We had a number of discussions about what to call it. MFi tunnel support, lightning, tuna etc

I am open to calling the flag for credentials that could work in apps on iOS12 something else to reduce potential confusion. (My preferred option was tuna)

I really do hate having to specially flag things that work over lightning and USB-C on iOS 12.

I hope we can come to a conclusion next week in Japan.

[othermaciej]

If "lightning" is actually supposed to mean specifically the CTAP2 over MFi thing, then probably the name should be changed, as that is not how we intend to implement native WebAuthn support in iOS WebKit; in our approach, we believe lightning will be as cross-adaptable as USB-C.

(Also does it really make sense to have a hint solely for a finite transition period?)

[ve7jtb]

The name is just a string as long as what it means is clear it could be anything. I think I did suggest a fish name to Jeff H. at one point to avoid potential controversy.

All the Yubico 5Ci keys with USB-C support standard HID transport over USB on both connectors. Due to the complexities of MFi they only support the encapsulated transport on lightning and not USB-C though people are asking for that to support iPAD Pro.

On the assumption that you are making CTAP2 work over USB for regular keys, the iPad Pro situation should sort itself out in a timely enough manner that we don't need to expose CTAP2-MFi over USB-C.

We had a request from someone currently doing U2F on iOS to have two transports one for the phisical lighning connector and one for encapsulated CTAP2-MFi. Given we hope to only do encapsulated CTAP2-MFi on litening I talked them back to one hint.

I don't care what it is called there are a handfull of apps and a handfull of RP that use the transport hints. (Mostly Google to smartlock to exclude non BLE at the moment)

I totally agree that you shouldn't do the CTAP2 over MFi thing. That would be clearly wrong, but it is something that can work for existing Pre iPhone 7 devices.

If we pick a name to change it to then we can debate more interesting things in Japan. I would be good with MFi , EAF (External Accessory Framework https://developer.apple.com/documentation/externalaccessory ) or just tuna because it is just a string.

I am happy to add any appropriate words about this being for backwards compatibility for older phones and only applying pre iOS13?

In reality, no RP should ever filter on the transports. It is a hint for the user agent.
That is my biggest problem with the transport hints is that RP may be tempted to do stupid things based on them.

By the way, when is Safari on iOS going to be wired up to all this goodness? I still didn't see anything in yesterdays iOS 13.1 dev beta. I know forward-looking things probably can't be commented on, but knowing some timing would help, now that we know that CTAP2 will be supported over USB-C and lightning using the normal HID transport.

Will you be at TPAC?

Regards

[christiaanbrand]

Wow. Great discussion. So, from the person who requested that Lightning got added in the first place as a transport, some more context.

Of course, Maciej and Jiewen are 100% correct. If any old USB FIDO token could be plugged in to a USB->Lightning converter (given that such a thing exists ) there would not be the need for the "Lightning" transport. This was simply to be used as a way to signal that the "CTAP_over_MFi" transport was available for this particular credential before we had clear indication from Apple that they would be supporting HID outright.

My mini-rant for the day was going to be about how useful it is for companies to communicate their intent early: it can save the community a lot of time. But, alas, I'll save that for another day.

For now, it seems like we're halfway through this thing already, so here's my recommendation: If vendors ship a device that does special "CTAP tunneling over MFi", go ahead and set the Lightning transport. I don't really expect many devices going forward to do this, because there wouldn't be much point: any USB HID device should work directly with iOS.

User-agents who don't understand (or implement) this tunneling, just ignore the bit. Maybe in the future we can completely remove it from the spec, but I don't know that right now is that time since vendors literally started shipping these things (on our recommendation) weeks ago.

Then, the million dollar question to Maciej and Jiewen: When will we actually start seeing this support show up in iOS?

Thanks! Christiaan

[ve7jtb]

Thanks for replying Christiann.

Hopfully the market for authenticators that support CTAP over MFi/EAF remains small and goes away completly over a small number of years.

As the person to blame for picking the name lightning, I am also not supper attached to it.
It is bit 6 in the U2F transports byte so the string in the CTAP spec could be anything to describe it.

Changing the name in WebAuthn transports also would not be a huge deal.
Some keys in GetInfo would report lightning as a transport but that can be ignored by browsers or not.

If we want a diffrent name picking a diffrent name sooner than later would be optimal to make that change.

The 5Ci support CTAP over HID on lightning and USB so that is where we want to focus ASAP.

John B.

[ve7jtb]

PS I think in principal a camera connector kit could work as an adaptor for a standard key. However there is no real way to test that currently. I think for iOS Apple could make that work for Safari if they wanted to.

[alanwaketan]

@ve7jtb @christiaanbrand If we have STP on iOS, we could just ask you to try it out now. Unfortunately, we don't. So we can't really comment on future releases.

We understand some vendors have already implemented the "lightning" port and we don't have any objection to ignore it while have them keep it in their own way.

One thing we want to point out is Level 2 is still a working draft and therefore keeping a foreseeable short lived term is not compelling. The term is very likely to be obsoleted before Level 2 makes itself to recommendation.

[equalsJeffH]

One thing we want to point out is Level 2 is still a working draft and therefore keeping a foreseeable short lived term is not compelling. The term is very likely to be obsoleted before Level 2 makes itself to recommendation.

That would seem to mean that there's a window here where we can keep iLightning in the spec for now and remove it before REC if the world markedly changes before then?

[jcjones]

... But then why would anyone implement it? Particularly, what would an RP who coded for that purpose get from the subsequent removal?

[equalsJeffH]

@jcjones -- yeah, good point, nevermind....

[ though, at the 20-Sep-2019 TPAC WebAuthn F2F meeting, we decided to keep it in the spec for the forseeable future, see https://github.com/w3c/webauthn/issues/1294#issuecomment-537720952 ]

[equalsJeffH]

From the 20-Sep-2019 TPAC WebAuthn F2F meeting (minutes):

From google point of view, we do need it. we don't care what it is called. We agree we should revisit when world is in different state. and we can think about UX.

Ricky: sounds good

Tony: I will move this over to the CR milestone. [ i.e., keep open for now, and keep spec as-is. ]

NOTE: Tony (@nadalin) actually assigned it to the L2-WD-02 milestone.

[alanwaketan]

We agreed to hold this issue and revisit it again once we have shipped our implementation on iOS as mentioned in the 20-Sep-2019 TPAC WebAuthn F2F meeting.

[agl]

From call of 2020-01-08: probably this can move forward now, but could Apple / Yubico comment either way?

[othermaciej]

We've shipped an implementation with external authenticator support on iOS. It properly supports USB authenticators through the lightning port on devices that have it, with ordinary adapters. We consider USB-A, USB-C and lightning to be equivalent and interchangeable, even though in some cases adapters are needed. Thus, Apple thinks it's appropriate to remove "lightning" from the list of transports.

[nadalin]

@othermaciej Thank you for the update

[ve7jtb]

A bit of an update.

Apple has shipped support for CTAP2 in Safari. That support includes using standard keys in a USB port on ipad pros and via a camera connector kit on iOS (note that the adaptor cost is similar to the cost of a key, and it is a bit awkward do I doubt many people will do this in practice)

The remaining issue is that native apps like Brave and other native apps must use SFAuthenticationSession or SFSafariViewController depending on if they want access to cookies.

This is also only available on iOS 13 so older phones currently have no support other than having the application using a SDK to talk to a key over "CTAP_over_MFi" transport.

I agree with Apple that the best way for most apps to integrate with WebAuthn is via SFAuthenticationSession however for browsers and other native apps on iOS 13 they are probably going to use a SDK to talk NFC directly and use the "CTAP_over_MFi" transport for lightning connected keys. For iOS 12 and older devices "CTAP_over_MFi" transport seems to still be the only option.

Leaving the transport hint as "lightning" or changing it to "CTAP_over_MFi" or something else seem like the best options. The reason for the hint has not disappeared.

[christiaanbrand]

At this point I won't argue for this hint any further. I still think it's somewhat better to have it than not (for the reasons John mentioned), but I'm fine either way.

[othermaciej]

We've initially only exposed WebAuthN in Safari and high-level web view APIS (SFAS and SFSVC), but we're also looking into exposing it to direct WKWebView clients.

II think a hint that exists only for SDKs for native apps shouldn't be exposed to the web.

[ve7jtb]

I will leave it to brave and other browsers to comment on if WKWebView would work for them. That would, however, cover most of the other use-cases other than iOS backwards compatibility.

I would be OK with taking it out of WebAuthn and keeping it in CTAP for the SDK use case but the transport hints in CTAP are referenced from WebAuthn.

WebAuthn now has RP accepting unknown values and platforms ignoring unknown values, rather than throwing errors. The existing keys are going to continue to include the lighting string in transports. The spec should allow that not to be an error.

I guess we could add a note to CTAP 2.1 that the lightning transport string is not in the WebAuthn AuthenticatorTransport but SDK may use the transport string lightning to indicate that a credential may be available via "CTAP_over_MFi"

We can remove the hint from MFi certified keys going forward if Google and others aren't going to use it, but we would like to avoid the existing lightning keys with the transports hint causing platforms to throw errors and break.

[ve7jtb]

Looking back on the issue.

To be clear we are talking about "CTAP_over_MFi" not a physical lightning connector, though they typically go together. To produce a non-bootleg lightning key you need lightning connectors and chips from Apple and be MFi certified. Anyone doing that is probably going to support "CTAP_over_MFi" and CTAP over HID (Our normal interface for USB) over the physical lightning connector.

Safari doesn't produce the transport hints it is the authenticator that provides them.
I cant see any reason why Safari would care about the lightning hint as it can use the HID encapsulation to any key. It would only look at the usb hint and ignore "lightning" or whatever it is called.

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.

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.

[alanwaketan]

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.

[dwaite]

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.

[othermaciej]

For the non-web use case, it may be useful to define it at the protocol level but it doesn't make sense to standardize it at the web API level. For the purpose of web-facing APIs, the compat story should be that any token that reports "lightning" should be coalesced with USB.

For the WebKit client use case, our hope is to allow access at least as permissive as what clients can do with MFI, since we won't prevent any auth token phishing by making clients do the feature themselves. We cannot yet give a commitment or a timetable, so we could return to this question at that time. But in the meantime, the presence of the "lightning" value in the spec creates confusion.

[dwaite]

But in the meantime, the presence of the "lightning" value in the spec creates confusion.

The "lightning" value is in the wild. I do not believe merely removing the line from the spec would compel other clients to stop publishing the value, or compel relying parties to stop relying on the value. I hope the need for it goes to zero over time, but I suspect other browsers will continue sharing "lightning" as a transport for these particular keys even past that point.

As I understand it, the point in question to resolve is whether there is more confusion by having "lightning" as part of a master list of known production transports in this specification, or to have developers search other sources not maintained by the W3C when they encounter it.

[ve7jtb]

Unfortunately, not all iPhones/iPads are updatable to iOS 13. (I admit that Apple is much better at updating old devices than other manufacturers. ) That problem will become less over time.

The other are 3rd party browsers like Brave that may expose WebAuthn level 2 to the RP but need to use a MFi API to talk to a key until some future version of iOS that exposes a WebAuthn API for browsers like Google has on Android that is being used by FireFox and others.

The reason lightning wound up in the WebAuthn spec has to do with the relationship between the CTAP2 spec and WebAuthn. In CTAP2 all of the transport strings are referenced from the WebAuthn specs.

I have the feeling that separate from this we may not have sufficient advice for RP on what to do with transport hints.

RP should not be filtering on them they are just to help the platform. The RP sends the entire list that they received for the credential when it was created (via extracting from meta-data or via the new API, most won't bother to send it) .

Once the browser receives the allow list Safari would extract the credentials with no hint, usb, and NFC (on iOS). Brave would extract the credentials with no-hint, lightning and NFC (on iOS).

If all the credentials are NFC then the browser would just prompt to tap. If there are credentials that would work over the wired port then they would be prompted to plug in the authenticator.

Brave or other non Safari browsers will only work with MFi wired authenticators pre iOS 13 and MFi and NFC on iOS 13+

How the transport hints are processed is determined by the platform/browser.

Google has been filtering non BLE credentials from even being sent to Smartlock because it has prior to this week only supported BLE (some new platform authenticator functionality just got added.but I haven't explored that yet) . Google should not be the example on this.

I would say RP filtering credentials in allow lists is not something that is not going to end well, and should not be encouraged.

So I am getting the feeling the direction is to remove the "lightning" hint form WebAuthn level 2 and add it to CTAP2 and Fido meta-data in some way in addition to referencing the strings in WebAuthn.

Do we need more clarification on what RP should and should not be doing with the transport hints?

[equalsJeffH]

on 2020-01-22 call, we are not 100% sure of jbradley (@ve7jtb)'s reason to keep the "lightning" transport enum item in the webauthn spec. regardless, browsers represented do not feel like it is necessary and are willing to remove it from the spec.