Comment by agwa

> It's going to be the banks first.

In Japan, this is already the reality. The FSA required brokerages to implement passkey authentication, and the effect is that it's no longer possible to have a brokerage account without a passkey. (Some brokerages, like Nomura Securities, will offer two separate client portals. The portal with money and trading-related functionality requires a passkey).

The thing that sucks a lot is that brokerages seem to also restrict the allowed software/hardware. Don't know the details, but none of my FIDO2 hardware keys were able to be used. I consistently use these hardware keys through WebAuthn, so I was surprised when my brokerage explicitly told me my hardware key is unsupported and I must use either Windows Hello or the iOS Passwords app.

The FSA's official explanation for mandating passkey implementation is that people kept falling for phishing attacks, and the attacks were getting too sophisticated thanks to "AI" or something.

> They could start tomorrow.

They could also start requiring you to mail a DNA sample to create an account tomorrow.

> It's going to be the banks first.

The same banks that (in the US) largely don’t even systematically use 2FA for online banking logins and completely ignore 3DS for card payments? Attestation usually requires customers to buy and carry extra hardware, so I highly doubt it.

The only place I’ve seen mandatory attestation is in enterprise IT, where admins can supply and enforce usage of e.g. Yubikeys.

Banks want attested terminals and for the customer to pay for them. An even better deal for the bank than ATMs, kind of like of how cable TV boxes enforce DRM on the customer and are paid for by the customer.

The banks are also a commonly mentioned reason to not use Grapheneos when it comes up on this site.

Attestation is already putting the screws onto open computing, and the frog is already on the boil.

Any site/service could easily implement their own proprietary solution to force compliance around usage of said service. Whether they can abuse Passkeys or not is irrelevant. If the service does something inappropriate, you can stop using it and, if necessary, build a competing service that is not abusive.

To suggest that people should stop using Passkeys over this is throwing the baby out with the bathwater. All of these features of Passkeys are appropriate in a given context. The only concern is where a service that might not need/justify "high security" Passkeys starts demanding them anyway, and no-one is forcing you to use said service in that case.

> It's going to be the banks first

This is a great point as banks already did exactly this and to me this seems like a very strong proof that we can't rely on "vigorously calling out"

So they're gonna stop supporting Apple users?

While not directly related to passkeys, CAs require private keys for code signing certificates to be generated on FIPS-certified hardware security devices, and use attestation to verify this.

I think OP was referring to “initial attestation”. Without that you cannot attest again.

We have more than enough technology in browsers to allow JavaScript reading live video from your webcam. A website could use that so they can see if you’re looking at the ads enough.

They could start doing it tomorrow. They just have to flip the switch.

What’s your point?

Even stronger, they used to support it, but now no longer do, so we know for a fact that Apple knows how to do attestation, has already expended all resources necessary to implement it, but has then actively decided to go into a different direction (i.e. that of cloud synchronization).

I believe Android still has the option to use hardware attestation, but that automatically opts credentials out of cross-device synchronization, but Apple's veto alone is enough to make attestation non-viable.

If this can't make the "WebAuthN implies mandatory attestation!!" critics update, I wonder if anything can, and how useful their criticism still is.

The "there is something wrong with you if you are at all off the beaten path" has cropped up a lot more for me recently; two examples both from 2026:

1. You can't use Firefox with our website (when I got this popup, I thought I had been transported back in time 20 years, but with Chrome substituted for IE).

2. You can't sign up for accounts with an e-mail from a "custom domain"

2a. I ran some tests; it's the domain itself, not the host, so e.g. foo@gmail.com is allowed but not a foo@somewhereelse.com, even if hosted by google).

2b. After a bit of back-and-forth with support: "No, we won't tell you the list of allowed domains, but gmail and hotmail both will work."

> The feature is now active by default, but no worries, there is a simple button for you to opt-out.

How I wish this were true for (US) banks. They usually force whatever new hell on you they just came up with without asking, or in fact even telling you about it.

The most bizarre instance I've seen so far: "We have unilaterally added this phone number we believe to be in your name (surely cell carriers have better KYC than we do!) to your account as the only SMS-OTP authentication method and are choosing to disregard the one we've had on file for years since it's an evil VoIP number. Please do not contact us again without access to the former number for authentication."

This is a great comment, and yes, the entire industry seems to keep doing this over and over.

My computers and devices feel less and less like tools under my control and doing my bidding, and more and more like something controlled by faraway tech companies, to do their bidding.

Oof, this comment convinced me to go from loving passkeys to "maybe I should be careful". However, I don't think these are technological issues, I think they're policy issues. We need to vote for freedom of computing, and against corporations doing whatever the hell they want.

Heh. This is exactly what happened to me at stackoverflow sites. I had been using OpenID to log in. Eventually they eliminated it.

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.

This is the obvious endgame. Right now you have people who will say that passkeys are unphishable so we should switch to them. When you point out that people will lose their devices and credentials they'll then tell you can just use account recovery emails to get back in. They actually argue you absolutely need an iron clad door with a guard employed by some one else to protect account on some random website (that the website decided was precious, not you) But that's OK because they left a same old shoddy back door open in case you can't get in. So why even bother? Because that isn't the point. The plan is to remove the back door after enough people are trapped, they just need to keep the screaming to minimum while they get everyone in there.

Can someone more familiar explain the end goal?

Would a website want you to have to use Apple Passwords to guarantee that the account you're creating is connected to an Apple account, and thus making it more likely that you're a real, non-anonymous human?

edit: Why not just require "Sign in with Apple/Google" if that's the goal?

I share that concern somewhat, but I think your point stands even better without suspecting some shadowy attestation cabal.

The US has thousands of banks, and nobody tells them how to authenticate their customers – they just all end up doing the same few horrible things, since nobody ever gets fired for doing what all their peers do (and maybe a little bit more to be sure).

It's not a conspiracy theory when it's just another instance of the patterns big tech has overtly used against us for 20 years now. We see, every day, a frog being stung by a scorpion when crossing the river. So we don't let scorpions ride on our frogs any more. No conspiracy theory, just pattern recognition.

"I'm different!" says this particular scorpion - yeah yeah, I don't believe you.

You are saying this as if these companies don't care about CVR or compatibility at all. The reality is that most companies are extremely conservative about pushing you to change your authentication method. Here are my observations, as both a user and an industry insider:

1. Many services have old users with passwords that predate password-strength meters (or their ill-conceived brethren: password complexity rules). The service provider knows these passwords keep falling, and the cost of having to deal with stolen accounts is very real: customer support calls, reimbursements and investigation. But I've rarely seen services that force users to upgrade their passwords (even though it's a very easy solution). Whenever I've offered doing this myself, it was always shut down (either immediately or 3 years down the line) by a myriad of seemingly unrelated stakeholders.

2. To go further than this, companies can also know for certain that some credentials have been leaked by looking at password breach aggregators like Have I been Pwned and forcing users with affected accounts to change their passwords. That too, is rarely done.

3. 2FA (with SMS or TOTP) has existed for ages now, yet very few major non-financial services have made 2FA mandatory by forcing you to register an authenticator app or a verified phone number[1].

4. Webauthn was available in Chrome and Firefox in 2018, and got pretty widespread support by 2020. The "Passkeys" brand was not a thing yet, but the basic functionality was there and both hardware and software support was quite solid. It still took several years for services to even start offering Webauthn to users, beyond small and limited trials. The rationale was simple: UX around Webauthn was still rough, syncing and transferring credentials were still unsolved and the worst part was "What do we even ask the user to do?". The broad concept of passkeys is extremely confusing, but the non-concept we had before was far more confusing. Supporting Webauthn back in 2020 would have given tremendous security benefits for power users who could have understood it and deal with the rougher UX back then, but nobody wanted to take the risk of regular users setting up a passkey, losing it and locking down their account.

5. Now that passkeys are being supported by more and more services, you still don't see them being pushed very hard. Passkeys are great for the service provider, since they just kill a big category of security incidents, but even then you're see pretty conservative adoption. And I've never seen a single service forcing you to use Passkeys.

My point in all these examples is that most companies are extremely conservative here. Forcing users to do something that might confuse them, break their account or frustrate them is risky, since you may lose a very real chunk of your customer base. Sometimes you have to do this, the costs from keeping the old way or the benefits or forcing the change have to be high enough to justify that. Think about how long it took for companies to drop support for IE6. The cost was high, but as long as it still had a sizable market share, it was hard to do. Google was probably the first major company to take steps towards killing IE6 support, and this was famously entirely bottom-up, and was done by engineers either hiding it from their bosses or tricking them[2].

With this trend. I personally find the scenario where non-copyable attested passkeys are forced on everyone unlikely. OP keeps mentioning Netflix, but streaming services are a rather special case, most service providers would get very little benefit from restricting users to an attested non-copyable passkey. Why would they risk all that friction for... nothing at all?

The more real risk with attestations (and we're already started seeing it) is that some services (namely banks) will use attestations to limit you to use their own shitty app instead of using a proper passkey.

---

[1] Keep in mind I'm only talking about companies that already had password-based accounts without 2FA. Companies that started out with a simple username and password are rarely forcing their users to add 2FA. The farthest they generally went is sending you an OTP code or link on a verified email address they already had, and this is usually only done for sensitive operations, a new browser and/or a suspicious location.

Email OTPs, notably, aren't 2FA by definition, since your Email address might be only password-protected, and at the worst case (and excruciatingly common) scenario it might be sharing exactly the same password as your service. Companies would love to have all their users using a stronger solution, so they can stop having to deal with all these pesky credential stuffing botnets, but not at the cost of losing a non-negligible portion of their customer base.

[2] https://blog.chriszacharias.com/a-conspiracy-to-kill-ie6

That could happen but passkeys won't be the reason why.

TOTP also does not imply a second factor, it's just a time-based password calculated from a shared secret that can be stored anywhere, for example in your password manager alongside the username and password. And worse than your password, of which only a hash should be stored at the service you have an account with, they store the shared secret too (which can thus be leaked from their side), so TOTP is never fully hardware-bound, it always exists in at least two places. Passkeys _can_ be fully hardware-bound, with the secret only existing in the secure chip of your phone or hardware security key for example, not at any moment in its lifecycle exposed to user, service or potential attacker.

> Amazon (..) still requires TOTP when logging in with a passkey from an unrecognized device.

I noticed Amazon does that and it annoyed me greatly.

My understanding is that the passkey branding is specifically for copyable, user-verified keys. So the second factor is the biometrics (or equivalent) of your device. But yeah there doesn’t seem to be consensus yet about still requiring TOTP with passkeys.