Excellent! Thank you for writing and sharing the blog post. I will read it more deeply later, but at first glance it looks like you found implementation fairly straightforward aside from understanding UserToken and an origin issue. This is great to see. 
ā-
I pushed an update to v0.8.0 at ElixirConf last week, and a more detailed post is overdue. Once life is done interfering with my plans, I will be posting that update and revisiting some improvements that have been deferred.
@type1fool Thx for this library and the nice documentation you wrote! Which came handy as a popup window during editing.
Also @Hermanverschooten Your blog post was very helpful. Adding passkey support to an existing phoenix application was not too difficult.
I have older hardware keys Iād like to use which (I guess) donāt support being used as a passkey device.
I already lowered the requirement regarding the user_verification from required to preferred but thatās not enough.
The control flow is different since the user name somehow has to be given to the component.
Without any offense, just saying:
If the library is only supporting passkeys perhaps rename it.
I like: PasskeyLiveComponent
Passkeys have a great momentum right now. Keep up the good work!
With best regards
Thank you for the feedback, @Terbium-135!
I have older hardware keys Iād like to use which (I guess) donāt support being used as a passkey device.
With some modification, it should be possible to use hardware keys, a Yubikey for example with the package. The Javascript is currently hardcoded to only accept āplatformā credentials, effectively meaning Passkeys. See line 44 below:
I could make this configurable so that developers could opt into supporting non-platform credentials. There may be other parameters that would need to be configurable, so I will do a bit of research when I have time. In the meantime, I created issue #87 for this enhancement. If you canāt wait, you could fork the repo and/or open a PR to make this change.
Without any offense, just saying:
If the library is only supporting passkeys perhaps rename it.
I like: PasskeyLiveComponent
No offense taken. The package has already been renamed once, from webauthn_live_component to webauthn_components. While the first goal was to make Passkey support easy for LiveView developers, support for other types of credentials should be possible with the same package. We wouldnāt want to have separate packages for Passkeys, USB keys, Bluetooth, and so on. The way to accomplish broader support is to increase control over registration parameters so that devs can tailor authentication options based on their business requirements and user preferences.
Another concern is that there is a growing amount of content referencing the package by name. Renaming the package may lead to more confusion, not less. Regardless, I appreciate your thoughtfulness. 
@type1fool I have been looking for a Hex package that supports Passkeys for Phoenix applications. Thanks so much for making this happen.
Hey @conradwt, thank you for the shout out! Much appreciated!
TLDR: This project needs a new maintainer.
Since I released this package almost three years ago, I have enjoyed the process of learning about Passkeys and creating tools that could be used in my favorite web framework. When I started seriously pursuing a career in software development, web security was surfacing in headlines with increasing frequency. The Snowden leaks, stolen government laptops with personally identifiable information, unprotected data repositories, the pace of credential thefts - all these stories made the prospect of this career even more intimidating than it already was.
So, security has always been front of mind for me. When employers, clients, and users use the applications we create, we have a responsibility to protect their data with all of the tools at hand. We also have a responsibility to push for and adopt better tools. This is why WebauthnComponents was created. The first W3 spec for the WebAuthn spec dates back to 2019 with iterations continuing in the years since.
What makes Passkeys interesting is that itās a rare security mechanism that is actually user-friendly. Multifactor authentication via SMS, Email, OTP codes were vulnerable to interception, and hardware devices would likely never get mass adoption. By integrating devices, operating systems, and cloud accounts Passkeys made a specialist-oriented technology much more palatable for people who may never need to understand the implementation details.
This project started as an experiment to see if I could understand the WebAuthn API and add support for Phoenix LiveView applications. Did I mention itās my favorite framework?
Over the summer of 2022, I spent most of my spare time learning the API and writing code that would eventually be released at ElixirConf the same year. This was the first time I had deeply read a W3 spec after needing more information than MDN docs provided.
There were several skills I picked up in the course of building WebauthnComponents:
To varying degrees, I feel confident in those skills. The conversations in this thread and the contributions in the repo are good indicators that this was time well spent.
However, that last skill, supporting the community, is where I have the least confidence now. The list of issues and PRs may be relatively short, but the amount time they require is not. At least, it is not an amount of time I have now. There are a few reasons I have less time to carry this project forward, but the one Iāll share here is that I started a new role in April which is both thrilling and consuming as an engineer. I hope to share more in the future, but for now I can say I have less mental and temporal bandwidth than I did in the past.
As a result, issues and pull requests have languished in the repo this year. The fact that they exist is a reward in itself. They mean that you and others like you have taken time to use the package, report problems, investigate the code, and share contributions.
One cost is that I am further from the initial problem than I was three years ago. Passkeys will continue to roll out to more and more services, and the world will benefit. However, I am no longer in an environment where Passkeys are a useful component. This means I spend very little time with the technology other than as an end user. That makes maintaining the package more difficult than I expected.
All of this is to say I am looking for a new maintainer or group of maintainers to adopt WebauthnComponents. I have put this off for a bit because it is important to get it right. Although it may not have the broad impact of the XZ debacle, a bad actor could still do significant damage by compromising a package responsible for creating web credentials.
Instead of hunting for a new maintainer, I decided to post here. The community can play an important role in vetting and encouraging whoever takes up ownership of this project.
My expectations for this process are:
| Duration | Task |
|---|---|
| TBD | Nominations |
| TBD | Decision |
| 1-3 months | Onboarding & collaboration |
| 1 month | Handoff |
Feel free to discuss this project with the people you know in DMs, at conferences (ahem ElixirConf), and in this thread. Keep in mind this is a place for encouragement.
I will coordinate with the new maintainer(s) via direct communication asynchronously and through scheduled calls as needed. If you become a maintainer of WebauthnComponents, I will do everything I can to set you up for success. Rest assured this project has not required a tremendous amount of time since its initial release. That may change as it becomes more widely used.
The length of this phase depends largely on schedules, which can be complicated to align during holiday season.
During this phase, I will step back from contributions. We will determine in more detail what level of involvement to expect, and I will be available for reviews and discussions.
Thank you to everyone who has spent time with WebauthnComponents. I hope to see this work carried forward and improved in ways I couldnāt even imagine. Hereās to the future!
Hi Owen!
First of all congrats for the great work youāve achieved with WebauthnComponents. As the author of Wax, Iāve been following your work and that is some really great work. Itās also great that youāve moved on to new demanding projects that you like.
Hopefully weāll find some new maintainers. Iād add that Iād be glad to assist as well any developer joining the WebauthnComponents project, as much as I can (although, like Owen, Iām pretty busy).
Not long ago I was asked about using Wax/WebauthnComponents in Elixir vs Rustās WebAuthn implementation. An interesting fact is that they have 32 contributors, while Wax + WebauthnComponents have only a handful of active contributors. IMO what it means is that WebauthnComponents is a great project for anyone joining the Elixir community, willing to have an impact and ready to give a bit of time to it! If youāre interested, consider applying to Owenās proposal!
@type1fool I have a honest question: when you started working on this project, Phoenix components were in their infancy and colocated hooks and other niceties didnāt exist. Therefore, a LiveComponent was the way to go. Do you believe that nowadays, a plain, stateless Phoenix components (with a bit of colocated JS) would be sufficient to implement WebAuthn modules? What would be the pros/cons? (A REST API would probably be needed I guess.)
Although it may not have the broad impact of the XZ debacle, a bad actor could still do significant damage by compromising a package responsible for creating web credentials.
This would actually be a primary target, because WebAuthn can be used in demanding security environments (with attestation), although the size of the Elixir ecosystem mitigates this issue. I, for instance, refused a PR for Wax not long ago that would have, I think, introduced a critical security issue (but I have no evidence at all this was a malicious intent). I just think it would be nice, in the current geopolitical context, to have maintainers from different blocs 
On my side, Iāll continue to maintain Wax (which is more or less finished), desperately waiting for someone to review all of it 
as written in the README:
This library has not be reviewed by independent security / FIDO2 specialists - use it at your own risks or blindly trust its author!
Cheers!
I would be happy to co-maintain the WebAuthn components lib. Iām actively using it and was even working on a PR tonight. I donāt think I have the time to be a sole maintainer.
Edit: My PR fixes (I think) the most recent request mentioned above, about YubiKeys and such (ācross-platformā authenticators). @Terbium-135 you might find it useful (free QA please?). Support cross-platform by peaceful-james Ā· Pull Request #98 Ā· liveshowy/webauthn_components Ā· GitHub
Hey @tang !
This means a lot to me. After all, WebauthnComponents wouldnāt exist without Wax. Thank you for maintaining it!
It could be that colocated JS hooks would allow for some streamlining of the code. I havenāt worked with the latest versions of Phoenix and LiveView yet, so I donāt have deep insight on that topic. If Typescript is supported, I could see value in moving the TS code into templates. There is still a multistep process that needs to be managed, which could mean these remain LiveComponents. Another option may be to use on_mount/1 to inject message handlers into LiveViews, removing the need for the LiveComponents. Itās an idea I havenāt tested, though.
There is an opportunity to replace the token_form with a controller, which would allow for exposing a REST API. The form is only there because I hadnāt worked with controllers in a long time and there were CSRF errors that I couldnāt resolve at the time.
Stay vigilant with the PRs! I agree that many eyes are crucial for keeping the community and end users safe.
I would be happy to co-maintain the WebAuthn components lib. Iām actively using it and was even working on a PR tonight. I donāt think I have the time to be a sole maintainer.
Peaceful James strikes again! This is great to hear. Thank you for your contributions and for offering your support. I will look over the PR when I have some time, hopefully this week.
Also, shout out to @Terbium-135 for a very neglected PR to add cross-platform authenticator support. I will take another look when I have a moment to focus on the repo.
Ā© Copyright Elixir Forum | Terms | Privacy & Cookies
