ATProto Identity Ownership and PDS Key Management Risks

PDS Operators Control User Identities by Default

In the default ATProto configuration, the Personal Data Server (PDS) operator holds both the user's signing key and rotation key. Because the signing key is used to authorize every commit to the user's repository—including posts, likes, and follows—a PDS operator can impersonate a user with cryptographic validity. These actions are indistinguishable from legitimate user activity because the signatures are valid and the commits are properly formed.

This risk extends beyond a single application. Since ATProto is designed as a foundation for multiple apps (such as Bluesky, Tangled for git collaboration, Grain for social interactions, and Leaflet for blogging), a single compromised PDS provides an attacker or rogue operator access to the user's identity across the entire ecosystem. An operator could potentially grant themselves push access to code repositories or publish fraudulent blog posts, all signed by the user's identity.

The Critical Difference Between Data and Keys

While ATProto data is public and broadcast via a "firehose" (a real-time data stream), the security vulnerability lies in the keys, not the data. Compromising a relay—the service that aggregates network data—only provides access to public information. However, compromising a PDS provides the ability to act as the user.

If a PDS operator decides to lock a user out, they can use the rotation key to change the signing key or point the Decentralized Identifier (DID) to a different PDS. This effectively "kills" the identity across all ATProto-compatible applications, regardless of whether the data still exists in backups.

Mitigation Strategies and Proposed Improvements

Users can mitigate these risks through two primary methods:

1. Self-Hosting a PDS: Users can run their own PDS (e.g., using Docker and SQLite on a Raspberry Pi or a low-cost VM) to ensure they maintain sole possession of their keys.
2. Manual Rotation Key Enrollment: Users can enroll a self-controlled rotation key with higher priority than the PDS's key. This prevents the PDS operator from locking the user out of their identity, allowing the user to rotate the signing key and move to a new PDS if necessary.

Critics argue that the current default setup trades sovereignty for convenience, as manual key management is difficult for the average user. Proposed improvements include making backup rotation key enrollment a default part of the account creation flow and integrating these tools directly into clients rather than just the API.

Community Perspectives and Counterpoints

Discussion among technical users reveals a divide between those who view this as a critical flaw and those who see it as a standard trade-off of web architecture.

Arguments that the risk is acceptable

Some users argue that this trust model is similar to other common web services. One commenter noted that users already trust GitHub with their accounts and use "Login with GitHub" for third-party access, suggesting that the risk of the platform itself being a bad actor is lower than the risk of third-party account takeover.

"Is author new at the whole web thing? Yes, people trust remote web servers... This is just how the web works, and there is no easy around it without losing features people care about."

Arguments for architectural changes

Other contributors suggest that ATProto's implementation of the DID spec is an "inelegant solution," arguing that the protocol should support provable hierarchical relationships between identities. This would allow a "child DID" to handle CRUD operations on behalf of the user without requiring the PDS to hold the root signing key.

Additionally, some suggest that blockchain-based smart contracts, similar to the model used by Farcaster, could provide a more robust method for identity recovery and self-sovereign identity management without relying on a single server operator.