Whats the plan with caBLE

104 views
Skip to first unread message

Shane Weeden

unread,
May 4, 2022, 11:36:46 PMMay 4
to FIDO Dev (fido-dev)
I have been experimenting a little with recent Chrome and Safari support for caBLE as an authenticator transport. There are plenty of interesting edge cases and observations, but one that concerns me quite a bit is the different behaviours by each vendor under which it is offered as an option during credential registration, and some broken use cases.

For example, I understand that Chrome does not offer caBLE if a resident key (discoverable credential) is requested in options, with the assumption this is because Android doesn't support RK yet. Understandable.

Safari on the other hand does, and even says in the UI "iPhone, iPad, or Android device", even though currently an Android device will not support RK. Completing this flow using an Android device is successful though, and a credential is created. Is the requireResidentKey option not transmitted from Safari to the Android authenticator when using the caBLE transport?!

Next weird observation is what happens when authenticatorAttachment is provided in options. If it's not provided, both Safari and Chrome offer caBLE as a transport. 

When it is specified, the two browsers behave completely opposite to one another. Safari only offers caBLE if "platform" is specified, and Chrome only if "cross-platform" is specified. This divergence is discouraging. I'm not sure if the CTAP spec provides any guidance at this level of detail, but I really think it needs to if we plan to head toward open compatibility with caBLE as a transport and not just have Safari-requires-iOS-devices, and Chrome-requires-Android-devices.

I realise this is somewhat bleeding edge, but I feel there is too much bleeding differences, and not enough consistency even at this early stage of delivery.

Cheers,
Shane.

Christiaan Brand

unread,
May 6, 2022, 4:21:21 PMMay 6
to Shane Weeden, FIDO Dev (fido-dev)
Hi Shane,

Thanks for the feedback. I think it's pretty natural at the current juncture that there's some divergences in the implementations, but I'm hoping that towards the end of 2022 we'll start seeing more convergence.

 Is the requireResidentKey option not transmitted from Safari to the Android authenticator when using the caBLE transport?!
Android doesn't yet understand the RK bit and is probably just ignoring it. There should be some updates at Google IO on this next week :)

When it is specified, the two browsers behave completely opposite to one another. Safari only offers caBLE if "platform" is specified, and Chrome only if "cross-platform" is specified. This divergence is discouraging. I'm not sure if the CTAP spec provides any guidance at this level of detail, but I really think it needs to if we plan to head toward open compatibility with caBLE as a transport and not just have Safari-requires-iOS-devices, and Chrome-requires-Android-devices.
We've been discussing this a bit and I think we have consensus to standardize the behavior here. I'm not quite sure of the timelines, but I think the behaviour we're likely to see in the future is to offer caBLE on all platforms when attachment=cross-platform is specified (as well as when attachment is omitted). 

Happy to chat about this in more detail.

/christiaan

--
You received this message because you are subscribed to the Google Groups "FIDO Dev (fido-dev)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fido-dev+u...@fidoalliance.org.
To view this discussion on the web visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/f84a88da-9622-4a2f-b5dd-1bf8f9777d6bn%40fidoalliance.org.

Shane Weeden

unread,
May 6, 2022, 5:22:02 PMMay 6
to FIDO Dev (fido-dev), Christiaan Brand, FIDO Dev (fido-dev), Shane Weeden
Thanks Christiaan,

Supporting caBLE for cross-platform attachment makes sense to me as it's a natural fit to extend existing deployed "security key as a second factor" use cases, where many RPs today use [rk=false, uv=discouraged, authenticatorAttachment=cross-platform] as the WebAuthn adoption pattern for credential creation.

Standardised labelling of that feature and devices that have been used is another thing I would hope is being discussed. I notice on Chrome when using Android devices they are "remembered" and appear in the list of authenticator choices on that browser for subsequent authentication. When using my iPhone they are not, and I have to "Add an Android phone" for each authentication ceremony. I don't know if the device information used for that labelling is part of caBLE or not, but would really like to see consistent UX in that regard as well even if I had to type in a label myself as part of BLE pairing.

I also want to say thanks too for moving this forward. Whilst my observations in this thread highlight some initial rough edges, mobile-as-a-roaming-authenticator is very useful and has huge potential in terms of scaling FIDO in the consumer space, particularly when combined with multi-device credentials.

Regards,
Shane.

Alexander Jackson

unread,
May 7, 2022, 3:11:37 PMMay 7
to FIDO Dev (fido-dev), Shane Weeden, Christiaan Brand, FIDO Dev (fido-dev)

Stop all Think in 1 min
Reply all
Reply to author
Forward
0 new messages