UK rolls out passkeys across Gov.uk services
biometricupdate.com
biometricupdate.com
It's a pretty ugly situation, and I'm quite disappointed by this. It could've been a cool technology, but until they straighten out the story of whether users are allowed to own their own data, I cannot support it.
[1] I initially wrote this as a pro-Passkey article, explaining how the marketing around Passkeys is ludicrously confusing for what is actually a pretty simple tech. But then I found the spec authors threatening open-source implementations with bans and had to revoke my endorsement. https://www.smokingonabike.com/2025/01/04/passkey-marketing-...
I don't know a ton about the implementation, but the above or the “option” of requiring some kind of TPM or secure enclave worries me. I think it’s only a matter of time before a few select companies usurp control of identity.
Ultimately, I think we’ll be forced into subscriptions for authentication once government services are captured.
What can happen is that the open source and "noncompliant" passkey implementations spread to the point that it becomes impractical to block them, or something that can only be deployed to internal security where an organization can control their authentication mechanisms tightly because they provide the authentication tokens to their employees, and regardless of what the spec writers think or want, the de facto spec simply diverges from the de jure spec. It's not like that hasn't happened to basically every spec ever.
The good news is, I think the market is going to pushed pretty heavily in this direction for a long time. Bitwarden right now provides pretty much exactly the experience I am looking for from passkeys; I auth with my tool, and as long as I am authed, it provides the passkey. It already has mechanisms for not staying logged in indefinitely and requiring periodic refreshes, and I think passkey mechanisms that involve people basically still having to authenticate every time are going to be systematically disfavored in the market to ones that don't. Passkeys are a legitimate advance if I can do one log in in the browser or my password manager and be logged in to all my sites without further intervention; they're actually a downgrade if I now have to go through the effort of setting up a passkey and also still authenticating every time I want to use one. Whether or not it is abstractly a good idea, you can't just spec your way to something like this in practice.
Apple has made it very clear that they will never support Attestation on consumer hardware. So long as Apple is a leader in consumer hardware, consumer apps can't rely on any sort of cryptographically-signed Attestation data being meaningful.
> I don’t know what a “relying party” is, so I’m not sure exactly what this threat entails.
This is most of what is wrong with your argument, I think. "Relying Party" is just fancy security lingo for "website or app that accepts Passkeys" (someone that relies on a passkey, as opposed to provides one), as in any or all of them. There's no "spec" for blocking clients. What you saw wasn't really a "threat" that a banhammer might come down. There's just the million different ways that websites can implement them, and some of them may reject Passkeys without certain metadata or attestations. But you will find out quickly on sign up with that key. It's kind of like some websites blocking passwords without a symbol in them and others don't care if you like symbols or not.
That said, it's also a lot like blocking users based on User Agent string. It's a wild west out there of different mixtures of metadata and/or attestation, some Passkeys just outright lie or pretend to be like the key of someone else. Apple has made it clear their consumer-grade Passkeys send the bare minimum and not much else. If a website wants to support average iOS users, they can't rely on any fingerprinting from Attestations and they have a bare minimum of other key data.
But there will be (already are) "Enterprise-Grade solutions" from companies like Microsoft and Google that want to keep corporate networks "extra secure" and will require you to use Genuine Microsoft Passkeys for Enterprise 2025 Edition Pro or Google Workspace Passkey Manager for Google Authenticator on Android Ultra Secure.
It wasn't a "threat", I don't think, it was an acknowledgement that things are complicated.
Also complicated, the "threat" wasn't even directly about Enterprise-grade (cryptographic) Attestations but the "Passkeys can be both first and second factor and Passkeys can claim that they did that" feature. It's mostly a simple boolean field "checked the user had a second factor" and the open source tools can mostly just lie and there is no way to cryptographically verify that. Apple does lie the other direction (so far as I've seen, Passkeys always use the biometric unlock on iOS, but the keys themselves don't state that they did). It is part of both sides of the ongoing debate about whether or not Passkeys count as one or two factors, websites are making both choices today, and no one can agree, and the spec doesn't help and can't actually threaten anyone to comply with "my Passkeys are always two factor".
> some of them may reject Passkeys without certain metadata or attestations. But you will find out quickly on sign up with that key.
I don't think that's applicable to the case I'm talking about. A relying party could change their implementation to ban the client you are using, after you set up the passkey. When you try to log in later using your private key via an implementation they have now banned, they could reject your log in.
The main (though not only) spec compliance at issue is the truth of the "User Verification" boolean when submitting your unlocked private key to the site for authentication. While it's true that your client could lie about this and the RP would not know, the spec authors view this as a violation of the spec, and a valid reason for RPs to reject users using that client. As I linked earlier, they even maintain a list of clients they feel violate the spec for UV.
> the spec doesn't help and can't actually threaten anyone to comply with "my Passkeys are always two factor".
The spec authors are very explicit that clients not meeting their standards are at risk of being blocked by relying parties. See:
>> RP's blocking arbitrary AAGUIDs doesn't seem like a thing that's going to happen or that can even make a difference
> It does happen and will continue to happen because of non-spec compliant implementations and authenticators with poor security posture.
https://github.com/keepassxreboot/keepassxc/issues/10406#iss...
The spec authors' comments on these issues make it very clear that they feel RPs may correctly block users for using clients that do not handle user data in the way the spec authors want them to. This isn't some corner case, it is explicitly built into the spec. I consider that to be incompatible with open source. It's my data and my software. It's my choice what software to use and how to handle my data. If I may be prevented from logging in to my online services because I use software on the naughty list, then that is not an acceptable authentication method to me.
I don't see an "incompatibility" with Open Source here. There are open source Passkey providers. There are open source Relying Parties. I've written an open source Relying Party. I've used an open source provider. This part of the spec is complicated and there's some fights over it, but part of the reason we're even seeing some of the fights is because open source cares on every side of this debate.
A better analogy would be a website blocking Firefox users because Firefox stores cookies in a way the website owner dislikes. A website intended for use by anybody, that chooses not to serve content based on the user's browser client, would be correctly considered broken. On the other hand, the Passkey spec authors are explicitly saying RPs should make rejection decisions based solely on the client. I agree implementations can be all over the map here, but what's giving me pause is the explicit endorsement of banning clients by the authors of the spec.
> I don't see an "incompatibility" with Open Source here. There are open source Passkey providers.
The incompatibility is that the spec requires the client software to behave in a certain way, or RPs may choose to reject logins from it. Open source software simply cannot make those guarantees. I have the freedom to make my implementation non-compliant. If an RP wants strict compliance from the providers they accept (which is a position explicitly endorsed by the spec authors), then they must only accept closed-source software.
this necessitates sharing attestation signing keys between many devices
if someone starts banning non-trusted attestations then attackers will extract and leak yubikey's/microsoft's/... attestation signing keys
and which point anyone can sign whatever attestation they want
then the other side has to decide whether they lock out & ban thousands of innocent users, or accept the loss of control
My worry is more that relying parties will ban all providers except for (more or less) iOS and Android and Windows clients. That would cover probably 99% of users, but as a side-effect, effectively completely ban open source software from logging in to the service. It's not hard to see a well-meaning person flipping the switch to only allow big-name providers in the name of "security," especially given the existence of the spooky non-compliant list actively maintained by the spec authors.
It's true we could work around this by stealing the tokens from approved software, but I am extremely uninterested in having my authentication rely on stolen attestation tokens.