Issues with custom FIDO hybrid authenticator + tunnel (Safari drop / Windows linked device disappears)

[Grzegorz Kołaski]

Hi all,

I’m working on a custom mobile FIDO hybrid authenticator + custom tunnel service (The routing ID is advertised over BLE). I’m aware there are more native solutions for Android/iOS, but I still need to implement my own stack.

I’m currently stuck on two issues and would appreciate any guidance:

1) Safari (QR flow):

After scanning the QR code, Safari connects but then most of the time (not 100%) drops the WebSocket shortly after. The same flow works fine in Chrome.

Has anyone seen Safari-specific behavior that would cause the tunnel connection to close after QR scan?

2) “Simplified login” / state-assisted flow on Windows:

I can see my device registered in Windows (it appears in the registry). But when I click “Authorize”, instead of showing the device in Windows Security window, it disappears.

Is there a known requirement/trigger to force Windows to use the simplified (state-assisted) login and actually keep the device available?

Any hints, Safari quirks, or platform requirements would be really helpful.

Thanks in advance!

[Tim Cappalli]

Cross-device authentication (e.g. hybrid) is not something authenticators implement. It is implemented by the client platform. 

When you build a credential manager using credential management APIs on each respective platform, CDA is handled automatically.

tim

--
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 visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/5dcc139a-22a8-4182-853d-8c75fa1de3d8n%40fidoalliance.org.

[Grzegorz Kołaski]

Hi Tim,

Thanks for the response. 

I understand that using credential management APIs would handle CDA automatically, but I'm intentionally building a custom authenticator (not a credential manager) with its own tunnel service.

Regarding your point about cross-device authentication being implemented by the client platform — I agree that the client platform initiates the connection, but the CTAP 2.2 spec (section 11.5) describes the tunnel service as something provided on the authenticator side. 

The authenticator advertises the routing ID over BLE, the platform discovers it and connects to the authenticator's tunnel. (when advertising with routing above 256 as far as I remember)

And that is why I am confused why I am not able to connect on Safari, and on Chrome it just works. (Beside state assisted flow)

Any advice appreciated,

Greg

[Tim Cappalli]

The terminology can be a bit confusing, but in this context, the authenticator for CTAP hybrid transport is the OS platform, with credentials being provided by a credential manager. All transport functions are handled by the underlying platform, including the tunnel service.

You'll need to build a credential manager application.

tim 

[Grzegorz Kołaski]

Thanks for the clarification. 

That helps me understand the intended architecture a bit better :) So if I would like to have my own authenticator, tunnel-service - I need to have a own implementation of client as well.

A follow-up question: my current implementation uses a custom tunnel ID (derived from the QR secret, advertised via BLE). The platform discovers it and connects to my tunnel service. This works with Chrome — is this approach considered a valid use of the protocol, a workaround, or something that's likely to be blocked in future versions?

Let me describe what I'm actually trying to achieve — maybe there's a better path:

I want to build a mobile authenticator app that supports passkeys, allowing users to register and authenticate on a PC from a mobile device. The key requirement is that it should work seamlessly — without requiring users to change their credential manager from e.g. Google Password Manager to a custom one. That onboarding friction (scan QR, switch credential manager, etc.) is something I'd really like to avoid.

On that note — your talk at Authenticate last year ("Passkey Mythbusters: Short Takes on Common Misunderstandings") was very relevant. You mentioned Managed Credential Managers — I found that concept really interesting but haven't been able to find more details. Could you point me in the right direction? Specifically, are these essentially synced passkeys that automatically appear on the user's device, or is there a different management model behind them?

Thanks again for your time,

Greg

[Tim Cappalli]

So if I would like to have my own authenticator, tunnel-service - I need to have a own implementation of client as well.

I guess I'd flip that around. If you want to offer credentials on a device (for use locally or cross-device), you need to build a credential manager.

Authenticator in the traditional, hardware sense combines key management, key storage, transports, etc together (e.g. a security key).

Authenticator in the software world is largely split into client platform services (transports) and credential managers (key management, storage, etc).

This works with Chrome — is this approach considered a valid use of the protocol, a workaround, or something that's likely to be blocked in future versions?

I can't comment on what any given product is going to do, but trying to build your own CTAP hybrid layer on top of the existing platform services is generally unsupported at scale.

The key requirement is that it should work seamlessly — without requiring users to change their credential manager from e.g. Google Password Manager to a custom one. That onboarding friction (scan QR, switch credential manager, etc.) is something I'd really like to avoid.

The user doesn't need to change their credential manager. They can have multiple credential managers enabled at once on both Android and iOS. This is common for personal vs work scenarios (e.g. Bitwarden for personal and Microsoft Authenticator for work).

You mentioned Managed Credential Managers — I found that concept really interesting but haven't been able to find more details. Could you point me in the right direction?

It is just a general concept. A credential manager completely in the user's control is considered unmanaged. A credential manager which has policy applied from their employer (e.g. an additional credential manager they install), would be considered a managed credential manager. There are a few of these in market today. It doesn't have so much to do with the type of passkey created as to whether there are policy and controls applied.

[Grzegorz Kołaski]

Ah - this clarifies a major misconception I had. I was operating under the definition where "Authenticator" was strictly the mobile application, so I attempted to build the entire stack (transport + keys) myself.

I have already done some tests implementing my own credential provider on Android.I was not happy that the OS automatically handle the CM selection(favour Google Password Manager / Samsung Wallet). Sure, there is an option to change it, but it's not so obvious to the user. Changing the default Credential Manager in system setting to avoid that is also a bit confusing.

I’ll check if it can be somehow managed by MDM tools in company - like MS Intune etc.

Still, thanks for unblocking my thinking on this,
Greg

[My1]

> The user doesn't need to change their credential manager. They can have multiple credential managers enabled at once on both Android and iOS. This is common for personal vs work scenarios (e.g. Bitwarden for personal and Microsoft Authenticator for work).

Sadly that doesnt always work in practice. I have a phone on android 15 (HMD Fusion) as well as 2 Tablets (Samsung Galaxy S9 FE and oneplus Pad 3) on Android 16 and I have had fun on at least 1 or 2 of them with a credential from e.g. google's manager because it didnt let me select anything but the primary in a Hybrid scenario or the inverse of that.

To view this discussion visit https://groups.google.com/a/fidoalliance.org/d/msgid/fido-dev/LV9PR13MB76002B10330FA076CD2430E7A063A%40LV9PR13MB7600.namprd13.prod.outlook.com.

[Tim Cappalli]

If this is for workforce scenarios, there's some early ideation going on for a solution to help address the credential manager selection challenges for a work credential (this is only a challenge during create).

 Happy to chat more offline. 

---

From: Grzegorz Kołaski <g...@rublon.com>
Sent: Thursday, February 12, 2026 4:07:29 AM