Support for caBLE / CTAP hybrid transport in libfido2?

[joelonsql]

Dear libfido2 maintainers,

I'm wondering whether there is any plan or interest in supporting CTAP hybrid transport (caBLE / Cloud-Assisted BLE, CTAP 2.1+) in libfido2, or whether this is considered explicitly out of scope.

By "hybrid transport" I mean the QR-initiated flow using initialHandshakeMessage, BLE used only for proximity, and a cloud relay carrying Noise-protected CTAP messages, as used for cross-device passkeys in browsers such as Chrome and Safari.

Support for this would be useful for non-browser, self-compiled applications such as PostgreSQL's psql client. Such tools could benefit from passkey authentication using a smartphone as the authenticator, but cannot reasonably rely on browser-centric or OS-managed Passkey APIs. On macOS in particular, those APIs require application entitlements and Apple App Site Association (AASA) configuration tied to a verified domain, which is impractical for generic command-line tools or open-source binaries.

If CTAP hybrid transport were available in libfido2 and used by PostgreSQL, it would allow users to authenticate to psql using standard, cloud-backed passkeys, in much the same way as in modern browsers.

For context, I'm a PostgreSQL contributor currently exploring options for adding FIDO2 as an in-core authentication mechanism. One possible approach is to piggy-back on OpenSSH's sk-provider API, which can use libfido2 or, on macOS, /usr/lib/ssh-keychain.dylib to access Security Enclave–backed keys. That approach favors device-local credentials, whereas supporting cloud-backed passkeys appears to require CTAP hybrid transport, particularly for applications that are not part of a browser or platform trust domain.

I would be interested in using libfido2 for this purpose, to reduce the amount of code we would need to maintain in the PostgreSQL code base.

/Joel

[LDVG]

Hi,

It's not explicitly out of scope, but not a priority for us. There are, among other things, some challenges in making it fit well with libfido2's current API:s (which applies to the regular BLE transport as well). Some more details can be found in a previous discussion.