The other day I just wanted to store passkeys in Deno KV without feeling like I was rolling my own crypto library. I did not succeed in the limited amount of free time I had on that personal project, and that seemed a shame and a half.
there doesn't seem to be a standard python implementation, and there's no feedback at all about what went wrong if your challenges/responses are not accepted by the client-side APIs. the error if your server-side implementation sends anything unexpected is essentially "no, that's wrong".
I would personally separate auth and the application. Configuring something like Keycloak or Authelia or one of the many other alternatives to do all the difficult work for you and just logging in through SSO/SAML seems much easier than having to keep track of your own authentication rules/security hashes/salting/etc. without making a mistake.
it seems like they've gone out of their way to make it purposefully difficult to communicate between the client and the server. there's client examples to follow, and server examples to follow, but getting something between the two of them is a mystery. json doesn't have a byte array type, so making an api that depends on byte arrays in json seems needlessly obtuse. it's a standard that doesn't work without client-server communication, and it hasn't bothered to define a client-server communication method or use a datatype that can be natively communicated to the server?
The browser API makes it easy to program a client against passkeys, but that doesn't necessarily hold up for doing the server implementation. For that, you need to either find a library that matches your requirements, or read through guides like these: https://developers.google.com/identity/passkeys/developer-gu... that skim over a lot of details.
The end result is that it was more a standard for them more than for direct use by the little sites, and password managers getting involved only furthers that enterprise industry standard feel.