Passkeys – More Security at an Unclear Price

szegedi.info supports passkeys.

Technically, there is little to object to. Passkeys enable a very strong form of authentication without requiring users to entrust the platform with a secret.

The private key remains on the user’s side. szegedi.info receives only the public key and can later use it to verify that someone is indeed authenticating with the corresponding private key.

It is, in fact, a remarkably elegant construction:

To authenticate with szegedi.info, a user does not even have to entrust szegedi.info with their key.

That is precisely why I wanted to offer passkeys on this platform.

While implementing them, however, I encountered a price that has surprisingly little to do with this technical property.

Where is the private key?

It has to be somewhere, of course.

On a smartphone. On a computer. On a security key. Perhaps on several devices.

The passkey specification does not require a central infrastructure for this. It allows different kinds of authenticators and different models for handling the keys they create.

In practice, the world looks different for ordinary users.

Anyone creating a passkey today on an ordinary computer or smartphone will very quickly find themselves inside the credential infrastructure provided by their operating system or browser.

Apple offers its infrastructure. Google offers its own. Microsoft does the same. And there are password and credential managers from other providers.

This works conveniently and, in most cases, extremely well.

But something has now happened that the passkey specification itself does not require:

Authentication that does not require an additional trust relationship has, in practice, often become authentication in which the user needs another provider and must entrust that provider with managing their key.

The user did not make that decision

One might argue that users simply need to be better informed.

That does not go far enough.

An ordinary user should not have to think about which parts of the passkey specification their browser implements in which way, what kind of credential is currently being created, or who will subsequently manage its private key.

Nor should they have to make an expert decision about whether they need a synced or a device-bound passkey.

What is remarkable is that this decision became necessary in the first place.

An obvious default case could be very simple:

A user wants to authenticate with szegedi.info. Their device creates a key for that purpose. The private key remains under their control on their device.

Done.

No other party needs to be involved.

No additional trust relationship needs to arise.

And, most importantly, the user does not need to know anything about it.

This simplicity is surprisingly difficult to offer

Device-bound keys are by no means technically exotic. Corresponding authentication models exist and are used particularly in professional and enterprise environments.

But an ordinary website cannot simply offer its ordinary users an equally straightforward experience.

szegedi.info can use the standardized web interfaces and specify the necessary options.

What this becomes for the user is then determined to a significant extent by the browser, the operating system, and the credential providers available there.

And this creates a peculiar situation.

The companies whose products make these decisions are also the companies whose infrastructure is offered as the solution.

Apple does not merely develop an operating system and a browser through which passkeys can be used. Apple also provides the infrastructure in which these credentials can be managed and synchronized.

Comparable constellations exist with Google and Microsoft.

That alone proves no intent.

But it creates a structure that should at least be noticed.

Where does szegedi.info end?

For the user, this boundary is barely visible.

They are on szegedi.info and click, for example, “Add passkey.”

Then the browser takes over.

The operating system appears.

A credential provider is offered.

Perhaps a smartphone becomes involved, perhaps cloud synchronization, perhaps some other mechanism.

A technically experienced person can roughly recognize which component is making which decision.

Most users should not have to.

And that is precisely why this matters.

From their perspective, all of this is still happening at szegedi.info.

In reality, at a certain point szegedi.info has largely surrendered control over the process.

Not voluntarily.

But because, at precisely this point, the web depends on browsers and operating systems.

More security in exchange for less autonomy?

That description would also be wrong.

There is no necessary trade-off.

The passkey specification does not require the additional trust relationship.

Nor is the additional dependency the cryptographic price we have to pay for greater security.

It arises only from the concrete implementation of the specification in the products that stand between a website and its user.

And those products are predominantly made by some of the largest platform providers in the world.

That is what makes the price so difficult to recognize.

The additional dependency does not appear as an additional dependency.

It appears as convenience.

As synchronization.

As recovery.

As security.

There are good arguments for each of these things.

But none of them answers the question of why a technical possibility had to become an architecture in which additional centralized trust relationships are, in practice, the default for ordinary users.

Why does szegedi.info support passkeys anyway?

Because the technology is good.

Passkeys enable a form of authentication in which szegedi.info does not need to know a private key and should never know one.

I want to offer that possibility to the users of this platform.

But at present, I cannot simultaneously guarantee that no additional trust relationship will arise from it.

And there is something else I cannot do:

I cannot make that boundary completely visible to them.

The dialog that appears after clicking “Add passkey” may no longer belong to szegedi.info. Its design, its recommendations, and some of the dependencies created by it are beyond this platform’s control.

That is why this text is here.

Not as a warning against passkeys.

But as a reminder that even an open technical standard is not determined by its specification alone once it meets reality.

Between an open standard and a human being stand products.

And the manufacturers of those products can therefore exert considerable influence over how open an open standard ultimately feels.

Passkeys make authentication on szegedi.info more secure.

That is why they are available here.

The additional price is not necessary.

But at present, I can no more prevent you from paying it than I can reliably know how high that price may one day become for you.

That is why I call it:

unclear.