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
