Keep the passkey, own the identifier

Last week Hacker News argued over Passkeys are a trap and Passkeys are not a trap, in 1,300+ comments across two threads. Under the noise, both sides seem to agree on one thing. The key part in pass·key is good. The key cannot be guessed, it signs without a secret to type, and it refuses to work on a lookalike site. The fight was about everything around the key, from confusing naming and poor portability to vendor lock-in and the poor UI of websites that implement them.

So what do people want? One commenter wrote that passkeys "should be cattle, not pets". Another wanted "SSH keys but with added website verification". Others asked for no vendor attestation, cross-platform support, revocation everywhere, sharing with a spouse, and phishing resistance.

The list reads like a description of triauth 👋

Triauth keeps your passkeys and gives them an identifier at your own domain that you can use across the web, with one place to manage and revoke your keys, and a common way to sign in to websites.

Making a passkey truly yours ​

In triauth, a device can have a passkey as one of its keys. You list it in DNS, and authenticate to websites with it.

For example, the DNS record that binds john@example.com to his passkey may look like this:

john._at.example.com.   TXT   "key laptop[2/2]:BLstmtxB6ceFUwjORLMlWfFmZ9XtqMQeUGs5iaCXkCQVUh-l… type=webauthn-es256"

With it, and the associated passkey, John can sign in as john@example.com from his laptop to every website that supports triauth. If he ever loses his laptop, he deletes this record. The laptop can no longer sign in anywhere, because its key is gone from DNS. Websites that re-check sessions also end any open sessions at their next check. There is nothing to export, back up, or restore, because the identity was never on the device. It is in the domain.

One passkey, every website ​

In triauth there is no per-website enrollment. A website reads whatever your DNS lists, so a second device is one more record, not a tour of every account you have. You choose where the passkey is kept once, at device setup, and not every time you sign up to websites.

Sharing without a copy ​

Copying or sharing passkeys is a hassle, but not with triauth. If you want to share your account with a spouse or an assistant, that's just one DNS record away.

You publish a DNS record naming the other identity and the websites it may use as you:

john._at.example.com.   TXT   "include jane@example.com scope=website.example.com"

They sign with their own keys, the website sees who acted, and deleting the record ends it.

No traps, no vendor lock-in ​

Last but not least, the first article's top worry is that you do not have ultimate control over your passkeys, because behind them stands a consortium of organizations serving their own interests.

With triauth you regain that control.

By design the triauth protocol is decentralized, and your identity lives in your own domain. You declare what devices you have and how they authenticate as you. As far as passkeys are concerned, you can swap one passkey for another at any time, or skip passkeys altogether and sign in with a browser key or a security key.

Get started ​

If you own a domain, set up your identity in about ten minutes, and add a passkey when the setup asks how you want to sign in. If you build a website, npm install triauth and add sign-in in about thirty lines. If you would rather not trust our copy of the authenticator, host it yourself.

Triauth has just launched, and the list of websites that accept it is still short. But the goal is noble, and we are working hard to bring decentralized, passwordless sign-in to the whole web. That takes websites that accept it and readers who try it. You can start either this week.

Try it, and tell us what you think 🧪

--> Get started <--