This is ignorant fearmongering. Attestation has existed for decades, for enterprise use cases. Now decades later, people discovering attestation for the first time are panicking. If you had panicked a decade ago, that reaction might have had more merit.
Today attestation is the most sophisticated it has ever been, and its rollout to the general public, outside of strictly controlled environments, is more viable than ever. We are already going down the road where we are constantly having choices taken away. If you are blinded to this by the fact that "you could do this in your organization 15 years ago so it's no big deal", then that's your opinion, it's no less ignorant.
> The attestion part only serves to strengthen to Google/Apple duopoly
That's strange, since neither of them are a big player in the attestation enabled key manufacturer market. AFAIK Apple doesn't even make keys, and barely anyone uses Google's keys. You even mention Yubikey, yet somehow think Google and Apple have a duopoly here.
That has nothing to do with the standard. Any website can invent its own proprietary authentication extension and try to force it on its users. If a website wanted attestation and the standard didn't have it, they'd just make their own extension. See Apple with Thunderbolt.
That's entirely a problem with one implementation and not the standard. It's like complaining Torx is bad because one manufacturer adds stabby bits to the handles of their Torx screwdriver.
You know what MITM is, yes? There are a ton of points between you and that hash algorithm, and any single one immediately and permanently compromises you.
> Passkeys have to be online to enroll additional keys
No they don't? A passkey is fundamentally just a private key pair, which can be copied around just like a very long password. Of course if you store it inside one hardware enclave and want to move it to another hardware enclave you have a problem, but for software implementations it's simply a client UX issue.
I think "online" here means "loaded in a device", as opposed to "sitting in a safe".
The protocol requires additional keys to sign a challenge during registration, so at best you have to load a pre-generated key from the safe when creating a new account. In practice, you generate a new key for every account, so between generating the key and storing it in your safe there's no backup but cloud sync.
This prevents using backup storage that is safer but inconvenient to access, and also prevents registering accounts on-the-go.
> "Online" in the sense of "loaded in a device", as opposed to "sitting in my safe".
The "device" can be entirely virtual. I've written a passkey-compatible OIDC provider for use on my homelab and it uses passkeys. But the passkeys are just in a SQLite database, which can be copied wherever.
That's not advisable for security, which is one reason I've not released the provider for others to use, but passkeys can operate just fine with that.
If I wanted, the private key itself just be in something like AWS KMS instead of a SQLite database, and it would all still work fine. Nothing about passkeys itself requires a hardware device or that the key be unexportable.
All of which have solutions in this thread too. Nothing forces you to use a passkey provider that enforces attestation if that’s what your threat model worries about.
I admit that the 1+2 yubikey rotation mentioned elsewhere was clever and new to me, but I'd argue that none of the solutions in this thread were good enough.
> Nothing forces you to use a passkey provider that enforces attestation if that’s what your threat model worries about.
I'm very confused by this statement.
For starters, attestation is unrelated to the topic of offline backups discussed in this thread.
Second, the whole problem of attestation, as described in the original post, is that it's not you who decides when to use it. And it's not the passkey provider who enforces attestation, as you said. It's the Relying Party, like Netflix, who can unilaterally decide the minimum security features of my passkey scheme, with all their drawbacks, and attestation ensures that they're followed.
So the problem, then, is with Netflix, not with passkeys. Breaking passkeys to try to prevent some different harm from befalling you does not make sense. And the passkey provider can enforce the lack of attestation by refusing to support it.
Netflix could force you to use a chosen authentication provider to restrict that scenario. But, we already live in that world today, nothing in principle stops them from forcing you to use Okta Verify or Microsoft Authenticator in principle. Yet I do not see people using that as a reason to write articles about how OIDC 2.0 or TOTP is a trap.
> And the passkey provider can enforce the lack of attestation by refusing to support it.
Then you won't be able to use it with Netflix when they require attestation. How's that supposed to help?
> nothing in principle stops them from forcing you to use [...] Microsoft Authenticator
Did you read the article? The author explicitly compares passkeys with TOTP, and explains how relying parties cannot force you to use a specific TOTP provider, because TOTP providers are indistinguishable from the relying party perspective. You could do it with pen and paper and nobody could stop you.
> Yet I do not see people using that as a reason to write articles about how OIDC 2.0 [...] is a trap.
First, there's no such thing as OIDC "2.0". And yes, people do complain about the SSO "Log in with X" services, for precisely the same lock in problems:
Sorry to be blunt, but if your account was not so old I would be reporting you as a possible bot or troll. In my 16 years on HN, this has been my most baffling conversation. I see your other comments on this same post, and you make good points there, I don't understand what's going wrong here.
> > And the passkey provider can enforce the lack of attestation by refusing to support it.
> Then you won't be able to use it with Netflix when they require attestation. How's that supposed to help?
That's my point. The issue is with Netflix forcing you to use passkeys + attestation, not with passkeys existing.
> The author explicitly compares passkeys with TOTP, and explains how relying parties cannot force you to use a specific TOTP provider, because TOTP providers are indistinguishable from the relying party perspective.
I used Okta Verify and MS Authenticator on purpose; they support “extensions” beyond their TOTP support which offer relying parties additional information about authentication events. If Netflix were willing to require atypical passkeys + attestation because passkeys were popular, they should logically be willing to require atypical TOTP + extensions because TOTP is popular. The apps to do this already exist.
I have government websites that already require me to use Okta Verify specifically, but I don’t go around saying this is the fault of TOTP for existing.
> In my 16 years on HN, this has been my most baffling conversation. I see your other comments on this same post, and you make good points there, I don't understand what's going wrong here.
We might just be talking past either other. I have been guilty of it before.
Having read the very complicated WebAuthn spec so I could implement an RP, and participated in too many stupid debates about attestation like this one: multiple, simpler specs focused on specific use cases would have been better than a single gargantuan spec that tries to do everything.
Not true due to induced demand. Traffic increases when more lanes are added to a highway. The alternative to $200 in AI costs is not $20,000 in labor costs. The alternative is nothing because the work was never worth $20,000. So the AI did not eliminate $20,000 worth of hypothetical labor.
AI creates demand for things that didn't exist previously
