FIDO2 confirmation bypassed by the normal confirmation setting

[My1]

Expected behavior

FIDO Standard requires to use presece when asked for it instead of just silently passing the auth

Actual behavior

the confirmation setting expands to fido as well, which kinda violates the standard as far as I think.

Step by step guide to reproduce the problem

Disable confirmation via MP settings

Firmware Version

Bundle version: 12

Operating System

doesnt actually matter but tried on Kubuntu 22.04

[limpkin]

oh that's a tough one.... I'm not sure where i stand here :/

[My1]

well tbh clients can ask for auth without presence (while not really a thing in webauthn, non-web applications, e.g. pam-u2f would totally be able to do that) and if it is asking for presence it would only make sense to do verify it.

although granted platform authenticators send the presence bit despite not really having any assertion of presence

[My1]

also if we leave the skip conf for FIDO in, at least do this as well as some other things in a seperate piece as I think that FIDO should have the ability to have seperate rules in terms of a lot of things. some users might want to for example also enter the pin fresh when FIDOing in with UV active.

[nekromant]

This is actually a problem when logging in to gitlab and using FIDO2 as 2FA. Perhaps normal creds and FIDO2 should have 2 different confirmation types that should be properly queued by device.

[My1]

Can you explain a bit in detail on how that causes a problem. I never lut both normal user/pw and fido creds for the same place on my mp soni don't have experience with that.

[nekromant]

I run a personal gitlab instance, and with some security settings it first asks user and password, and then the passkey as a way for 2FA. And I'm just not getting passkey confirmation on the mooltipass, though I see the notification in browser that it's waiting for someone to press the button on the passkey.