Thread by @patio11

Continuing with our launches this month, Stripe Identity.

When I was first exposed to the Internet in the late 90s, it was an open question whether we'd ever come up with a way to demonstrate identity over the Internet.

https://twitter.com/stripe/status/1404443523680673793

Every business transacting online ends up building this, as a primitive. Almost every implementation is wrong. (Just zooming in on names: I still wonder whether any system anywhere handles names correctly, 10 years after writing about that.)

And we muddle along. But why?

This is a field where the topic benefits both from domain expertise but, even more, from a network advantage. Assuming a customer *wants* to tell a business "Yes, this is really me, trust me", it is in their interest to be able to pull in experiences w/ other businesses.

That largely doesn't happen in the status quo, partially because it requires cooperation between businesses which are not fundamentally in the identity business, and partially because previous attempts at solving identity at economywide scale (e.g. credit reporting) are... yeah.

So how is Stripe Identity different?

One, we're built in an era which has cell phone cameras and not fax machines as the primary way of transmitting pixel-based data, and we can take advantage of that in designing the UX. It's fast and easy (doesn't cost conversions).

Two, we've got a more modern understanding of privacy baked into it from the ground up.

The user has a very clear understanding of what is being shared, and a business can rely on e.g. their history with other businesses *without learning about those relationships.*

(This also helps to firewall businesses away from information they'd rather not have. Many companies have asked to see my passport at some time or another. Very few *actually want* a copy of it; that is just asking to get leaked later. Identity helps them implement verify/forget)

Three, taking advantage of the network effects of the Internet economy lets you use much more tailored levels of friction depending on business requirements, perceived level of risk, and acceptable impact on conversion.

This lets you create a sliding scale of certainty.

You can imagine, for example, that many businesses told "I'm patio11" care primarily "I really just need to know that this is a unique-ish human not the 1,500th alter ego of a bad actor; I'm pretty ambivalent to who it is."

And for them, minimal user interaction might be fine.

An e-commerce company might want to verify my shipping address (to minimize ops problems) but not want to take the conversion hit associated with scanning an ID, so a certainty score about it helps them do that and maybe kick anomalies to a second verification or to staff.

And then an insurance provider might say "Sorry, hard Compliance requirement, we *have* to see a government-issued ID from this list and we have to log the fact that we saw it and the following bits of information from the ID."

Stripe Identity gives building blocks for all 3.

This is, as you'd imagine, a problem Stripe has spent an awful lot of work on internally (and continues to do so).

Users get to benefit from our ability to hit edge cases before they do. And boy oh boy, do we get a brisk tour of the global economy.

Do you want to design an identity verification flow which will handle the owner of a Japanese LLC doing business in the U.S.? We already had to do that; freeride on our work.

(I am probably not the only Stripe customer with that fact pattern.)