Confusing API: MakeAssertionAsync

[glatzert]

The function

fido2-net-lib/Src/Fido2/IFido2.cs

Line 16 in 9ad038b

Task<VerifyAssertionResult> MakeAssertionAsync(

IFido2.MakeAssertionAsync() returns an instance of VerifyAssertionResult. This leads to questions and some confusion about how to use it:

1. The return type contains an status and an errorMessage, that is used in the samples like here

   fido2-net-lib/BlazorWasmDemo/Server/Controllers/UserController.cs

   Line 284 in 9ad038b

   if (res.Status is "ok")

   , but will never be anything else then { status = "ok" } and errorMessage = null despite the sample indicating otherwise. MakeAssertionAsync() will always throw on error, which is okay, but should be clearly communicated.
2. the VerifyAssertionResult.Status property is of type string and is neither populated by an enum nor by an constant, so if that property is relevant, the caller needs to read the code to understand the possible values.

I propose:

• removing the inheritance of VerifyAssertionResult to Fido2ResponseBase since that brings in the two problematic fields.
• adding a bool to VerifyAssertionResult indicating successful verification and thus remove all throws and replace it with return VerifiyAssertionResult.Error(string reason) setting that bool to false (or an enum indicating success and failure to make it clearly distinguishable).

If you'd accept the Idea, I'd implement it and provide a PR.

[glatzert]

I followed the Fido2ResponseBase.Status and currently there's only one line of demo code, where the Property takes another value than "Ok" - I think the property is most misleading as such.

Same goes for the errorMessage - it's always empty.
Fido2ResponseBase seems not to be used in any meaningful way and should as such be removed.

[abergs]

If I recall, the reason for this weirdness was because the conformance tests required the models to look like that. Of course, we improve on this.

I agree - will look into cleaning this up as part of v4.