FIDO Alliance publishes new spec to let users move passkeys across providers

Great; but, as long as a system supports the open solution, anyone can provide for you the closed one, while the opposite isn't the case.

And Passkeys is an open solution, what are you all going on about?

Currently it is not. It was created provider centric so far, and in my reading of the spec, a thinly veiled lockin. The ability to move around should have been built in from the beginning but it was more beneficial for the providers to start without.

There are FIDO Alliance folks posting Github issues requesting to remove features such as plaintext exporting of credentials, with the explicit threat that the Alliance might block such "open" passkey providers in the future. A local database is not enough, it needs to be locked in a secure element or protected with some TPM-like scheme.

The spec allows for hardware attestation as well, to ensure passkeys are being provided from blessed computing environments. Hopefully implementers continue to ignore this anti-feature, because it's entirely stupid to lock out users who want to control their own security; at the same time, letting anyone with an Android phone restore passkeys from the cloud with one of their device PINs.

Historically, the spec was written for hardware security tokens. Keys on those tokens can't be moved around by design.

The whole "platform authenticator" thing enabling passkeys came later. Extending the spec that way was easy: a platform authenticator works just like a hardware authenticator, it just uses a different channel for communication.

The spec the providers built upon just wasn't designed for software authenticators that allow moving around credentials. The original spec assumed credentials are stored in a non-extractable manner in HSMs.

Edit: thinking about it, platform authenticators may have been in there pretty early, but under the assumption of also using an HSM and not allowing extraction of credentials. Providers compromised security for usability, removed the HSM and made passkeys synchronizable – the spec had to adapt.

The original thread:

https://github.com/keepassxreboot/keepassxc/issues/10407#iss...

Passkeys are just resident webauthn tokens with a fancy name.

Where's the lockin?

The attestation anti-feature which is part of the spec. And the portability feature which is conspicuously not. The former makes the enforcement of the later possible.

Pretty telling thread. Tim Cappalli, one of the spec writers drops by to criticize the export feature and suggests that the attestation feature should be used to punish them for not implementing the fully locked in version.

The credential exchange changes nothing IMO, the rod to punish anyone who doesn't want their credentials stored on a tech giants servers is still there.

The attestation is part of the webauthn spec, and it's up to the relying party to decide whether or not to use it. The whole reason it's there is to give some contexts the ability to narrow their users down to specific webauthn storage implementations (which is useful in some corporate / gov contexts).

Are there any examples of any widely-used sites that are enforcing attestation?

Two comes to mind:

- Cloudflare had a "captcha" POC called "Cryptographic Attestation of Personhood" where you need to use a FIDO-approved token. It's reusing U2F just for the attestation part only. I don't think it ever go to production as most people don't have a token (but perhaps in the future hardware-locked passkey may serve as one...)

- Okta do have an option to enforce attestation. By default it is off, but in my Okta production I can limit the list to FIDO-approved vendor only, or to even a subset of them. They also have a beta feature flag for blocking Passkeys but allowing physical keys (which they do not guarantee success)

OK, so you gave two examples of systems that do NOT enforce attestation (one that is not in production, one that has an option to enforce attestation but is not apparently in use).

Are there any widely-used sites that actually enforce attestation?

That's not what happened. He said quote "which would allow RPs to block you, and something that I have previously rallied against".

This is something that has been proposed that Tim fought against but mentioned in the thread to provide context of the types of kneejerk reactions the spec authors have had to push back against.

Let's be truthful and show the remainder of that parenthetical:

> (which would allow RPs to block you, and something that I have previously rallied against but rethinking as of late because of these situations)

I read "these situations" to mean "non-spec-compliant providers", where "spec-compliant" means to prevent plaintext export of resident keys.

I halfway expect a v2 specification where keys are only stored on a few "Certified Attestation-capable" providers (i.e. facebook, google, apple, amazon)

Then watch them get hacked through a systems management plugin like Clownstrike, or Solarwinds.

People already do have issues with e.g. banking apps on mobile devices requiring OS attestation, so we can expect that once they know they can do the same for the most of their web clients (so probably once most people have moved onto Windows 11 which requires a TPM), they will.

It’s absurd, really. Attestation is clearly a feature intended for high security environments, where you want to ensure all employees use their corporate hardware authenticators and those only, yet people act like it’s big techs secret, evil mind control back door.

Given the chance, why wouldn't companies abuse that feature like every single anti-user feature in the history of them? Surely this time it will be different?

If it's only meant to be used for those environments, then attestation data should not be provided by default. IT can enable it on managed devices.

What is absurd about expecting companies to do what many internet banks in some countries already do?

Because it’s highly annoying to set up in a way that doesn’t massively inflate your support cost.

It's up to the provider as to whether they provide or not. I don't think there's a "default"?

I seem to remember that apple specifically don't provide attestation details on their implementation.

This has not stopped banks in the past.

It's only a matter of time when it's this easy. Some essential service, most likely a bank, will inevitably turn it on in the future. And it only takes one of those to make all freedom respecting providers non-viable for someone. For our safety, of course. :)

Non-default as in browsers should not provide any attestation information unless configured to via a setting in about:config (which can be automatically enabled by IT on a managed device), and mobile OSes should not provide attestation info to apps unless configured via some similarly buried setting that MDM can enable.

Basically put it there for nerds and IT where the device owner wants that extra security and coordinates with (or is) the service provider to set it up. For everyday use, it should be unavailable so that it's not used for lockin.

The regulatory universe that banks operate in means that they're not like other companies. They don't share the same overall incentives, and aren't a useful point of comparison.

Browsers should follow the spec.

Whether or not attestation data is passed onto the browser is a decision the passkey provider can make.

As a sibling comment explains, attestation isn't processed by common web browsers unless explicitly configured. Your bank can require attestation from you and limit you to a number of supported authenticators... But I don't quite see what that would get them, other than loosing customers? And to what end, to foster ecosystem lockin on behalf of Apple or Google? It doesn't make any sense. Hence: absurd.