Hey I'm happy you're able to run passkeys on .Net Framework. Two things: Since I'm on the W3C I'll just share some advice: The spec is still heavily evolving and non-trivial changes are to come, so if you want to keep your port compliant, I'm just giving you a heads up of the upcoming work.

For anyone else just looking to get Passkeys working on a .NET framework web app and feel discouraged about this library .net8 target: I'd recommend taking a look at the Bitwarden Passwordless.dev API. We have a .net framework SDK and you can use our hosted api or self-host a docker container.

The passwordless api is how I run passkeys on all web sites I'm engaged with.

Anders, thanks for the notification! I'll try to keep in touch and of course respond to any problems that will occur with the ported code. Also, I'd be extremely grateful for any note that you leave here to inform about anything that could be important.

There's at least one app I am aware of, scheduled for release, that will use the ported code and thus, I am highly interested in resolving issues as quickly as possible.

Regards,
Wiktor

Wiktor, I have an established .NET Framework 4.8 application, and would like to add FIDO2 / WebAuthN to it. Would this version that you have ported to 4.7.2, work in 4.8? How complete is the implementation? Anything I should know before trying it out? Would you say this is ready for prime time? Thanks, Tim.

@timammons In short:

• this version definitely works in 4.8
• I believe it's production ready
• download the code run the demo locally from VS2022

It's a straight port, where only incompatible apis and libraries were replaced. The core implementation is verified by some good unit tests and all these tests pass in the port, too.

What can go wrong?

The implementation is split between the client and the server and this is only the server part. We don't directly control the client part which is implemented in modern web browsers and devices. The server part could go wrong in two ways:

• it can fail in crypto operations by failing to validate signatures of assertions/attestations - the worst what happens is the pass key authentication doesn't work, users fall back to username/password authentication
• it can fail in crypto operations by incorrectly accepting incorrect signatures. This could potentially be a way for a hacker to log on behalf of a legitimate user. For this to happen, a hacker should first steal public keys from your database and then craft passkey logging attempts signed incorrectly in hope that the crypto fill accept incorrect signatures. But this is what all these unit tests are for, to make sure the crypto works here

We tested this and verified

• android devices work
• ios devices work
• windows hello workd
• fido2 compatible usb keys work

In few weeks I'll get more feedback from a production deployment that just starts slowly, a couple million of users. But I am also interested in other applications using this, in case of anything worth of fixing/improving, the more people the better.

Regards.