https://passkeys.directory/ indicates that plenty of relying parties have implemented support for passkeys and I’ve yet to hear about any efforts taking 100 sprints (if TFA is to be believed that it’s 100x harder than a single sprint’s worth of work). Indeed a rather lazy exaggeration.

> have implemented support for passkeys

Why do you assume they have also implemented correctly for all cases?

Our blog is full of examples of implementation analysis, and we have not encountered one implementation that is bug-free or leverages the complete toolset (same for us: we have just identified a bug in our implementation that relates to WebKit's user-gesture requirements on iOS versions before 17.4). That's not because of them being sloppy, it's just very difficult to get it right; that's exactly the point. For example, Uber and Amazon both did not get it right (until today). Of course, it is possible to implement passkeys without any external resources, and to be honest, we appreciate any effort, be it open-source, tutorials, or commercial applications. If you have been on an authentication team in a big B2C company and truly want to retain the trust of your customers, then you appreciate passkeys immediately as they solve one of the biggest problems... So we are also happy to see a half-good implementation as it improves security.

is it honestly better than TOTP in terms of security, ease of implementing "correctly*, and convenience?

This matches our experience too. Out of curiosity, do you use email as the identifier? And if so, do you verify during the initial signup flow?

We use email or phone number as the identifier. We recommend verifying on sign-up, but it is actually a configuration option. We have other customers who want to request OTP on the next sign-in. Not validating the identifier on sign-up comes with a long list of potential security/ux race conditions further down the chain (especially if you also support social logins). What is your approach?

Yes, we use email as the identifier, and yes we verify on signup.

We certainly aren't exceptional, and I expect that implementation will become easier as passkeys become more popular, and browser/device APIs develop. So hopefully later adopters will find it even easier than we did.

So not a weekend project but not crazy hard. Probably still rules it out for my hobby apps.

A weekend project is probably fine -- I wrote a Passkey-based SAML IdP in a weekend (re-using the SAML IdP from a different project). It's written in Tcl.

The hardest part of dealing with the Passkeys was remembering to read the whole specification before implementing it -- I spent a lot of time parsing their CBOR/COSE-based specification so that I could get the public key before "discovering" that there was a method for that defined by the specification.

You must know something about the domain. One time I spent several weeks falling to implement a minimal SAML relying party. Not even an idp. I found the spec to be impenetrable without a baseline understanding of the jargon. All the definitions seemed to be circular like when I end up on a Wikipedia article for some fancy math concept.

It's been a while, but I read through the OASIS spec for SAML for my implementation. There is a lot of yak shaving and I also had to implement XML Digital Signatures (XML-DS), and XML Canonicalization (C14N), but overall I don't think it took too long for something that worked, and was a library so I could just give it a key (or PKCS#11 handle) an identity and get back a SAML Assertion, which is fundamentally what I was after. It's available for viewing here [0].

[0] https://github.com/rkeene/saml-idp/blob/master/lib/saml/saml...

Implementing SAML from scratch should take a long time - it's one of the most footgun-prone designs I've ever seen.

'Yak shaving' as a phrase is new to me, and I love it.

Why not use Keycloak, then add OIDC to your Flask app, in 4h?

I think Keycloak is always the wrong choice if you’re looking to simplify your authentication stack

I would if I could use them. But no, Windows refuses to connect to Android, it times out. Same thing on Linux. Android itself? Your encrypted data is locked on this device, and following the help article doesn't do anything. Three different platforms, none with functional passkey support. Awesome UX. My grandparents would've thrown their phone out of the window by now if a website they need to visit requires passkeys. And no, before you ask, Bluetooth is working just fine. I regularly send files between my computers and my phone via Bluetooth, that's not the problem.

> So please don't put passkeys in the too-hard basket after reading this article. Users love them, and they are going to be ubiquitous very soon.

It's funny but that's almost exactly what #15 in the article even eventually states that you can't ignore passkeys because users love them and they will be ubiquitous very soon and also that the article isn't meant to alarmist "it's all too hard" but cautionary "have you considered x?" but they knew writing it will sound alarmist (because of course they wrote some parts of it in an alarmist tone for clickbait/salesbait). Of course #15 ends with trying to sell their product.

We tried to make the article fun to read. In the end, we could have omitted our hint about our product, but honestly, we have gathered a lot of know-how there for anyone who wants to build passkeys on their own. Our blog and this article are one of the better resources to start with, and even without it, our product offering is obvious. But: We are very commited to help anyone implementing passkeys.