SupportedCtapOptions does not signal absent (not supported) options

[philsmart]

From the CTAP specs you should be able to tell if an authenticator does not support, say, user verification because the uv flag is absent. So there are three states, true and false, which signals the authenticator supports uv, and absent, which signals the authenticator does not support uv.

I assumed this was the same as what is represented in FIDO metadata. Some authenticators have true, some false, and for others it is absent. If that is what it means, I am not sure this is represented in the SupportedCtapOptions class, as they are all primitive booleans defaulting to false.

[emlun]

Hm. These tri-state option values don't really make sense in the context of the MDS. Take the uv option you mentioned, for example:

If present and set to true, it indicates that the device is capable of built-in user verification and its user verification feature is presently configured.

If present and set to false, it indicates that the authenticator is capable of built-in user verification and its user verification feature is not presently configured. [...]

If absent, it indicates that the authenticator does not have a built-in user verification capability.

This only makes sense as an authenticatorGetInfo response, where the value obviously applies to the authenticator that returned it. The "user verification feature is presently configured" state is nonsensical in the MDS context, where this is a static value representing the model of authenticator, not any one authenticator in particular. "uv":true and "uv":false are thus equivalent in the MDS context, which just seems wrong - it definitely breaks the principle of least surprise, at least, as evidenced by this library getting it wrong.

Looking through the tri-state options, it looks to me like all of them would make sense as definite, binary Boolean values, but the definition of the tri-state values would have to change so that false means "not supported" instead of "supported, but not currently enabled" in the MDS context.

Thanks for bringing this up! I'll raise the issue with our colleagues in the FIDO MDS working group and see where that leads. If the MDS data definition changes to use binary values, then no change to the library may be needed; if the MDS definition remains, we'll have to update the internal parsing logic but should be able to keep the data model unchanged.

[emlun]

you should be able to tell if an authenticator does not support, say, user verification because the uv flag is absent

Unrelated to the previous reply - please also note that inspecting just the "uv" field of AuthenticatorGetInfo is actually not enough to tell whether the authenticator supports UV. The "UV capability" signal is split across the uv attribute, signaling whether the authenticator supports internal UV (e.g., using a built-in fingerprint reader or built-in keypad) and the clientPin attribute, signaling whether the authenticator supports external UV using PIN (by entering the PIN on the client device instead of directly on the authenticator). If both of those UV options are acceptable to your application, you'll need to inspect both attributes.

[philsmart]

Thanks, @emlun. Your point about an individual authenticator responding with its current capabilities versus the capabilities of an authenticator model in the MDS, makes perfect sense. The text in the MDS spec is perhaps a little confusing around this:

The information is the same reported by an authenticator when invoking the 'authenticatorGetInfo' method, see [FIDOCTAP].

*Maybe it has just confused me, not sure.

And, many thanks for the advice on UV. I've been battling with this today, this helps a lot. I'll turn off this registration policy for now, and wait to see what is decided.

EDIT: I just realized you already addressed my confusion about the 'authenticatorGetInfo' text in your initial response. Please disregard that.