This problem would also apply to any other "preference-ordered sequence" parameters, namely pubKeyCredParams and hints. For hints it is explicitly specified that duplicates are ignored, but pubKeyCredParams and attestationFormats have no explicit statement like that.

I don't think this is a problem in practice, though, precisely because both pubKeyCredParams and attestationFormats are meant so that the authenticator simply iterates through them and picks the first option it supports. Thus if a supported option appears more than once, the authenticator will just pick the first occurrence and ignore the rest. If an unsupported option appears more than once, it will just be rejected each time it is encountered. In both cases, everything works as expected.

One could make the argument that duplicates are most likely unintended, so it's better to reject them so the RP finds out about the issue. This would, however, not be backwards compatible with existing RP implementations that (intentionally or accidentally) rely on duplicates being silently ignored.

One could make the argument that duplicates are most likely unintended, so it's better to reject them so the RP finds out about the issue. This would, however, not be backwards compatible with existing RP implementations that (intentionally or accidentally) rely on duplicates being silently ignored.

I agree that throwing an error is a bad approach. But, adding some notes explicitly make the readers and developers to clearly understand how the underlying client and authenticator would work.