In the current format of the attestation that ssh-keygen creates for fido2 credentials it is unclear if userverification / credprotect were enabled on the private/publickey that were created. This is an important and useful signal for ssh-servers to understand the nature of the key that was used for authentication. 

The attest format should be altered to include the requested userVerification and credprotect state that were requested at credential creation time. For a stronger assertion of this, these data could be part of the collected client data, and the collected client data becomes part of the attest blob (see also https://bugzilla.mindrot.org/show_bug.cgi?id=3516 where it is described why ccd is required in the attest blob ssh-keygen produces) 

Note it is not possible for the RP (server) to rely on the state of the userverification bit in attested credential data as ctap2.1 forces uv=true on all credentials during creation, even if uv=discouraged were sent to the device during the make credential operation. It is required for the server to see "what flags" were also sent to the device for creation.

In a similar vein, it may also be prudent to add the residentKey boolean to the ccd so that a server can verify if an rk was created or not.