- From: John Bradley via GitHub <sysbot+gh@w3.org>
- Date: Thu, 16 Jan 2020 14:15:13 +0000
- To: public-webauthn@w3.org
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? -- GitHub Notification of comment by ve7jtb Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1294#issuecomment-575170175 using your GitHub account
Received on Thursday, 16 January 2020 14:15:15 UTC