What you get
A person signs in to your site with a key only they hold, made for your site alone. You receive an ordinary OpenID Connect ID token whose sub is that key, as a did:key. There's no client registration and no client secret: your client_id is your domain, and a small JSON file on it says where sign-ins may return.
- No user database at wellknown.id. It keeps no accounts, no names, no email addresses, and no record of who signed in where.
- A different key at every site. Two sites can't match their records of a person by key.
- Standard where it can be. Discovery, the authorization code flow with PKCE, ID tokens signed with published keys: a stock OpenID Connect library verifies them.
Where to start
- Getting started: sign-in in three steps, and verifying the token on your server.
- The web SDK: the button, its options and its events.
- How it works: per-site keys, personas, self-issued proofs, FedCM, and why the server keeps nothing worth stealing.
Reference
- OpenID Connect endpoints and tokens
- The /.well-known/id config
- Policies in karu
- The API reference, generated from the packages' doc comments.
Guides
- Accepting delegation, and running a mailbox
- Running a witness
- The wallet SDK and its ports
- Checking what wellknown.id serves
Status
wellknown.id is in development, in a preview: endpoints and formats may still change before launch. Each page says what works now and what's planned. The packages aren't published to npm yet; until they are, write to hello@wellknown.id for any file a page mentions.