Public View

Universal Identity System

The Universal Identity System is a proposed architecture for frictionless cross-site authentication. The core problem: different websites should immediately know who you are without repeated login flows.

The Problem

Authentication across many sites is unnecessarily repetitive. Users face login friction on every new service. Browsers intentionally prevent cross-domain tracking for privacy and security, third-party cookies are being phased out, and mobile browsers do not support extensions. An ideal solution must also be recoverable if keys are lost and require no per-domain manual action.

The proposed solution uses a central identity domain (e.g., tmad4000.github.io/whoami) as a lightweight identity hub:

  1. Daily flow: Sites check localStorage for an identity token. If absent, a "Verify yourself" button redirects to the central domain where the user is already authenticated via cookie. The central domain redirects back with a token that the site stores locally. One click, no typing, works on mobile.

  2. New device setup ("Omni-Link"): A setup page at the central domain knows all registered sites. It rapidly opens each site with an auth token in the URL via popups. Each site stores the token and closes the popup, configuring all sites in seconds.

Site Integration

Integration would be minimal — a JavaScript snippet that listens for a whoami-response event and dispatches a whoami-request event. Any site that adds the snippet can participate in the identity network.

Landscape Analysis

Solution Limitation
DID Wallet extensions Crypto-focused, lose keys = lose identity
IndieAuth Requires per-site auth action
WebAuthn/Passkeys Per-site, not broadcast identity
FedCM (Chrome) Still evolving, requires site adoption

The identified gap: nobody has built a simple system where you log in once (with Google or a normal password) and it broadcasts identity to any site that asks, with recovery if you lose access.

Open Questions

  • Token revocation if compromised
  • Identity payload beyond name and email
  • Making the Omni-Link popup flow feel non-intrusive
  • Using passkeys as the underlying auth for the central domain

Status

Idea stage. Next steps would include building the central identity page, the redirect verification flow, the Omni-Link batch setup, and a JavaScript snippet for site integration.


Source: Brainstorm, December 2024

[[curator]]
I'm the Curator. I can help you navigate, organize, and curate this wiki. What would you like to do?