Fido2VerificationException is thrown at Controller.MakeCredential method.

[daisukenishino2]

Acquiring solution from the latest master branch and executing this on local, the following exception was thrown at Controller.MakeCredential method. But, this is working properly on your demo site. I confirmed on the console of chrome, but error is not occurred.

Fido2NetLib.Fido2VerificationException: Exception of type 'Fido2NetLib.Fido2VerificationException' was thrown.
   at Fido2NetLib.AuthenticatorResponse.BaseVerify(String expectedOrigin, Byte[] originalChallenge, Byte[] requestTokenBindingId) in \fido2-net-lib\fido2-net-lib\AuthenticatorResponse.cs:line 64
   at Fido2NetLib.AuthenticatorAttestationResponse.VerifyAsync(CredentialCreateOptions originalOptions, String expectedOrigin, IsCredentialIdUniqueToUserAsyncDelegate isCredentialIdUniqueToUser, Byte[] requestTokenBindingId) in \fido2-net-lib\fido2-net-lib\AuthenticatorAttestationResponse.cs:line 177
   at Fido2NetLib.Fido2.MakeNewCredentialAsync(AuthenticatorAttestationRawResponse attestionResponse, CredentialCreateOptions origChallenge, IsCredentialIdUniqueToUserAsyncDelegate isCredentialIdUniqueToUser, Byte[] requestTokenBindingId) in \fido2-net-lib\fido2-net-lib\Fido2NetLib.cs:line 93
   at Fido2Demo.MyController.MakeCredential(AuthenticatorAttestationRawResponse attestationResponse) in \fido2-net-lib\Fido2Demo\Controller.cs:line 81
   at lambda_method(Closure , Object )
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeActionMethodAsync()
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeNextActionFilterAsync()
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.Rethrow(ActionExecutedContext context)
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Internal.ControllerActionInvoker.InvokeInnerFilterAsync()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeNextResourceFilter()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Rethrow(ResourceExecutedContext context)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.Next(State& next, Scope& scope, Object& state, Boolean& isCompleted)
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeFilterPipelineAsync()
   at Microsoft.AspNetCore.Mvc.Internal.ResourceInvoker.InvokeAsync()
   at Microsoft.AspNetCore.Builder.RouterMiddleware.Invoke(HttpContext httpContext)
   at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Session.SessionMiddleware.Invoke(HttpContext context)
   at Microsoft.AspNetCore.Diagnostics.DeveloperExceptionPageMiddleware.Invoke(HttpContext context)

This is displayed as following on console of chrome

:4728/makeCredential:1 Failed to load resource: the server responded with a status of 500 (Internal Server Error)

I am using YubiKey as authenticator.
And, the following json data is posted to Controller.MakeCredential method.

{
	"id": "wOliPOJgXxqHrne1eFboQ9BD_IgrC1Wqq5M8peNRADZXD0jhmz_lJzB5JWqyBWQxL51JBXp16NDM8lpTkdgSrQ",
	"rawId": "wOliPOJgXxqHrne1eFboQ9BD_IgrC1Wqq5M8peNRADZXD0jhmz_lJzB5JWqyBWQxL51JBXp16NDM8lpTkdgSrQ",
	"type": "public-key",
	"response": {
		"AttestationObject": "o2NmbXRkbm9uZWdhdHRTdG10oGhhdXRoRGF0YVjESZYN5YgOjGh0NBcPZHZgW4_krrmihjLHmVzzuoMdl2NBAAAAAAAAAAAAAAAAAAAAAAAAAAAAQMDpYjziYF8ah653tXhW6EPQQ_yIKwtVqquTPKXjUQA2Vw9I4Zs_5ScweSVqsgVkMS-dSQV6dejQzPJaU5HYEq2lAQIDJiABIVggc3EBnpl-GGLh3i-c5Or05YwcFznBhd-YAn64BBXU7y0iWCBh_I6c4w5SB2tZ1dze_KlhyAtoG6YQP5u0j-h-Q857Xg",
		"clientDataJson": "eyJjaGFsbGVuZ2UiOiJaYmk5WkFaNk9yV2NGUW1aRGpnS3M3NmxjQzNBaGlUSEJnR3NlS2dLOTZieTUyNFdRQm5wUUlNNVdjVFRidGdwN2l5RmZyWjh6ZUdLQWVnQWVVWHk1dyIsIm9yaWdpbiI6Imh0dHA6Ly9sb2NhbGhvc3Q6NDcyOCIsInR5cGUiOiJ3ZWJhdXRobi5jcmVhdGUifQ"
	}
}

[abergs]

I will test, but could it be that your response properties are not encoded with base64url?

[abergs]

@daisukenishino2 if you set a breakpoint at https://github.com/abergs/fido2-net-lib/blob/master/fido2-net-lib/AuthenticatorResponse.cs#L18 what is your deserialized Json (stringx variable)?

Mine is: {"challenge":"E5f4b5SdLp2oKWWIh40RcTf9oV4myO-HLyTat6vz3aWKXOQeemMyzCFEzpqDBs4XsrCdoCLboQSX5k3xNyAc1A","new_keys_may_be_added_here":"do not compare clientDataJSON against a template. See https://goo.gl/yabPex","origin":"https://localhost:44329","type":"webauthn.get"}

[abergs]

@daisukenishino2 Also you can try to check out the latest master branch, I've since merged @aseigler changes which should add more information in the exception.

[aseigler]

Try using "https://localhost:44329" instead of "http:https://localhost:4728". SSL is assumed to be in use, I think you will get a Origin vs expectedOrigin mismatch if you use HTTP. @abergs, we should probably disable the non-SSL option in the project configuration. Was able to repro problem replaying data from @daisukenishino2 through the HTTP uri. This also explains why the demo site works.

[abergs]

@aseigler Solved by informing user in 397b6b3

[daisukenishino2]

@abergs @aseigler

Set launchSettings.json as follows, this worked well.
Thank you very much for your supports.

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "https://localhost:44329/",
      "sslPort": 44329
    }

I also have plan to implement FIDO2 in ASP.NET,
so I am referring this repository with interest.

[abergs]

@daisukenishino2 Please leave feedback if you have any. We will of course release a nuget package when the library has matured for easier consumption. I 'm also investigating if a middleware would be a suitable integration point for easier consumption.

[daisukenishino2]

@abergs

I have experience to implement biometric authentication to the website by "Windows Hello". However, I does not have expert knowledge for FIDO2.

• https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/Controllers/AccountController.cs#L443
• https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/Controllers/ManageController.cs#L2297
• https://github.com/OpenTouryoProject/MultiPurposeAuthSite/blob/develop/root/programs/MultiPurposeAuthSite/MultiPurposeAuthSite/Models/ASPNETIdentity/FIDO2Extension/FIDO2Helper.cs

The result of observe the implementation of "fido2-net-lib", I started to think it is necessary to analyze the implementation of "Fido2Demo" side,
https://gist.github.com/daisukenishino2/d50bfcfa415902abfdee0e27ed48a715

And compared my implementation and "fido2-net-lib" implementation in this work, I thought that implementation of "Fido2NetLib" side is big. Therefore, I think it is important how to prove the reliability of the Fido2NetLib side. And, I think reliability is required for dependency library of Fido2NetLib as well.

And I understood that I was too ignorant about spec aof FIDO2 in this work. Because, if provid this to enterprise users, then required guarantee quality. Therefore, even if user side, I think it is necessary to know more about spec of FIDO2.

... I will analyze "Fido2NetLib" side from now. I think that I will rather be taught, by this lib, but I will send you feedback if I notice something there.

[abergs]

@daisukenishino2 Yes, the Fido2NetLib side is where 95% of the work is happening.

There are however some things that is necessary to know about browser side and the HTTP server side.

1. We currently expect everything that is a byte[] to be base64url-encoded when sent from the browser. In certain other examples they send some data as base64 and others as base64url.
2. Storage, as shown in in the Fido2Demo. Your server need to be able to store and retrieve certain data as expected (Counter e.g.)

Also note: This project is till heavily work in progress. We aim to make it fully compliant (100% test score on the official test tool). We also might change the requirement on base64url where the spec allows us.

[daisukenishino2]

@abergs , @aseigler

I implemented webauthn using fido2-net-lib to my Idp.
And, summarized the feedback in following page.
https://gist.github.com/daisukenishino2/204f16d612831421ab7451861a29c001

[aseigler]

@daisukenishino2, this is a very nice writeup and your IdP integration is a great success story! Thanks for sharing it with us!

• "Server Requirements and Transport Binding Profile": I need to re-read this, I am not exactly sure what is not in compliance here

• "MDSAccessKey": This is the access token referenced here: https://fidoalliance.org/metadata/. It is used by the library to access production metadata. The metadata is used with certain attestation types to verify that the information in the attestation matches the corresponding characteristics for the authenticator used (determined by the aaguid in the attestedCredentialData in authData), as described in the retrieved metadata. A relying party may also use this metadata to allow or prohibit users from registering authenticators with specific characteristics. For example, a relying party may only wish to allow authenticators that support a certain type of user verification (https://fidoalliance.org/specs/fido-v2.0-id-20180227/fido-registry-v2.0-id-20180227.html#user-verification-methods), the metadata provides a framework to allow this sort of scenario. The metadata for an authenticator often includes an image of the authenticator, provided by the authenticator vendor. The relying party can then display this image for the user during login or other operations.

• "DevelopmentInMemoryStore": I agree this could stand some improvement, but I am not certain what direction to go for ease of use. We are certainly open to suggestions!

@abergs, take a look at the JavaScript feedback, see if we can use it with the new demo web page