VerifyAsync accepts Fmt = "none" even when AttestationConveyancePreference was "direct"

Method VerifyAsync from AuthenticatorAttestationResponse doesn’t check which Attestation was inside originalOptions. It uses an AttestationVerifier selected depending on what was in the request (AttestationObject.Fmt):

AttestationVerifier verifier = AttestationObject.Fmt switch
{
    // TODO: Better way to build these mappings?
    "none" => new None(),                           // https://www.w3.org/TR/webauthn/#none-attestation
    "tpm" => new Tpm(),                             // https://www.w3.org/TR/webauthn/#tpm-attestation
    "android-key" => new AndroidKey(),              // https://www.w3.org/TR/webauthn/#android-key-attestation
    "android-safetynet" => new AndroidSafetyNet(),  // https://www.w3.org/TR/webauthn/#android-safetynet-attestation
    "fido-u2f" => new FidoU2f(),                    // https://www.w3.org/TR/webauthn/#fido-u2f-attestation
    "packed" => new Packed(),                       // https://www.w3.org/TR/webauthn/#packed-attestation
    "apple" => new Apple(),                         // https://www.w3.org/TR/webauthn/#apple-anonymous-attestation
    _ => throw new Fido2VerificationException("Missing or unknown attestation type")
};

The problem with this is that if we requested attestation by returning “direct” as the AttestationConveyancePreference, then we are not checking that in that case AttestationObject.Fmt was different than “none”.

I’m right with my analysis or am I missing something?

Thanks for your time!

[aseigler]

The attStmt.fmt “none” has nothing to do with the options.attestation “none”. The RP in steps 3 - 21 checks the result to see if it matches spec and policy, if anything is amiss, the registration should be failed.

[aseigler]

Check out https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-attestationformats. It’s been made a bit more obvious in this draft of the next version of the spec.