Could we return the UAF assertion in an extension that is included in a well-formed FIDO2 signature assertion?

From call of 2019-06-05:

Rolf clarified that registration would be handled out-of-band.

I, for Chrome, said that arbitrary Authenticator Data would be very problematic. Akshay, I think, said something similar. I suggested putting the necessary information in an extension and having the RP reconstruct the signed message from that.

There was worry about this being a channel for arbitrary data though the browser. Several such channels already exist, but people aren't thrilled about adding more.

J. C. queries how a reader of the spec would be able to figure out the necessary supporting documents to be able to use this. (I.e. the UAF specs.)

John asks about UAF extensions themselves, which currently aren't defined for WebAuthn and so couldn't be passed in.

Mike notes that no UAF authenticators work with WebAuthn today, so new code will be needed. But if a change is needed why not make these authenticators real CTAP2 devices? Rolf asserts that parts of this ecosystem are pretty hard to change, but adding an interop layer would be much easier.

John, J. C., and Mike ask about the number of devices that would partake in order to judge the value.

My more basic question is who really needs this?
The use case seems to be for phones that have UAF authenticators in ROE that someone wants to wrap a BLE transport around so the phone can be a CTAP2 authenticator for a desktop.

As I understand it all Android phones 7+ have Webauthn platform authenticators now and Google is in the process of adding CTAP over BLE and caBLE so that they can be remote authenticators. So current Android phones don't really seem to fit this description.

On iOS apple may take a bit longer to roll out their platform authenticator, so this might be a target. However, all Fido authenticators on iOS are in software not in a ROE other than using the keychain. Those could just as easily be updated to Fido2 native authenticators rather than doing this wrapping.

I am left to conclude that we are talking about a small number of phones that may have UAF built in perhaps on Samsung? But those would have to be pre android 7. Anything later and the android platform is going to be doing Fido over BLE. I don't even know if a non core OS app could also do Fido over BLE at the same time without breaking things.

This seems a lot of work for potentially a small to non-existent number of devices.

Can someone point to a real example of a phone that would do this?
If not it seems a lot of work for a hypothetical problem.

John B.

Thinking more about this, may be upgrading such implementations to do CTAP2 is more achievable. Changing webauthn and faking the authdata, passing info via an extension, does not seems right.

No update today, so I untied it from milestone L2-WD-02

As per 3/3/21 Meeting: This pull request would need to be heavily updated to include further explanation of what's being proposed, justification of its purpose , and amendments to sections of the spec (such as those regarding clients and authentication servers) that would be affected by this change.