In 2005, a question was going around the identity community that felt almost philosophical: who owns your identity online? The answer, at the time, was mostly “your service provider.” You had a Yahoo account, a Google account, a bank account. Each was a separate silo. You logged in separately, with a separate password, and the site knew only what you had told it directly.
The Identity 2.0 movement — this site’s original mandate — was a technical and philosophical response to that fragmentation. The proposal was user-centric identity: you carry a single credential, you decide what gets shared with whom, and no single company controls the infrastructure. OpenID was the main protocol. SXIP was another attempt. The vision was decentralized, portable, user-controlled.
That vision mostly lost. And understanding why it lost explains a great deal about the privacy crisis that followed.
The User-Centric Promise
The core idea behind user-centric identity was straightforward. Instead of creating a separate account on every website, you would authenticate through an identity provider of your choice — one you trusted, one that could be changed or replaced. The website (called a “relying party”) would get only the claims it needed: your age bracket, perhaps, or your email address, or just a confirmation that you are a verified human.
OpenID let you use a URL as your identity. Type your OpenID into a login box, get redirected to your provider, confirm the login, come back. That was the theory. The practice was rougher — the UX was confusing, different sites implemented it inconsistently, and the average user had no mental model for “my identity lives at myopenid.com.”
But the underlying principle was sound. Identity data should be held by the entity the user chooses. Attributes should be disclosed minimally. No single intermediary should aggregate the full picture of your online activity.
Where Facebook Connect Changed Everything
Facebook Connect launched in 2008 and offered something OpenID could not: a frictionless experience that most users already understood. Click the familiar blue button, confirm on Facebook, return to the site. No URL to type, no concept to explain. The social graph came with it, which meant instant personalization. For site developers, the integration was clean and well-documented.
The trade-off was obvious but easy to ignore: every site that adopted Facebook Connect was now reporting back to Facebook. Not explicitly — Facebook did not sell the data — but the authentication flow itself told Facebook which third-party sites you visited, when, and how often. Your identity was now a surveillance instrument.
The comparison between Passport, OpenID, and Facebook Connect was being written in real time. Passport failed because Microsoft centralized too aggressively and too visibly. OpenID was decentralized but confusing. Facebook Connect was centralized but felt like a user benefit. The market chose the third option overwhelmingly.
The concern at the time was that Facebook Connect dealt a near-fatal blow to the user-centric identity movement. That turned out to be accurate. OpenID 2.0 was never widely adopted as a consumer product. OAuth evolved separately into an authorization protocol (which is a different thing), and “Sign in with Google / Apple / Facebook” became the practical answer to the login problem — each one a centralized identity silo, exactly what the original movement was designed to prevent.
The Surveillance Architecture That Followed
The failure of user-centric identity left a vacuum, and it was filled in two directions simultaneously.
First, login consolidation around a few large providers: Google, Facebook, Apple. Your “identity” for most of the web is now mediated by one of these three. This is the direct descendant of the Passport problem, now at a scale Passport never achieved.
Second, and more consequentially for the privacy picture: tracking without authentication. You do not need to log in for a website to build a profile of you. Third-party cookies, device fingerprinting, cross-site tracking pixels, and advertising network IDs created a parallel identity infrastructure that runs below the surface of every page load. This system has no login screen. You never consented to it. It simply operates.
This is the layer that GDPR, ePrivacy, CCPA, and the wave of privacy legislation since 2018 is aimed at. The privacy law conversation is, at its core, the user-centric identity conversation — but arrived at from the enforcement direction rather than the design direction.
User-Centric Identity vs. Consent-Era Reality: What Changed
| Dimension | Identity 2.0 Vision (2005) | Consent Era Reality (today) |
|---|---|---|
| Who holds your identity | You, through a provider you choose | Google, Apple, or Facebook — for logins; ad networks for tracking |
| Attribute disclosure | Minimal, user-controlled, claim-by-claim | Bundled data sharing via login; parallel tracking regardless of login |
| User understanding | Assumed as design goal | Replaced by consent banners; legal compliance ≠ genuine understanding |
| Control mechanism | Technical (protocol-level) | Legal (regulation + consent UI) |
| Central authority | None by design | A handful of platforms + national DPAs enforcing after the fact |
| What “logout” means | Session ends, no residual data | Session ends, but tracking profiles persist indefinitely |
The most striking column is the last one. In 2005, the assumption was that identity was something you actively asserted. You logged in. You made claims. You logged out. The idea that your identity — or something functionally equivalent to it — could be continuously assembled from your browsing behavior, without any login event, was not the primary threat model. It became the dominant one.
Consent as the New Login Screen
GDPR came into force in 2018. The practical effect on most websites was the appearance of the consent banner. Before you can use the site, you must click something. This is, in a very real sense, the login screen that user-centric identity was trying to design — except it comes after the page has already loaded, after the tracking scripts are already queued to fire, and with a user interface that is frequently engineered to maximize acceptance rather than genuine choice.
The parallel to the SSO debate is uncomfortable. The value of single sign-on to real users was always about reducing friction while preserving meaningful control. Consent banners in their current form do the opposite: they add friction to the surface while the meaningful control — over what data is collected, how it is processed, who it is shared with — remains buried or absent.
The legal requirements are real and, in some jurisdictions, well-enforced. But legal compliance and user empowerment are not the same thing. A consent banner with a small gray “Reject All” link and a large yellow “Accept All” button technically satisfies the regulation. It does not satisfy the principle.
What Tracking Actually Builds
It is worth being specific about what the consent-era tracking infrastructure creates. This is not a vague “your data is collected” situation. The actual outputs are:
- Cross-site behavioral profiles — a record of which sites you visited, in what sequence, at what times, over months or years, assembled by advertising networks whose pixels appear on millions of sites.
- Probabilistic identity graphs — your email address, hashed, matched against purchase data, matched against offline records, matched against your IP history, to create a persistent identifier that survives cookie deletion.
- Inferred attributes — health conditions, political orientation, financial stress, relationship status — derived from behavioral signals and used for ad targeting without your knowledge.
- Real-time bidding dossiers — in the milliseconds before an ad loads, your profile is broadcast to dozens of bidders — with no technical guarantee that the losing bidders ever discard the data used in the bid.
This is what “your identity online” means in practice today. It is far more detailed and more invasive than anything the Identity 2.0 era was imagining, and it was built without any authentication protocol at all — purely through observation and inference.
The Answer That Did Not Scale
One reason to revisit this history carefully is to understand why good technical ideas can fail to prevent bad outcomes. User-centric identity was a sound design. The protocols were functional. The principles were right. It lost anyway — not because it was wrong, but because the competing option (centralized social login) was more convenient, and because the real surveillance architecture bypassed the login layer entirely.
This matters for evaluating current privacy solutions. Consent management platforms, privacy-first analytics tools, cookie audits — all of these address real parts of the problem. None of them, individually, solves the structural issue, which is that identity data is economically valuable and the incentives to collect it are strong. Technical and legal interventions shift the boundary; they do not dissolve the pressure.
That said, the interventions are not useless. Accurate consent infrastructure matters. Knowing what your site actually sends to third parties matters. The gap between “we have a consent banner” and “we understand our data flows” is where most organizations are currently sitting, and closing that gap is the practical work.
What to Do With This
If you run a website today, the useful inheritance from the Identity 2.0 conversation is the underlying question: does the user actually control what happens to their identity data on your site?
Not legally — though that is the minimum bar. Actually. Does your consent banner block all tracking before consent is given? Are you using third-party login providers whose authentication flows feed back to their own tracking infrastructure? Do you know what data your analytics stack sends to servers outside your control?
These are the same questions from 2005, translated into current infrastructure. The answers require auditing your actual implementation, not your privacy policy. If you are not sure what your site requires, the consent requirements wizard gives you a jurisdiction-specific starting point — which consent types you need, what your banner must include, and what the regulation says about rejection.
The principles from the Identity 2.0 era — minimal disclosure, user control, no unnecessary intermediaries — remain correct. The fight is now on the legal and technical compliance layer rather than the protocol layer. But the question underneath has not changed.
The Unfinished Conversation
Dick Hardt closed this site in 2010. The headline of his final post was “No More Microsoft Dick, No More Identity 2.0.” The user-centric identity project was set aside. The web moved on toward social login and behavioral tracking, and the consequences took another decade to become visible enough to generate a legal response.
What the original Identity 2.0 project understood correctly was that identity infrastructure is power infrastructure. Whoever controls the layer that authenticates you online, or that builds a profile of you without authenticating you at all, holds a kind of authority over your participation in digital life. That authority is now distributed differently than the 2005 vision intended — across a few large platforms, a global advertising technology stack, and a growing body of privacy law trying to constrain both.
The conversation is not finished. It just moved to a different room.