Re: Time to add FIDO2 support?

On Tue, Jan 27, 2026, at 10:35, Joel Jacobson wrote:
> Draft [1] ("SASL Passkey") is essentially "SASL over WebAuthn/passkeys".
> I don't think the browser-based WebAuthn-protocol maps well to PostgreSQL,
> due to the browser-specific RP ID model (DNS name, HTTPS, origin checks,
> etc). Also, for Passkeys i.e. Cloud Provider backed keys, to work,
> at least on Apple macOS, native apps need platform-specific entitlement
> / domain-association requirements (AASA).

I was curious what would happen if trying a self-compiled Chromium
on my macOS machine, with a website that supports Passkeys.

Expectedly, it refuses access to the keys stored locally:

[35826:18100134:0127/105844.098344:ERROR:components/device_event_log/device_event_log_impl.cc:202] [10:58:44.058] FIDO: touch_id_context.mm:89 Touch ID authenticator unavailable because keychain-access-group entitlement is missing or incorrect. Expected value: .org.chromium.Chromium.webauthn

This is due to the lack of "entitlement" for the app (Chromium).

However, when trying to sign-up and sign-in via Passkey, Chromium or
macOS instead shows a QR-code. Scanning this QR code with my separate
iPhone device, then opened up the native Apple Passkey UI, where I could
select among my passkeys, and then authenticate using FaceID.

While not as convenient as being able to use TouchID one the same
device, I still think this is interesting, as it would then provide an
option to use real cloud-backed Passkeys.

I haven't explored what kind of API that provides this QR-based Passkey
mechanism, but will do some digging. I guess psql would then
show a ASCII art QR code, which the user would scan using their
Cloud Provider mobile phone device.

If it turns out it could work, then I think it should be a separate auth
method, since it has different tradeoffs between security and
convenience, compared to only storing the secret key on the hardware
security device.

/Joel