Spike code for did plc adoption

[fforbeck]

What

Replace the existing login + email verification flow with a fully client-side authentication process using Lit PKP + DID PLC.

Users prove ownership of a did:plc and are granted upload permissions using UCANs signed by a Space DID.

Why

This change, if possible, removes reliance on Storacha servers for authentication by letting users prove ownership of a did:plc directly in the browser using Lit PKP. It simplifies infrastructure, aligns identity with your UCAN-based permission model, and enables secure, walletless logins via various providers. It offers a decentralized, scalable, and user-friendly auth flow.

How

The new authorization flow should

• Resolve did:plc
• Verify did:plc ownership (equivalent to access/authorize)
• Support did:plc type (cli, upload, auth, etc)
• Provide existing delegations for a given did:plc (access/fetch)
• Preserve UCAN Delegations chain of authority
  • New Spaces:
    • space -> agent
    • space -> did:plc (note: we don't delegate to did:mailto anymore)
    • discard space private key
  • Existing Spaces
    • client fetchs the existing delegations
• Support user sign up (first time)
• User sign in
• Existing user signs up on a new device (sounds similar to the sign-in process?)
• Billing Integration
• Lit Integration

[fforbeck]

I won't explore Lit Integration at this point, but the idea is that for every PKP we mint using Lit sdk, we need to update the user did:plc document with a new verification method, which is the PKP public key, auth method, etc.

[hannahhoward]

This issue has been automatically moved to Stuck / Dead Issue status.

Reason: No activity for 244 days (threshold: 180 days)

If this issue is still relevant and you'd like to work on it, please:

1. Comment on this issue with an update
2. Move it back to Backlog or another appropriate status
3. Consider if this should be moved to Icebox instead

---

Automated by project-agent