The Three Pillars of Decentralized Auth

Overview

For a long time, we’ve yearned for a truly decentralized authentication and authorization (auth) protocol. While OIDC and OAuth2 offer some degree of decentralization, they fall short in key areas. For example, service users typically cannot delegate specific permissions to others within a service with fine-grained control. Additionally, setting up a resource server and integrating it with OIDC and OAuth2 can be a complex and cumbersome process.

We asked ourselves, “Isn’t there a simpler, more decentralized approach?” After careful consideration, we developed a solution that leverages Decentralized Identifiers (DIDs), Verifiable Credentials (VCs), and User-Controlled Authorization Networks (UCANs) to create a robust, decentralized authentication protocol.

In this post, we’ll introduce these three foundational tools — the “three pillars” of decentralized auth — and explain how they can be combined to support a wide range of scenarios, all in a distributed and decentralized way.

Goals

Here are some key objectives of a decentralized authentication system:

1. No more passwords - Simply put, username and password combinations are not secure. It’s time to move away from relying on them to protect access and data in online systems. We need to provide solutions that are both easier and more secure for the end users of the systems we build.

2. Simple implementation - Setting up decentralized authentication must be easy and intuitive, or it simply won’t gain widespread adoption. Anyone who has set up an authentication server and navigated the complexities of OIDC or OAuth2 knows how challenging and time-consuming it can be. We’ve endured these headaches because, until now, they’ve been the only way to authenticate users and manage access across our apps and services. But it shouldn’t be this complicated. The goal is to create an elegant, minimalist process that securely authenticates users and grants them the appropriate access rights to services.

3. Inexpensive - User identification, authentication, and authorization are most effective when managed in small groups by the trusted network of individuals within each user’s communities. Becoming an identity provider should be straightforward and require minimal investment. The same principle applies to authenticating users and granting authorizations for your apps and services.

4. Give users options and freedom - Each user is unique and should have the freedom to choose the level of security that best suits their needs. For example, some users may prefer the convenience of regaining account access through an email reset, while others might disable this option to avoid relying on the security of their email provider. Users should also be able to delegate specific access rights to others, even to people who have never registered with the service. For instance, a user might want to grant a friend read-only access so they can monitor the service on their behalf. Traditionally, this would require sharing a password, which does not allow for fine-grained control over permissions. A robust decentralized authentication solution should enable users to grant precise permissions without ever needing to share their password.

5. Leverage web standards - Modern web browsers have advanced considerably in recent years. With the Web Crypto API, we can now generate and securely store cryptographic key pairs directly in the browser, enabling highly secure authentication. Whenever possible, we should take advantage of these built-in browser tools to make authentication both more secure and easier to implement.

Identity Precedes Auth

In the physical world, we carry wallets filled with various credentials that identify us in specific situations: a passport for crossing borders, a driver’s license for renting a car, a membership card for entering a gym, and a loyalty card for receiving discounts at a store. Each of these credentials serves to identify us to some extent and can be used in either limited or broader contexts. For example, a loyalty card may only be useful at one store, while a driver’s license can be used to rent a car, prove your age at a bar, or meet ID requirements when opening a bank account.

Before someone can be authenticated and authorized to take action, they first need to be identified. Many of us — especially those with the privilege of holding a passport — assume that identification is primarily the responsibility of governments. Online, we often believe that using a single credential to access multiple websites is only possible through major platforms like Google or Facebook.

However, instead of relying solely on governments or large tech companies, we can collaborate in small groups and define our identities in a more grassroots and privacy-focused manner. While this approach may not grant us access to cross borders or open bank accounts, it does allow us to organize and build trust networks in new and innovative ways.

Imagine being part of a group large enough — more than 150 individuals — that it makes sense to issue digital credentials to members, enabling them to easily identify themselves to one another. These credentials can also be presented to others as proof of group membership, whether interactions take place online or in person.

The 3 Pillars

Keys 🔑 (DIDs)

Identification relies on the assumption that each entity is unique and distinguishable. For humans, we recognize individuals by their appearance, voice, and other distinctive traits. These unique attributes are then captured and encoded into a credential. For example, a passport contains a photograph of the person to whom it is issued, along with other identifying information — such as their name, date of birth, and place of birth — which together make the passport unique to that individual. In the digital world, we currently rely on email addresses or accounts at online services to act as unique identifiers.

Cryptography enables the creation of unique identifiers on a large scale. An individual can generate public/private key pairs within a digital wallet, using a specific key pair to identify themselves to a particular group. It’s similar to having a keychain where each key unlocks a different door. In the case of public/private key pairs, each private key uniquely identifies the wallet holder to the group with access to the corresponding public key. If you are a member of 10 different groups, you hold 10 public/private key pairs in your digital wallet. You have a separate private key for each of those 10 groups and use the appropriate key to prove your identity to each group, whether you are present in person or connecting over a network.

This process of using your private key to prove your identity is called authentication. The group keeps your public key, which you provided from your digital wallet when you joined. They use this public key to verify a challenge they sent you, which you signed with your private key.

There are several methods for creating and issuing keys to individuals. In a decentralized authentication approach, individuals generate their own keys directly within their wallets and then share their public keys with the groups they wish to connect with. This is accomplished using Decentralized Identifiers (DIDs) that follow the did:key specification, which allows a cryptographic public key to be shared without relying on a centralized registry.

Credentials 🪪 (VCs)

After you have authenticated yourself to the group and they recognize you as the trusted member who joined them hours, days, or even years ago, the group can issue credentials that verify your membership. These credentials might specify your membership type or level, the duration of your membership, and possibly additional information such as your age, skills, or other relevant details.

These credentials are valuable because you can present them to other groups, institutions, or individuals to prove your membership status with a respected group. As a result, others may be more willing to share resources or grant you access to services based on your verified affiliation. We’re already familiar with interactions like these from everyday life — for example, gold status frequent flyers are allowed to board the plane first. However, when groups establish levels of trust with one another, these kinds of interactions can occur across different groups — not just within a single group.

Verifiable Credentials make these kinds of interactions possible both in person and online. They are designed to be cryptographically secure, privacy respecting, and machine-verifiable, ensuring that digital credentials can be trusted, easily shared, and automatically validated by systems and individuals alike.

VCs are built on top of public/private key pairs, because keys enable different types of interactions. They can be used for authentication when the private key holder signs a challenge, proving he is the owner of the public key linked to an account. But they can also be used to issue credentials when a group issues a credential to its member. The group signs the credential with its private key so anyone with the group’s public key can verify that credential was actually issued by the group. The person with the credential then signs a challenge with their private key proving they own the public key mentioned in the credential.

VCs fundamentally rely on public/private key cryptography to enable secure interactions through three core mechanisms:

1. Authentication via key ownership - A private key holder can authenticate by signing a cryptographic challenge, proving control of the public key linked to their account, eliminating the need for passwords or centralized identity providers.

2. Credential issuance with group authority - When a group issues a credential to a member:

   • The group signs the credential with its private key
   • Anyone with the group’s public key can verify the credential’s authenticity
   • The credential typically includes the member’s public key and attributes (e.g., membership status)

3. Credential Verification Through Dual Signatures - To use a credential:

   1. The credential holder signs a challenge with their private key, proving ownership of the public key embedded in the credential

   2. The verifier checks:

      • The group’s signature on the credential (using the group’s public key)
      • The holder’s signature on the challenge (using the holder’s public key)

This dual-signature approach creates an auditable chain of trust without relying on centralized authorities. The group acts as a decentralized issuer, while the cryptographic binding between keys and credentials prevents tampering or impersonation.

Permissions ✅ (UCANs)

After verifying your Verifiable Credential (VC), the service provider may grant permissions to you based on:

• Your group’s established trust relationship with theirs
• Your membership status
• Additional criteria like membership tenure

These permissions are assigned through User-Controlled Authorization Networks (UCANs), which operate differently from traditional OAuth 2.0 flows:

Aspect	OAuth 2.0 Approach	UCAN Approach
Token Type	Access Token (authorization only)	Combined capability token
Session Control	Requires separate session management	Built-in temporal permissions
Delegation	Limited via refresh tokens	Chainable proofs via prf field
Authority	Centralized authorization server	Decentralized cryptographic proofs

UCAN tokens encode permissions similarly to OAuth 2.0 access tokens but with key differences:

• Time-bound access: Like OAuth’s expires_in parameter, UCANs specify nbf (not before) and exp (expiry) timestamps
• Capability-based: Instead of OAuth scopes, UCANs use att (attenuations) field defining precise resource permissions
• Decentralized verification: Unlike OAuth’s centralized token validation, UCANs use cryptographic proofs (prf field)

The service owner determines trust parameters through:

• Group relationships (DID-based trust networks)
• Temporal constraints (e.g., 1-hour expiration)

This approach maintains OAuth-like temporal access control while eliminating reliance on centralized authorization servers.

Delegation in Access Control

Once you have been granted permissions to a resource (physical service, digital item, or location) you can delegate those permissions to another trusted individuals. For example:

As a group member with privileges at a bike-sharing service, you can temporarily delegate your bike-sharing access to a friend.

Under the terms of your group’s agreement with the service provider, you remain accountable for your friend’s actions while using the bike.

The key features of this permission delegation model include:

• Transitive Delegation: Permissions can be transferred without requiring centralized approval.
• Accountability Preservation: The original privilege holder (you) retains responsibility even after delegation.
• Granular Control: Specific rights (e.g., single-use bike access) can be delegated rather than full privileges.

This model aligns with decentralized authorization frameworks, where permissions flow through a chain of trust while maintaining clear accountability. For example, when User A (a group member) delegates access to User B (a friend, and not necessarily a member of the group), the service provider retains a cryptographic audit trail linking the delegated rights back to the original grant. Unlike traditional systems where delegation might obscure responsibility, this approach preserves a verifiable chain of custody-similar to how OAuth2 tracks token lineage through metadata like sub and aud claims, but without relying on centralized servers. The service provider can always trace permissions to their source, even as they propagate through multiple delegated relationships, all while enabling flexible resource sharing.

[This post is not finished but maybe we’ll get to it someday…]