Demo Project and Documentation for Stand-alone Native FIDO2 Client

[eos4git]

Dear all,

I am currently looking into FIDO also from my perspective of a FIDO alliance member and I am specifically testing eWBM and other hardware dongles with FIDO2 support including biometric functions. I am a bit of a developer myself, but I have rarely worked with ASP.NET – I am actually more focussed on native Windows applications. What I find intriguing about this library is that it also supports native applications, but given the shortage of time since its release I can see how there would be little documentation on its use in native applications.

That brings me to my next question of how I could maybe generally start contributing to this library. If you do not mind I would like to keep my focus on the realm of native applications for now which run outside a browser context making them more challenging in my view. I am willing to contribute both code and documentation, but I am afraid I would need a bit of help myself to get started. For example, now that I have the FIDO server up and running and can also successfully register the eWBM dongle (after fixing the certificate parsing issue), I would like to go ahead and build a native (.NET Core) client that could pick up the previously registered user and do an assertion (authentication) based on it against a remote FIDO server.

I have already figured out that the demo project constructs an in-memory database that holds user objects comprised of the essential attributes such as the user name, GUID and public key. My idea was to try to serialise that object to file either in JSON, XML or binary format keeping in mind that the binary serialisation also preserves what is called type fidelity of the user object in question (I am not sure though if it is required or not at this point). If that assumption is correct, I would also need to do the following by way of next steps:

1. Instantiate the library from the native app (.NET Core). I suppose I do not need to use ASP.NET for that or do I? It should be enough to follow the Controller class example of how to reference the library.
2. Open the user object file and de-serialise it back to a user object.
3. Open an HTTP(S) connection and call the remote FIDO server marshalling that user object over to it for assertion.
4. Verify the server response in terms of a successful or failed assertion / authentication.

I would very much appreciate it, if someone could give me an advice on any of those steps, especially on how to open the connection to the server and marshal the object. Is that something the library already encapsulates at its level?

Maybe we can use this issue to get the conversation going about how to provide a demo project in conjunction with an appropriate documentation of the respective workflows.

[eos4git]

Ok, let us reduce the scope here a bit. If I wanted to make an assertion based on a registered FIDO2 USB token with the following parameters, how would I do that using the examples from Fido2Tests.cs?

Attestation type: Direct
Authenticator: Token
User verification: Required
Use Resident Key: True

This is based on the assumption that I can serialize all the right files (JSON) when running the server and registering a new user with that token.

[aseigler]

I am looking at this. I think the reason for confusion is that I wrote the last set of tests on the assertion side only. What I meant to replace that with is tests that create an attestation for each attestation type, for each supported key type and algorithm, then immediately follow up that registration with an assertion. I have just gotten busy and haven't gotten back to doing that.

For question 1, I think you are right. The demo code works without it. For 2, you can store the user data any way you see fit. We only provided one (two, actually) options, but made it pretty simple to add your own. I think you have a good handle on 3 and 4.

[aseigler]

@eos4git I added the basics of some additional attestation tests in 4cf3fab. It's not ready, very much work in progress. Needs to be organized better and made complete, but hopefully you can see where I want to go with this.

[aseigler]

I have added a great many attestation unit tests with #162. Hopefully this will help this issue.

[FrankSzendzielarz]

I am struggling to get my head round this stuff at the moment. Can someone give me a nudge/hint on how I'd build a .NET Console app and have the internal authenticator (windows hello, i guess) register at a server?

[jinan-kordab]

@FrankSzendzielarz How about creating an API that does all the FIDO2 authentication, and calling that API from the .NET Console app ? Something like this: https://github.com/jinan-kordab/passwordless-dotnetcoreapi-nextjs In this example, the FIDO2 is an API, you only have to replace the NextJs app with your .NET Console app. Hope that helps a little. Thanks.

[FrankSzendzielarz]

@jinan-kordab many thanks. Unfortunately it is replacing the js part i am trying to figure out how to do . there are fido ctap classes in the lib but no usage guidance. I guess i would have to construct different implementations for each native platform but a windows default would be helpful

[nicowitteman]

@FrankSzendzielarz does it have to be a console app per se? If not, you could build a windows app containing a WebView2 component and have that execute the communication with the API and with the navigator to get the credentials.

[dbeinder]

@FrankSzendzielarz
To use the CTAP/HID protocol directly with hardware, your app will need to run with admin privileges and you need quite a bit of extra code to deal with hardware quirks and dealing with the case of multiple connected authenticators.

I'd recommend going through the Windows WebAuthn API, I've built .NET bindings for it: https://github.com/dbeinder/Yoq.WindowsWebAuthn and integrated it with this library

However, keep in mind that in this scenario your app is filling the role of the "browser". So you are responsible for validating the remote server's domain before passing queries to the API.