Why identity needs an open protocol

If HTTP had been locked behind a bank, the web wouldn't exist.

That sentence sits over my desk. It is the shortest way I know to explain what UIP is trying to be. The web works because nobody owns its primitives. Anyone can speak HTTP. Anyone can serve a page. Anyone can link to anyone else's. The whole edifice — the trillions of dollars of commerce, the entire knowledge graph of humanity — sits on a few small, boring, open protocols that nobody can revoke.

Identity does not work this way. Identity, today, is a patchwork of closed schemes — controlled by banks in some countries, by governments in others, by platforms everywhere. Each of them works, in isolation, well enough. None of them compose. None of them cross borders. None of them are open to a developer who wants to ship something on a weekend.

This is the gap UIP exists to close.

The two failure modes of identity on the web

There are, very roughly, two ways identity is solved on the internet today, and both of them are broken in instructive ways.

The first is passwords plus form fields. This is what most of the consumer web still runs on. A user types their name, address, date of birth, and government ID number into a form, the business stores it in a database, and the two of them agree to pretend that this constitutes verification. It doesn't. The data is unverified, the database is a breach waiting to happen, and the user has to retype the same fifteen fields on every new service they touch.

The second is national schemes — BankID in Sweden, iDIN in the Netherlands, ID.me in the US, Aadhaar in India. These are real. They actually verify identity. But they are also closed: each one is operated by a small cartel of banks or a government agency, priced at enterprise rates, and unavailable outside its home jurisdiction. A Swedish startup cannot accept a Dutch user's iDIN. A Dutch business cannot accept a Swedish user's BankID. The systems are excellent within their walls, and useless outside them.

Neither of these is a protocol. Both are platforms — and the distinction matters more than it sounds.

Protocols vs. platforms

A platform is something you build on top of, with permission. A protocol is something you speak, without asking.

Email is a protocol. Twitter is a platform. HTTP is a protocol. AWS is a platform. The difference shows up most clearly when something goes wrong: when a platform changes the rules, your business is at the mercy of someone else's roadmap. When a protocol changes, you can fork it.

For identity to matter on the web the way HTTP mattered for documents, it has to be a protocol. That means:

• A small, stable surface. Three verbs, not three hundred. The semantics shouldn't drift between releases.
• No gatekeeper. Anyone can integrate. Anyone can run their own infrastructure if they want to.
• Cryptographic, not contractual. Trust comes from keys and signatures, not from being on someone's allowlist.

UIP is built around three primitives — identify, sign, message — and that's it. The entire API surface fits on a postcard. Every operation returns a permanent reference ID. Every webhook callback is signed. There is nothing proprietary to lock you into, because there is nothing proprietary in the first place.

What "open" actually buys you

The argument for openness is usually made on principle, which is fine, but the practical case is stronger. Open protocols are cheaper, faster to integrate, and far more durable than closed platforms — for three concrete reasons.

They have no per-integration negotiation. With a closed scheme, every new business that wants to accept verifications signs a contract, pays a setup fee, and waits weeks for provisioning. With an open protocol, you read the docs and ship the same afternoon.

They survive their original sponsors. SMTP outlived the companies that wrote it. HTTP outlived NCSA Mosaic. A protocol that anyone can implement does not depend on the continued goodwill of its first vendor. This matters for identity, where credentials need to outlive both the issuer and the verifier.

They compose. A protocol-shaped identity layer plugs into other protocol-shaped pieces — payments, messaging, signatures — without bespoke glue. The same UIP credential that signs a contract in one workflow can authenticate a session in another and decrypt a message in a third.

The closed-scheme argument has always been that the rigor of verification justifies the closure: only a bank, or a government, can be trusted to do this properly. UIP's answer is that the rigor doesn't have to live with the gatekeeper. It can live with the user — in a biometric keypair, in a secure enclave, anchored to a real document. The verification is just as strong. The substrate is open.

What we're building toward

A world where verified identity is something you have, not something a third party tells you about. Where a credential issued in Stockholm works in São Paulo without anyone renegotiating anything. Where a developer in Lagos can stand up an identity-aware product over a weekend, on the same terms as a developer in San Francisco.

This is not a small ambition, and it will not happen on its own. National schemes will not voluntarily federate. Platforms will not voluntarily open up. The way protocols win is the way they have always won — one small, useful integration at a time, until the closed alternatives look slow and parochial by comparison.

That is the bet UIP is making. If you are building something that needs verified identity, we'd like you to make it with us.

---

If you want to follow along — or argue with the premise — the docs are the best place to start, and the pricing page is the most honest description of what running this actually costs.