2026-03-15 01:48:32Claude (MCP):
[mcp] Update open questions with research findings, mark resolved items
Design/VPS_Architecture.md ..
@@ 643,14 643,14 @@
## Open Questions
-
1. **ATProto Python OAuth library maturity.** The Bluesky Flask demo uses `authlib` + `joserfc` and is CC-0 licensed. It's a reference implementation, not a maintained library. We'd be copying and adapting it, not importing a package. Is the DPoP/PAR implementation battle-tested enough, or do we need to audit it carefully?
+
1. ~~**ATProto Python OAuth library maturity.**~~ **RESOLVED.** The Bluesky Flask demo uses `authlib` (not `joserfc` — earlier research was wrong). Dependencies are `authlib>=1.3`, `dnspython`, `requests`, `requests-hardened`, `regex`. All mature. The demo is ~600 lines, well-factored, and directly adaptable. See [[Dev/V3_V5_Risk_Research]].
-
2. **MCP OAuth AS scope.** Building a spec-compliant OAuth 2.1 AS (with DCR, PKCE, token refresh, JWKS) is a meaningful amount of work. `authlib` has server-side components that can handle some of this. How much can we lean on `authlib` vs. hand-rolling? The Bluesky Flask demo is client-side only.
+
2. ~~**MCP OAuth AS scope.**~~ **RESOLVED.** `authlib` provides `AuthorizationServer`, `AuthorizationCodeGrant` (with PKCE), and `ClientRegistrationEndpoint` (RFC 7591). The Flask OAuth 2.0 server components handle the heavy lifting. We implement model callbacks (save_client, save_token, query_client) against SQLite. See [[Dev/V3_V5_Risk_Research]] for implementation sketch.
3. **Caddy DNS challenge provider.** Wildcard TLS requires DNS API access. Which DNS provider hosts the robot.wtf zone? Cloudflare, Route 53, and OVHcloud are all supported by Caddy. The DNS provider choice should be made before deployment.
-
4. **Claude.ai MCP OAuth compatibility.** The self-hosted OAuth 2.1 AS approach should work — Claude.ai's MCP client follows standard OAuth 2.1 discovery. But the actual implementation needs testing against Claude.ai's specific client behavior (which headers it sends, how it handles token refresh, whether it supports DPoP). The GitHub issues around Claude.ai MCP OAuth suggest it can be finicky. Plan for a debugging cycle.
+
4. **Claude.ai MCP OAuth compatibility.** The self-hosted OAuth 2.1 AS approach should work — Claude.ai's MCP client follows standard OAuth 2.1 discovery. Key finding: Claude.ai uses `client_secret_post` auth method and does NOT require DPoP. The risk is in underdocumented client quirks. Mitigation: build a minimal stub AS early and test against Claude.ai before building the full thing. See [[Dev/V3_V5_Risk_Research]].
-
5. **ATProto scopes.** The ATProto OAuth spec has "transitional" scopes (`transition:generic`). We only need authentication (identity), not authorization to act on the user's PDS. Is there a read-only or identity-only scope, or do we request `transition:generic` and just not use the access token for anything beyond profile fetching?
+
5. ~~**ATProto scopes.**~~ **RESOLVED.** The ATProto spec explicitly says: "A client may include only the `atproto` scope if they only need account authentication." The `sub` field in the token response contains the DID. We request scope `"atproto"` and nothing else. See [[Dev/V3_V5_Risk_Research]].
6. **Docker Compose vs. systemd.** Both work. Docker Compose gives you reproducible builds, isolation, and easier migration between hosts. Systemd is lighter, native to Debian, and avoids Docker's overhead. For a Proxmox VM where we control the environment completely, systemd is probably sufficient. Docker adds value if we expect to move the deployment frequently.