PLANET Research – Decentralized Auth Solutions

TL;DR

• From Centralized SSO to Decentralized Auth: Traditional Single Sign-On (SSO) solutions are complex and create single points of failure. Decentralized authentication and authorization offers self-sovereign identity, reducing reliance on central authorities while enhancing security and user control.
• Choosing the Right Decentralized Auth Solution: PLANET requires a highly decentralized, scalable and cost-effective framework that simplifies user authentication and authorization across services without the complexity of traditional SSO infrastructure.
• DID/UCAN for PLANET: After reviewing several authentication and authorization frameworks, we have concluded that the User Controlled Access Networks (UCAN) protocol meets all of our requirements for decentralized, capability-based access control management, allowing groups to set permissions and manage user access without relying on a centralized service. Coupled with Decentralized Identifiers (DIDs), they provide a robust solution for user authentication and authorization across a wide range of services without creating a single point of failure.

Introduction

PLANET will eventually offer a variety of functionality, so from a systems architecture point of view it makes sense to connect many different services together (i.e., the modular architecture approach) rather than create a single service that attempts to do everything: the classic “monolith” which eventually becomes unwieldy and has to be broken down into smaller pieces in order for the whole system to grow in size and scope. A major side benefit of this modular approach is to be able to leverage existing software rather than having to build from scratch. One of the design goals is to only build a service if we can’t find an existing one that meets our requirements.

To connect multiple services effectively and make them homogeneous to the user, the foundational service of PLANET must be an identity authentication and role authorization service. In other words, there needs to be a way to identify users and then assign them access rights to all of the other services. Another design goal is that users need only login once to their group in order to have access to everything in the PLANET ecosystem of services for their group.

The way this is usually achieved is known as single sign-on (SSO) and is managed through a centralized service which acts as a gatekeeper to all of the other services. Centralized SSO servers operate on a model where a single authority manages user identities and authentication. This central hub authenticates users and issues tokens for accessing multiple services. 

Anyone who has ever used a Google account and accessed Google services is using SSO to authenticate and be assigned access rights to those services (Gmail, Google Drive, YouTube, etc.). Google account owners are probably also familiar with the ability to use their Google identity to log into third party websites. These technologies are known as OIDC and OAuth2. In general, OIDC mainly occupies itself with authentication of the user (i.e., confirming their identity, particularly to third parties) and OAuth2 with the authorization of the user (i.e., confirming the roles and rights the user has with each of the services to be accessed). The main point to remember is that SSO – and identity verification and access control systems in general – encapsulates two distinct concepts: authentication (who are you?) and authorization (what can you do?).

A major disadvantage of a centralized SSO service is when it goes offline, access to all of the other services is not possible. In other words, when the gatekeeper is not there, the gate is locked and you can’t get in. Also the SSO provider typically owns and controls user identity and access data. Users rely on this central authority for authentication and authorization, across multiple different services and possibly for authentication even in multiple (third-party) domains. If you lose access to your SSO account, you are potentially locked out of a large number of services. In other words, if you use Facebook to login to other websites, if your Facebook account is hacked, you will lose access not only to Facebook but all of those other sites as well.

Given that another one of our technical design goals for PLANET is to strive for a decentralized and distributed architecture, we have reviewed several existing authentication and authorization solutions that are less centralized. One of the most prominent technologies that is an alternative to centralized SSO for authentication are Decentralized Identifier (DID) frameworks. As the name suggests, DID frameworks are designed to be decentralized, allowing individuals to create and control their own identifiers without relying on a central authority. DIDs embody the principle of self-sovereign identity, giving users control over their digital identities and how their information is shared.

Centralized SSO

Given that centralized SSO is the standard identity verification protocol on the Internet today, let’s start by looking at how it works. Although it is a robust solution that can work at scale (Google, Facebook, etc. handle 100s of millions of users), it is not necessarily simple to implement and has many moving parts.

We looked into what it would take to set up our own SSO solution. There are many components out there that enable us to build one without writing code from scratch, but the configuration is hard. Also, standard procedures like adding new users and assigning them rights to the various services requires further configuration and integration work if that process is to be automated. And there are several components that make up a typical SSO solution that need to be learned, set up and then connected together:

• Auth server – handles the authentication and (sometimes) authorization of users (e.g., Authelia, Keycloak)
• Reverse proxy – intercepts traffic to the various services that need authentication and hands them over to the auth server (e.g., Traefik, Nginx)
• LDAP server – the lightweight directory access protocol server that contains user credentials for authentication/authorization (e.g., OpenLDAP)
• Session provider – manages and persists details of user sessions to services for authenticated users (e.g., Redis)
• Storage provider – manages and persists details of users to auth and LDAP servers,, stored in encrypted format for security, and needs to be stored for long periods of time (e.g., PostgreSQL, MySQL)
• Notification provider – manages notifications to users for password resets, etc. (e.g., SMTP mail service)

These six different components need to be orchestrated together when a user tries to access a service. The user’s request first goes to the reverse proxy, which sees that the user has not been authenticated so the user is redirected to the auth server. The user then enters his credentials (username/password) which are then verified via the LDAP server in communication with the storage provider. If the user has valid credentials, a token is issued to the user and recorded in the session provider so that the user can access the service by giving the service the token. The service must also validate the token before giving the user access. Finally, the notification provider is there to send email notifications to the user when needed.

Aside from orchestrating all of these components together, they must also be configured correctly to ensure they are secure and that malicious users can’t bypass the auth server and access the protected services directly, steal the user data from the session or storage providers, etc. In other words, there is a significant amount of time involved in learning how to properly configure the components. Also, logging should be enabled for all of them and then regularly reviewed to ensure the auth system is working correctly.

Finally, these centralized SSO solutions are difficult to scale, especially as more services are added into the mix, since the access controls must be actively maintained and then synchronised between the services and the auth server. Overall, a comprehensive centralized SSO solution is a mammoth effort and not to be undertaken lightly. 

The ideal solution would remove the single points of failure of the auth, LDAP and reverse proxy servers while making the configuration of user authentication and authorization to each service simple and granular.

Decentralized Identifier (DID) Types

The main purpose of a DID is to authenticate a user to one or more services without relying on a centralized identity provider. There are several types of Decentralized Identifier (DID) solutions, each designed for specific use cases and technical requirements. These methods differ in their underlying infrastructure, scalability, decentralization and integration complexity. Following is a breakdown of the main types and their characteristics:

1. Ledger-Based DIDs

• Examples: did:ethr (Ethereum), did:btcr (Bitcoin)
• Rely on public blockchains for anchoring and managing DIDs
• Pros: High decentralization, immutable records, strong cryptographic security
• Cons: Scalability challenges due to blockchain limitations (e.g., gas fees, transaction speed)

2. Ledger Middleware (“Layer 2”) DIDs

• Examples: did:ion (Bitcoin + IPFS/Sidetree)
• Combine blockchain with off-chain storage (e.g., IPFS, Distributed Hash Tables) to reduce costs and improve scalability
• Pros: Balances decentralization with efficiency; batches operations to minimize on-chain transactions
• Cons: Increased complexity in setup and maintenance

3. Peer DIDs

• Designed for closed groups or private networks
• Pros: Privacy-focused, no reliance on external ledgers
• Cons: Limited to specific ecosystems, not globally resolvable

4. Self-Contained DIDs

• Examples: did:key
• Derived directly from cryptographic key pairs without external infrastructure
• Pros: Stateless, portable, and simple to implement
• Cons: No built-in key rotation or recovery mechanisms

5. Web-Based DIDs

• Examples: did:web
• Anchor DIDs to domain names via DNS and HTTPS.
• Pros: Easy integration with existing web infrastructure
• Cons: Centralized dependencies (domain ownership, DNS)

Comparison of Popular Decentralized Identifiers

Method	Infrastructure / Blockchain	Key Features	Use Cases	Decentralization	Scalability
did:ethr	Ethereum	Smart contracts, key rotation	Web3 apps, DeFi	High	Medium (L2 helps)
did:ion	Bitcoin (anchoring only)	IPFS/Sidetree, high throughput	Scalable identity systems	High	High (complex)
did:key	None (self-contained)	Offline use, minimal dependencies	Local-first apps, distributed services	High	High
did:web	Web domains	Leverages DNS & HTTPS protocols	Organizational identity	Low	High
did:sov	Hyperledger Indy	Privacy-preserving, compliance focused	Enterprise, regulated businesses	Medium (permissioned)	Moderate

Key Trade-offs

• Decentralization vs. Scalability: Blockchain-based methods (did:ethr, did:ion) offer strong decentralization but face scalability challenges, Layer-2 solutions like did:ion mitigate this with off-chain storage but are more complex to implement
• Simplicity vs. Functionality: did:key and did:web are easy to implement but lack advanced features like key rotation and recovery (though solutions for them can be implemented)
• Cost: Blockchain-based DIDs all incur costs of varying degrees

Security and Integration Considerations

• Key Management:
  • did:ethr supports smart contract-based recovery
  • did:key relies solely on cryptographic key pairs
• Development Complexity:
  • did:ion and did:sov require significant effort to integrate
  • did:web and did:key are simpler to adopt

Choosing the Right Decentralized Identifiers for PLANET

The following general factors to prioritize a DID framework for PLANET are as follows (in order of importance):

1. Decentralized: Must be a highly decentralized solution to ensure maximum control for groups and end users
2. Configurable: Group admins should be able compose on top of the DID to manage user roles for each service
3. Scalable: Solution should be scalable for a large number of services and users
4. Cost: Setup and ongoing costs should be low, which implies a simple architecture (avoid 6 components like for centralized SSO)

Review of some existing Decentralized Auth solutions

We have reviewed several existing decentralized solutions (mostly DID frameworks) with a view toward finding one that enables PLANET users to easily use DIDs for authentification while decentralizing the creation and management of them. Importantly, the optimal solution will also enable simple and scalable assignment of access rights to those DIDs to the various PLANET services in a decentralized manner, so as to avoid the need to manage the equivalent of centralized SSO infrastructure.

Therefore, the ideal solution for PLANET is a DID framework that enables both authentication of users while also working well with a decentralized access control solution for the various PLANET services those users access.

AT Protocol DIDs

AT Protocol uses Decentralized Identifiers (DIDs) as persistent account identifiers, with a custom DID method called “did:plc” (DID Placeholder). AT Protocol’s DIDs are resolved to DID documents containing the user’s current handle and public signing key, enabling consistent identity across platforms without relying on blockchain technology.

Summary: AT Protocol’s DIDs focus on authentication rather than authorization. Also, ATProto relies on a central DID directory, creating a major single point of failure.

DIDComm (Decentralized Identity Communication)

DIDComm is an open protocol for decentralized communication that uses Decentralized Identifiers (DIDs) to establish confidential, ongoing connections without relying on usernames and passwords. It provides a secure, private communication methodology built on the decentralized design of DIDs, enabling direct, encrypted communication between DID owners across various transport methods. DIDComm allows for the creation of higher-order protocols that inherit its security, privacy, and decentralization features, making it suitable for a wide range of applications from verifiable credential exchanges to complex business interactions.

Summary: DIDComm focuses on secure communication channels rather than authorization and capability delegation.

DID Web

DID Web (did:web) is a decentralized identifier method that uses traditional web infrastructure to publish and resolve DIDs. It creates DIDs anchored in common web domains, linking the trustworthiness of existing domains to their associated DIDs. The method translates DIDs into HTTPS URLs, allowing for easy resolution and compatibility with existing web systems.

Summary: DID Web focuses purely on decentralized identity (authentication) and not authorization and capability delegation. It is also reliant on DNS, so is not easily usable by a typical internet user.

Beehive

Beehive is a project by Ink & Switch that aims to develop secure and efficient local-first authorization while maintaining a user experience similar to familiar cloud-based applications. It seeks to address the challenges of access control in local-first systems, where every replica has a complete copy of the application, by rethinking how authority flows between nodes without relying on central servers or constant network connectivity. Beehive strives to combine the self-certification of “Rumpelstiltskin” security, the power of auth servers, and the user agency of decentralized solutions in a local-first context.

Summary: Still just a theoretical concept (no technical details or code), but we will follow its development. It’s an interesting decentralized authorization solution that would work nicely alongside DIDs.

Secure Scuttlebutt

Secure Scuttlebutt (SSB) is a decentralized peer-to-peer protocol and social media ecosystem where users host their own content and that of their peers, using cryptographically signed append-only message feeds. It prioritizes offline-friendly communication, user sovereignty, and resilient data replication across networks. SSB allows users to create and maintain their digital identities without relying on centralized authorities, enabling secure and private social interactions in a distributed environment.

Summary: SSB is a full protocol and ecosystem rather than a DID solution. Due to its implementation it has limited scalability compared to other DID systems.

Confederal Protocols

Confederal protocols are presented as a hybrid approach between federated and peer-to-peer systems, aiming to combine user sovereignty with federated infrastructure. This concept proposes a model where users maintain control over their digital identities and data while benefiting from the easier infrastructure design of federated systems. In confederal protocols, users are not bound to specific providers but are free to choose and switch between service providers without disrupting their user experience

Summary: This is currently just a theoretical concept (no technical details or implementations in code), but it could be interesting to review again in the future if it’s developed further.

PKarr

PKarr (Public-Key Addressable Resource Records) is an innovative project that integrates the Domain Name System with peer-to-peer overlay networks, allowing public keys to function as sovereign, censorship-resistant top-level domains. It uses the Mainline DHT to publish and resolve signed DNS packets, enabling users to maintain control over their online identities and resources without relying on centralized authorities. This system aims to enhance internet freedom by providing a decentralized alternative to traditional domain name resolution, making it accessible to anyone capable of maintaining a private key.

Summary: Although it is an interesting solution for decentralizing the traditional DNS system, it does not directly address the need to enable individuals to obtain DIDs for authentication and is instead focused on publishing those credentials once they have been obtained.

KERI (Key Event Receipt Infrastructure)

KERI (Key Event Receipt Infrastructure) is a project focused on creating a decentralized identity and trust management system. It provides a framework for secure, privacy-preserving, and authentic digital interactions without relying on centralized authorities or blockchains.

Summary: KERI is more focused on authentication and identity verification rather than user authorization.

UCAN (User Controlled Authorization Networks)

UCAN (User Controlled Authorization Networks) is a decentralized protocol that enables users to directly delegate permissions in distributed systems using cryptographically signed tokens. It extends JSON Web Tokens (JWTs) to allow users to self-issue authorization credentials without relying on centralized servers, supporting offline-first operations and granular control over resource access. Unlike traditional systems, UCAN uses capability-based security, where tokens explicitly define permitted actions and resources, enabling secure delegation across applications and devices while maintaining user sovereignty.

Summary: UCAN meets all of our requirements for a decentralized, configurable, scalable and cost-effective role authorization solution. Coupled with a DID framework like did:key that enables a simple way to authenticate users, UCAN making it possible to manage permissions on a per-service basis for those users at a fairly granular level. Further, the UCAN protocol enables users to share all or a subset of their permissions for a service with other users.

The official repos are somewhat stagnant, but there is a good selection of software (written in TypeScript and Golang, which are both languages well suited for a project like PLANET) that we can use as a starting point to implement UCAN as PLANET’s base layer for user access management.  Also, there are other projects (e.g., storacha.network) who have implemented UCAN in their user registration and authorization flows so we can learn from their work and perhaps collaborate to build modules that can be shared by other projects looking to implement UCAN.

Conclusion

We are cautiously optimistic that a combination of UCAN and the did:key DID method is the best decentralized identity authentication and role authorization solution currently available, so we have started a thorough technical assessment of how to implement DID/UCAN for PLANET.

We will continue monitoring the decentralized authentication and authorization landscape should other solutions show promise and welcome your feedback on the choice of DID/UCAN in the Loomio group.