What is decentralized identity? What’s the current state of it? How could it be improved?

What is decentralized identity?

I see decentralized identity basically as Single-Sign-On, but you aren’t tied to certain providers supported by the client. Many places have “Sign in with GitHub” or “Sign in with Google” buttons, but what if you don’t want to be tied to GitHub or Google?

Anyone should be able to choose whichever identity provider they like, and they should be able to host their own one, if they wish to.

Your online identity should be portable. You should be able to trivially move your identity from one provider to another, without affecting your data on any of your clients.

Current state of decentralized identity

OpenID Connect

I’m just gonna quote the OpenID Connect Core specification on what OpenID Connect is:

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.

OpenID Connect Discovery builds on top of that, adding:

1. Issuer discovery using WebFinger
   It lets a client look up user identity like joe@example.com and find out who the OIDC issuer is for that identity.
2. Provider metadata
   The OIDC Core specification doesn’t define fixed paths for OIDC endpoints, they must be previously negotiated out-of-band. OIDC Discovery lets clients look up a JSON document at /.well-known/openid-configuration to get all metadata about the identity provider that is needed for performing authentication.

We also need OpenID Connect Dynamic Client Registration so that we can register a new client at the OIDC server and get our Client ID and Client Secret.

In reality, OIDC Dynamic Client Registration is rarely implemented because identity providers prefer doing client registration out-of-band (for example an admin UI).

IndieAuth

Quick sidenote: if you want to know more about IndieAuth and it’s design then Aaron Parecki has written an excellent blog post about it

Just as OIDC, IndieAuth is also based on OAuth2. The main difference between the two is that IndieAuth doesn’t require client registration. App URL is used as Client ID, redirect URI is validated based on the App URL/Client ID. Information about the client (icon, name) is parsed from the HTML response of App URL.

Issues

Both OIDC and IndieAuth are lacking in the “portable identity” category. If you log in using OIDC, your identity is tied to the provider that you signed in with. With IndieAuth, your identity is actually portable, but only as long as you have your own domain (which many people don’t have!).

What it could be like…

So how do we make identities portable? With ✨ public-key cryptography ✨.

Each user (identity) could have an unique Ed25519 keypair and identities would be globally identified by their public key. The user’s identity provider knows the private key, and would assert their legitimacy by signing a nonce using the private key on authentication.

If you want to switch providers, you could just export your private key from provider A and import it to provider B. Because the keypair doesn’t change, identity remains the same.

This does put a lot of trust on providers though. A rogue identity provider could run away with your private key and pretend to be you (although, right now, any SSO provider you log in with could do the same). Maybe you can solve this problem somehow, I’m not sure.

OK but, how would a client figure out who is the user’s identity provider? I have 2 ideas right now:

1. The Fediverse Style - let users have an “alias” at the IdP, like bob@example.com. The client would authenticate using example.com, the IdP performs authentication and asserts that bob corresponds to identity hSDwCYkwp1R0i33ctD73Wg2/Og0mOBr066SpjqqbTmo=
2. The IndieAuth Style - let users enter identity provider URL, client redirects to the IdP, user logs in, IdP redirects back to client with assertion that the user logged in as identity hSDwCYkwp1R0i33ctD73Wg2/Og0mOBr066SpjqqbTmo=

It should be possible for users to have a profile consisting of at least nickname and profile picture, that clients can use displaying information about the user.

Glossary

• IdP - identity provider, the party that authenticates the user
• OIDC - OpenID Connect