Unexpected keys in CTAP2 responses should be ignored

[hvge]

Hello,

I'm working on a FIDO2 hardware token that supports the CTAP2.1 protocol, and we have identified an issue with Mozilla Firefox on Linux. Specifically, when the authenticatorGetAssertion command's response contains keys introduced in CTAP2.1, the entire response is rejected. This behavior contradicts the specification, which mandates that implementations must ignore any keys they do not understand.

Refer to the CTAP2.1 specification, which states:

"If map keys are present that an implementation does not understand, they MUST be ignored. Note that this enables additional fields to be used as new features are added without breaking existing implementations."

Our hardware token includes the userSelected member in the authenticatorGetAssertion response structure. After investigation, I identified that this line in the code is responsible for rejecting the entire response.

Although I have not reviewed other commands in depth, the "ignore unknown keys" principle applies universally to all responses returned by the authenticator.

Thank you for reviewing this issue.

[emlun]

After investigation, I identified that this line in the code is responsible for rejecting the entire response.

Permalink pinned to latest commit as of 2024-12-17:

authenticator-rs/src/ctap2/commands/get_assertion.rs

Line 792 in 9410d65

k => return Err(M::Error::custom(format!("unexpected key: {k:?}"))),