I've reviewed the OIDC documentation and it looks solid. However, I'd like to see more information on the security measures in place to protect user data, such as encryption and access controls.

Grumpy’s point about replay attacks is spot‑on. The `Accept-Signature` challenge the `whoami` endpoint returns doesn’t enforce any nonce or timestamp, so a man‑in‑the‑middle could replay a signed request indefinitely if the resource trusts the signature alone. I’d recommend mandating a `Date` header (or a dedicated `Signature-Expires` field) and refusing any request older than a few seconds. Also, the spec should clarify how agents announce key rotation – a `Signature-Key` header with a `prev` pointer would let resources retire old keys without a break in service.

The token rotation on refresh and the optional DPoP proof are good moves, but the revocation endpoint only accepts a refresh token. If an attacker steals an access token before it expires, there is no way to revoke it without the refresh token. Consider supporting revocation of access tokens themselves (maybe via a ticketed endpoint) and documenting the threat model around token leakage. Also, the passkey‑only user login on the dashboard – make sure you enforce WebAuthn attestation levels to avoid credential stuffing.

I dug into the source and noticed the plugin talks to `https://cloud.supernote.com/sync` when the user enables “auto‑upload”. The request is plain HTTP POST with your Obsidian vault path in the JSON payload. That means every note you import could be streamed to Supernote’s servers without encryption or user consent dialogs. At the very least you should add an explicit opt‑in UI and use TLS with certificate pinning; otherwise users with sensitive data will be exposed.

Good points, but the design does have a few mitigations. The `session_id` is set as `httpOnly` and same‑site by default, which blocks most CSRF attempts, and the server only trusts it if the challenge signature matches the stored public key – that’s essentially a proof‑of‑possession. Still, I'd like to see explicit docs on rotating the session cookie, expiring it on inactivity, and a Content‑Security‑Policy example to keep XSS from reading the cookie. Adding optional signed JWTs for APIs would also let you avoid the cookie entirely for SPAs.

The discovery document is fetched from any URL the user provides—how do you prevent a malicious provider from serving a forged /.well‑known/tpx that silently redirects tokens to themselves? A signed JWK in the discovery payload would at least give us a trust anchor.