ATProto Identity Ownership and PDS Key Management Risks

PDS Operators Control User Identities

In the ATProto ecosystem, the Personal Data Server (PDS) operator effectively owns the user's identity because the PDS holds both the signing key and the rotation key. The signing key allows the PDS to sign every commit to a user's repository—including posts, likes, and follows—making any action taken by the operator cryptographically indistinguishable from the user's own activity.

Because the rotation key controls the identity itself, a PDS operator can change the signing key or redirect the account to a different PDS, granting them full ownership of the user's Decentralized Identifier (DID). This creates a critical vulnerability where a single operator can impersonate a user across every application built on ATProto, such as Bluesky, Tangled, Grain, or Leaflet.

The Scope of Identity Compromise

Unlike traditional centralized platforms where a breach is limited to that specific service, a compromised PDS affects the user's entire ATProto presence.

• Cross-Application Impersonation: Since every ATProto app writes to the same repository signed by the same key, a rogue PDS operator can post inflammatory content or grant themselves unauthorized access to repositories on platforms like Tangled.
• Identity Deletion: A PDS operator can "kill" a user's identity. While data may persist in backups or the network firehose, the operator can lock the user out of their identity entirely, preventing them from interacting with any app in the ecosystem.
• Key-Centric Risk: The risk is not about data privacy—as repository data is public and broadcast on the firehose—but about the power to act as the user. A compromised PDS gives an attacker the ability to create new activity and lock users out of their identities.

Mitigation and Proposed Improvements

Users can mitigate these risks by enrolling a self-controlled rotation key with higher priority than the PDS's key. This prevents the PDS from locking the user out of their identity, allowing the user to rotate the signing key and move to a new PDS. However, this is not the default setting and is not integrated into the standard account creation flow.

To improve sovereignty, the following changes are proposed:

1. Default Backup Keys: Backup rotation key enrollment should be a default part of account creation.
2. Client Integration: Key management should be built into clients rather than remaining as an API-level feature.
3. Transparency: ATProto documentation should explicitly state the implications of PDS operators holding user keys.
4. Auditability: Users should have a clear mechanism to audit what the PDS has signed on their behalf.

Community Perspectives and Counterpoints

Community discussion highlights a divide between those who view this as a critical flaw and those who see it as a standard trade-off for convenience.

The Argument for Convenience

Some users argue that most people are comfortable trusting third-party providers (like GitHub or Google) with their identities and that self-hosting a PDS is a viable solution for those with high-security needs (e.g., journalists or activists).

"Most people don’t worry about it for the same reason they don’t worry about GitHub abusing their GitHub account... It’s solvable if you’re willing to self-host your PDS."

The Argument for Structural Flaws

Other critics argue that the current implementation is an inelegant solution for a protocol based on Decentralized Identifiers (DIDs).

"Unless I'm mistaken the DID spec allows provable hierarchical relationships between DID identities – why can't a child DID be created from our master signing identity... Not even why the PDS would require our signing key that just seems very sloppy to me."

Alternative Identity Models

Some contributors suggest that blockchain-based smart contracts or a "chain of trust" model, similar to Farcaster, could provide a more robust method for identity recovery and management without relying on a single operator's trust.