fix(security): bind UCAN JWT verification to the iss key, not the kid header

[mikera]

Vulnerability

UCAN.fromJWT verified the EdDSA signature against the public key named in the attacker-controlled kid header, then trusted the iss claim without checking the two agree. An attacker could sign a token with their own key, place that key in kid, and claim any iss (e.g. a trusted root) — an issuer-spoofing authorization bypass.

The forged token passed validateJWT / parseTransportUCANs, and via UCANValidator.capabilitiesFor(..., issuer=root) yielded capabilities attributed to the root. Reachable from transport input (e.g. DlfsMcpTools).

Fix

Derive the verification key from the iss DID (did:key encodes the issuer's public key) and verify against it. The kid header is no longer trusted for key selection. Legitimately signed tokens are unaffected (kid already equals the iss key). The CAD3 path (UCAN.verifySignature / validate) was already correct.

Audit of other JWT verification paths

Path	Verdict
UCAN.fromJWT	was vulnerable → fixed
PeerAuth.verifySelfIssued	safe — binds sub == did:key(kid) (covered by testSelfIssuedJWTKidMismatch, testBadlySignedJWTWithCorrectAudience)
PeerAuth.verifyPeerSigned	safe (verifies against trusted peer key)
OAuthService (JWKS RS256)	safe (kid selects among the provider's trusted keys; iss/aud validated)
JWKSKeys	safe (parser only)

Added a SECURITY WARNING to the kid-trusting JWT.verifyEdDSA() / verifyPublic(jwt) to prevent reintroduction.

Adversarial tests

UCANTest now forges iss=ROOT signed by a rogue key and asserts rejection at fromJWT, validateJWT, the transport boundary (parseTransportUCANs → capabilitiesFor), and inside a proof chain; plus a regression that genuine tokens still verify. These four were confirmed to fail against the pre-fix kid-based verification (the forged token was accepted as iss=ROOT granting can:"*"), then pass after the fix.

Testing

• convex-core: 2131 pass
• convex-peer (PeerAuthTest): 20 pass
• convex-dlfs: 68 pass

🤖 Generated with Claude Code