triauth news

Keep the passkey, own the identifier

2026-10-19T00:00:00Z

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.

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 <--

Every sign-in, now encrypted

2026-10-14T00:00:00Z

Today we are releasing a significant privacy upgrade to the triauth protocol. Every answer that your authenticator sends to a website is now encrypted, and so is every request that a website makes after you sign in.

Why

When you sign in, your authenticator sends the website a signed answer. Until now, that answer traveled as plain text. A copy of it is of no use for signing in as you, but it shows your identifier, and servers, proxies, and error trackers often keep copies of what passes through them. Also, later requests, such as a document to sign, traveled the same way, and your browser kept them in its history in readable form.

Encrypted answers

Now your authenticator seals its answer with a cryptographic key, so that only the website that made the request can open and read it. Anything that logs the answer along the way sees only encrypted text.

One secret for everything after

The cryptographic process behind sealing and opening the answer gives the website and your authenticator the same secret, which they use to establish an encrypted channel between them. Every other operation that follows the sign-in is now encrypted with that secret. Your browser's history holds only encrypted text, so the documents that you sign and the attestations that you make stay private, and do not leak through the browser history to your other devices or to the browser's vendor.

What you need to do

Nothing, if you sign in with triauth. The hosted authenticator at auth.triauth.org has the upgrade. A website that updates may ask for your approval again at your next sign-in.

If you run a website with triauth, update to the latest triauth-js. The sign-in result now gives you a session key in place of tokens, and the stored challenge now holds the key that unlocks the answer, so keep it out of logs. See Sessions and sign-out and Extensions and permissions.

If you self-host the authenticator, update your copy. See Self-host the authenticator.

A more private web

Privacy is a part of how triauth is built, from identities that you own to records that show no more than you choose. This upgrade is one more step in that direction. We hope you enjoy it, and we would love to hear what you think.

Introducing triauth

2026-10-01T00:00:00Z

Today we are happy to announce the first public beta of triauth.

Over the past few months, we've been working hard to create a simple yet robust authentication protocol that lets users sign in to websites with a single domain-based identifier that they control, and maintain self-sovereignty in an increasingly centralized online world.

Thanks to this effort triauth was born. You can take it for a test drive today and discover how authentication should have always worked on the web.

> Get started with your first triauth identifier

> Integrate triauth with your website

> Learn more about triauth