Redundant callback IsUserHandleOwnerOfCredentialIdAsync

[dbeinder]

When verifying an assertion, the API consumer already needs to look up the stored public key corresponding to the received CredentialId in order to call MakeAssertionAsync().

• That could be just a lookup by CredentialId in a Credentials table - which should be combined with a JOIN back to Users table and fetch the associated UserHandle in one go.
• But the original purpose of adding UserHandle in FIDO2 was to enable the RP to design their database with an efficient index on a UserHandle column of the Users table (full control over its structure, without having to create an index on variable-length CredentialId data). So with this DB design, it's even more natural to fetch the UserHandle first and then look for the public key among those registered to this user.

IMO, by the time the MakeAssertionAsync() is called, the API consumer already has all the inputs in place to rule out a CredentialId/UserHandle mismatch and having a IsUserHandleOwnerOfCredentialIdAsync callback seems pretty redundant to me.

I understand it is neat to have the whole pass/fail logic in a single call. But it seems to me, in this case, the only sane, real-world implementation of the callback is return true.

[henryzhao95]

Seconded: I've also come to the realisation today that the database call within the IsUserHandleOwnerOfCredentialIdAsync callback of the example in the README is redundant since as you mentioned, the UserHandle is available in the retrieved credential, and can be trusted since it's not from the client.

Is there any situation where it would be beneficial to verify the UserHandle from the database matches the UserHandle in the callback args (which I understand is from the AuthenticatorAssertionRawResponse sent from the client? Under what circumstances could they hypothetically mismatch?