How should the relying party (RP) handle unknown or duplicate fields

[zack]

Good evening,

I was unable to find any guidance on how a relying party (RP) is supposed to handle unknown or duplicate fields during deserialization. MUST/SHOULD/MUST NOT/SHOULD NOT a relying party (RP) error if unknown or duplicate fields exist in the received payload?

Thanks,
Zack

[zack]

To expand on this, the W3C Working Draft, explicitly mentions in certain areas that unknown keys should be allowed like the NOTE in section 5.8.1:

Note: The CollectedClientData may be extended in the future. Therefore it’s critical when parsing to be tolerant of unknown keys and of any reordering of the keys. See also § 5.8.1.2 Limited Verification Algorithm.

The lack of such notes in other locations leads me to believe that it's OK for relying parties to reject the request when unknown keys are present when such notes/clarifications are not present. My question is if such rejection
is elevated to a MUST or SHOULD.

For example Section 7.2, step 3 sates "Let response be credential.response. If response is not an instance of AuthenticatorAssertionResponse, abort the ceremony with a user-visible error." So if credential.response looked like

{ "clientDataJSON": <base64URL>, "authenticatorData": <base64URL>, "signature": <base64URL>, "foo": 4 }

is a relying party required or recommended to reject the request due to the unknown field foo? One could argue the response is not exactly the type of an AuthenticatorAssertionResponse; thus per step 3 it should error. A counterargument would be that AuthenticatorAssertionResponse is an interface which semantically represents a portion of the "structure" of a conforming type (i.e., a type can have additional structure (e.g., equivalence)); thus it does conform.