Update 
Still alpha after all these years
I have updated WebAuthnLiveComponent with a new version which adds preliminary support for Passkeys. More specifically, discoverable credentials aka resident keys.
WebAuthnLiveComponent.PasskeyComponentis the module containing the new LiveComponent, which provides a drop-in pair of buttons for registration and authentication via Passkey in a LiveView applicationpasskey.jscontains the client-side Javascript for interacting with the WebAuthn API, sending events back to thePasskeyComponent, which in turn sends messages to the parent LiveView (see Communication).
Thanks to @dbern for moral support and asking great questions as I wrestled with implementing Passkey support. The mental model here is quite different from traditional authentication, so it was helpful to have someone to ask “how,” “why,” and “what if” throughout the process.
What’s Next? 
Split, merge, or ???
The full module name, WebAuthnLiveComponent.PasskeyComponent is just a bit too much for my taste. I expect confusion about the two LiveComponents in this package, which are based on the same WebAuthn API, but take two approaches to implementation. The original component includes a form which requires a username before proceeding with registration or authentication.
So, I am looking for feedback on whether to split PasskeyComponent into its own Hex package, replace the WebAuthnLiveComponent module with the Passkey implementation, or something else. I am inclined to keep the original component for applications which would like to require a username first, though I would plan on replacing the form with a slot and using a @changeset assign to allow more control from the parent LiveView.
This is still an early alpha package with little adoption, but some excitement and interest expressed in this forum. So, there is still time to make significant changes to improve developer experience.
Speaking of Developer Experience 
I spent some time documenting the PasskeyComponent module, but there is still more work required to clearly document the process of using the component from start to finish. This includes adding the JS hook to the LiveSocket and several message handlers that must be added to the parent LiveView. Not to mention requirements for persisting the user’s public keys created during registration, as well as other requirements and best practices in the parent application.
Demo Application
Updates to the demo Phoenix application are a work in progress. With the Hex package updated, some cleanup needs to be done to remove prototype component code. Other updates to the demo app include:
- Finish Live Session Hook implementation
- Add
/passkeylink to landing page - Add tests for the
PasskeyLiveView - Remove
AuthLiveView and route ...
Contributions 
If you are interested in contributing, please don’t hesitate to respond in this thread. Since this is a potentially critical piece of security code, I believe it is important to keep the conversations as public as possible. 
to maintainability and adoption. Testing is also critical for a set of security-oriented components, and the modular design should make testing more straightforward than it would have been.