Support did:web user authentication and identity

[will-corrigan]

Context

Currently Frontpage only supports did:plc for user identity. We want to explore supporting did:web users — allowing them to authenticate, create posts, comment, and vote alongside did:plc users.

Previously tracked as #214 ("Cannot log in with did:web"), which was closed as unsupported. This issue scopes the work to properly design and implement did:web user support.

Problem

did:web has fundamentally different trust and availability properties from did:plc:

• Availability: DID resolution depends on the user's web server being up. If it goes down, we can't resolve their DID, discover their PDS, or verify their identity — and DID resolution is baked into profile pages, post rendering, comments, voting, and feeds.
• Domain takeover: If a domain expires and is re-registered, the new owner controls the DID. As Tom noted in Cannot log in with did:web #214: "making sure that once a did:web is deleted it's burned forever, it can't be reused" is a key problem.
• No portability: The DID IS the domain. Users can't migrate PDS without changing identity.
• No audit trail: Unlike did:plc's signed operation log, did:web key rotation is just "update the file." No cryptographic proof of changes.
• No recovery: If the user loses both their private key and domain access, the identity is gone.

Scope

A comprehensive design is needed covering:

1. Identity resolution: Extend DID validation and resolution to handle did:web — resolving via HTTPS to /.well-known/did.json, with SSRF protection, timeouts, and redirect handling
2. Auth flow: OAuth works identically for both DID methods at the protocol level, but we need graceful handling of resolution failures during sign-in
3. Resilience: Caching strategy, graceful degradation when a did:web host is down, circuit breakers to prevent cascading failures across the app
4. Domain takeover mitigation: Strategies for detecting identity discontinuity (key changes, document changes) and protecting against domain re-registration attacks
5. DID burning: Once a did:web identity is seen, ensure it can't be silently replaced by a new owner of the same domain
6. UI/UX: How to surface did:web identity status, warnings about availability, handle display differences
7. Data integrity: What happens to posts, comments, and votes when a did:web user's domain goes down permanently?

References

• Cannot log in with did:web #214 — original bug report and Tom's security concerns
• at://did:web:pds.mk.gg/app.bsky.feed.post is an invalid URI #328 — related at://did:web: URI parsing issue
• W3C did:web spec
• AT Protocol DID methods

[will-corrigan]

Additional references

Ducky (@ducky.ws / did:web:didd.uk) on did:web account permanence:

• https://bsky.app/profile/ducky.ws/post/3lccj3mbyts2h — "Once a did:web account is deleted, it's burned forever." Bluesky's AppView tombstones deleted did:web accounts permanently, even if the domain is re-registered and did.json re-created. Recommends other AppViews adopt the same policy.
• https://bsky.app/profile/ducky.ws/post/3mab7ctnfek2s — Clarifies that "deleted" means invoking the deleteAccount XRPC method specifically, which triggers AppView tombstoning.

Bryan Newbold's did:web setup guide (WhiteWind, Jan 2026):

• https://whtwnd.com/bnewbold.net/3mdc7fpbxhk26 — Full walkthrough of creating a did:web atproto account using the official goat CLI tool.