javascript-solid-server 0.0.176 → 0.0.178

package/.claude/scheduled_tasks.lock

@@ -0,0 +1 @@
+{"sessionId":"a05da419-92b7-4056-93b8-e97b2035d4ae","pid":3932382,"procStart":"114094236","acquiredAt":1778317500161}

package/README.md

@@ -26,6 +26,7 @@ A minimal, fast, JSON-LD native Solid server.
 - **Nostr Relay** — Integrated NIP-01 relay (`wss://your.pod/relay`)
 - **Nostr Auth** — NIP-98 signatures, did:nostr → WebID resolution
 - **End-to-End Encryption** — Encrypt pod content client-side via NIP-44 / NIP-04 using `did:nostr` keys ([docs](https://jss.live/docs/features/e2ee/), zero server-side changes)
+- **LWS / CID v1 profile shape** — New pod profiles are structurally W3C [Controlled Identifier](https://www.w3.org/TR/cid-1.0/) documents, ready for [LWS 1.0](https://www.w3.org/TR/2026/WD-lws10-authn-ssi-cid-20260423/) auth ([docs](docs/lws.md))
 - **ActivityPub** — Fediverse federation with Mastodon-compatible API
 - **remoteStorage** — [draft-dejong-remotestorage-22](https://remotestorage.io/spec/) file sync
 - **MongoDB Storage** — Optional `/db/` route for JSON-LD at scale

package/docs/lws.md

@@ -0,0 +1,84 @@
+# LWS / Controlled Identifiers (CID v1)
+
+JSS pod profiles are aligned with the W3C [Linked Web Storage 1.0 Authentication Suite](https://www.w3.org/news/2026/first-public-working-drafts-for-the-linked-web-storage-lws-1-0-authentication-suite/) (FPWDs published 2026-04-23) and its substrate, [W3C Controlled Identifiers v1.0](https://www.w3.org/TR/cid-1.0/).
+
+The work is phased — see [#386](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/issues/386) for the convergence tracker and [#319](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/issues/319) for the FPWD-alignment audit.
+
+## Three levels of compatibility
+
+| | What it means | Status |
+|---|---|---|
+| **1. Profile shape** | A WebID profile that's structurally a W3C Controlled Identifier document — right `@context`, right vocabulary, parseable as a CID document by any LWS-aware tool | ✅ **Yes** (since v0.0.174, [#388](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/pull/388)) |
+| **2. Profile carries keys** | The CID document actually declares `verificationMethod` entries an LWS verifier can look up by `kid` | ❌ Phase B — a separate "doctor / add-keys" app PATCHes them in after authentication. Out of JSS server scope. |
+| **3. Server accepts LWS-CID JWTs** | An incoming request with an LWS-CID self-signed JWT (`sub`/`iss`/`client_id` triple-equality, `kid` lookup against the WebID's `verificationMethod`, signature check) | ❌ Phase 3 of [#386](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/issues/386) — JSS still only knows OIDC/DPoP, NIP-98, passkey, simple bearer |
+
+## What Phase A actually does
+
+`src/webid/profile.js` declares the six CID v1 vocabulary terms — `controller`, `verificationMethod`, `authentication`, `assertionMethod`, `publicKeyJwk`, `publicKeyMultibase` — in the profile's `@context` (inline, so JSS's JSON-LD → Turtle conneg layer can expand them without fetching external contexts), and emits a `controller` triple pointing at the WebID itself per CID v1's self-control contract.
+
+A freshly-created pod's `profile/card.jsonld` looks like this (excerpt — the existing Solid predicates `oidcIssuer`, `pim:storage`, `ldp:inbox`, `service` etc. are unchanged):
+
+```jsonld
+{
+  "@context": {
+    "foaf": "...", "solid": "...", "cid": "https://www.w3.org/ns/cid/v1#", "lws": "https://www.w3.org/ns/lws#",
+    "controller":         { "@id": "cid:controller", "@type": "@id" },
+    "verificationMethod": { "@id": "cid:verificationMethod", "@container": "@set" },
+    "authentication":     { "@id": "cid:authentication", "@type": "@id", "@container": "@set" },
+    "assertionMethod":    { "@id": "cid:assertionMethod", "@type": "@id", "@container": "@set" },
+    "publicKeyJwk":       { "@id": "cid:publicKeyJwk", "@type": "@json" },
+    "publicKeyMultibase": { "@id": "cid:publicKeyMultibase" }
+  },
+  "@id": "https://alice.example/profile/card.jsonld#me",
+  "@type": ["foaf:Person"],
+  "controller": "https://alice.example/profile/card.jsonld#me"
+  // verificationMethod / authentication / assertionMethod arrays are
+  // intentionally absent until Phase B's doctor app PATCHes them in.
+}
+```
+
+## What Phase B will add
+
+A standalone web app (separate repo, no JSS coupling) where the WebID owner authenticates via existing means (OIDC, NIP-98, passkey) and PATCHes their profile with one or more verification methods:
+
+```jsonld
+"verificationMethod": [
+  { "id": "...#nostr-1", "type": "Multikey",   "controller": "...#me",
+    "publicKeyMultibase": "fe70102..." },
+  { "id": "...#did-key-1", "type": "Multikey", "controller": "...#me",
+    "publicKeyMultibase": "z6MkpT..." },
+  { "id": "...#passkey-1", "type": "JsonWebKey", "controller": "...#me",
+    "publicKeyJwk": { "kty": "EC", "crv": "P-256", "x": "...", "y": "..." } }
+],
+"authentication": ["...#nostr-1", "...#did-key-1", "...#passkey-1"]
+```
+
+Because Phase A already declared the context terms, this is a pure data-layer PATCH — no `@context` rewrite needed.
+
+## What Phase 3 will add (server-side verifier)
+
+When an incoming request carries an LWS-CID JWT, JSS will:
+
+1. Confirm `sub`/`iss`/`client_id` are the same URI (the caller's WebID)
+2. Dereference the WebID, parse it as a CID document
+3. Look up `kid` in the document's `verificationMethod` array
+4. Confirm the method is in `authentication`
+5. Verify the JWT signature with that public key
+
+The verifier joins the existing auth methods (OIDC, NIP-98, etc.) — preference ordering tracked in [#306](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/issues/306).
+
+## Spec references
+
+- [W3C CID v1.0 — Controlled Identifiers](https://www.w3.org/TR/cid-1.0/)
+- [LWS 1.0 SSI via CID (FPWD 2026-04-23)](https://www.w3.org/TR/2026/WD-lws10-authn-ssi-cid-20260423/)
+- [LWS 1.0 SSI via did:key (FPWD 2026-04-23)](https://www.w3.org/TR/2026/WD-lws10-authn-ssi-did-key-20260423/)
+- [W3C announcement](https://www.w3.org/news/2026/first-public-working-drafts-for-the-linked-web-storage-lws-1-0-authentication-suite/)
+
+## Related
+
+- [`docs/authentication.md`](authentication.md) — current JSS auth surface (OIDC, NIP-98, passkey, etc.)
+- [`docs/nostr.md`](nostr.md) — Nostr relay + did:nostr resolution
+- [#386](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/issues/386) — convergence tracker
+- [#388](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/pull/388) — Phase A PR
+- [#389](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/issues/389) — `@context` array form support (turtle conneg)
+- [#390](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/issues/390) — `@type:'@json'` literal handling (turtle conneg)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "javascript-solid-server",
-  "version": "0.0.176",
+  "version": "0.0.178",
   "description": "A minimal, fast Solid server",
   "main": "src/index.js",
   "type": "module",

package/src/auth/cid-doc-fetch.js

@@ -0,0 +1,202 @@
+/**
+ * Shared CID-document / WebID-profile fetcher.
+ *
+ * Used by both the LWS10-CID JWT verifier (`src/auth/lws-cid.js`) and
+ * the NIP-98 → WebID VM-lookup path (`src/auth/nostr.js`). Centralized
+ * so future SSRF / redirect / DoS hardening only needs to land in one
+ * place.
+ *
+ * Defenses (mirrored from the original lws-cid implementation):
+ *
+ *   - URL validated through `validateExternalUrl` (loopback, private
+ *     IPs, http-in-prod blocked) on the original URL AND every
+ *     redirect Location.
+ *   - Manual redirect handling — no automatic following — capped at
+ *     MAX_REDIRECTS hops.
+ *   - Cross-origin redirects refused (an open redirect on the WebID's
+ *     host can't substitute an attacker-controlled CID document).
+ *   - Body size cap enforced via Content-Length up front AND a
+ *     streaming reader cap (cancel on overage), so untrusted hosts
+ *     can't OOM us with a large payload.
+ *   - 5-second timeout per request via AbortController.
+ *
+ * Throws on any failure; callers convert to whatever they want
+ * (LWS-CID surfaces the error string, the NIP-98 path treats
+ * throw-as-null and falls back to the existing did:nostr resolver).
+ */
+
+import { validateExternalUrl } from '../utils/ssrf.js';
+
+// Default body cap (256 KB) — CID documents are tiny in practice.
+const DEFAULT_MAX_BYTES = 256 * 1024;
+const MAX_REDIRECTS = 5;
+const FETCH_TIMEOUT_MS = 5000;
+
+// Auth is on the hot path; refetching the CID document on every
+// request is unacceptable for both latency and reliability (and would
+// amplify self-traffic when the profile is hosted on this same
+// server). Bounded LRU — an attacker could otherwise grow the cache
+// without limit by sending tokens / requests with many distinct
+// document URLs. Mirrors the pattern in did-nostr.js.
+const profileCache = new Map(); // url -> { profile, timestamp, failureTtl?, error? }
+const PROFILE_CACHE_TTL = 5 * 60 * 1000; // 5 minutes for hits
+const PROFILE_FAILURE_TTL = 60 * 1000;   // 1 minute for misses
+const PROFILE_CACHE_MAX = 1000;
+
+/** @internal — exposed for tests */
+export function _clearProfileCacheForTests() {
+  profileCache.clear();
+}
+
+/**
+ * Fetch and parse a JSON CID document with SSRF, redirect, and
+ * body-size protections — and a bounded TTL cache so auth-path callers
+ * don't refetch on every request.
+ *
+ * Content-Type expectation: the response must declare a JSON-bearing
+ * Content-Type (matching `/json/`, e.g. `application/ld+json`,
+ * `application/json`, `application/json+ld`). A missing or non-JSON
+ * Content-Type rejects with a clear error rather than silently
+ * attempting JSON.parse — this caught real misconfigurations during
+ * #398 review where Turtle / HTML error pages were being served at
+ * profile URLs. Deployments serving WebID profiles should make sure
+ * their host returns the correct Content-Type for the CID document.
+ *
+ * Cache contract: keyed by `docUrl` only. All callers MUST pass
+ * consistent `opts` (in practice today everyone passes
+ * maxBytes = 256 KB). If a future caller needs a stricter limit, the
+ * cache key needs to incorporate it (or that caller needs its own
+ * cache) — otherwise a permissive entry would be returned to a strict
+ * caller and the cap wouldn't be re-enforced.
+ *
+ * @param {string} docUrl - URL to fetch (untrusted — comes from JWT
+ *   claims or is derived from a request).
+ * @param {object} [opts]
+ * @param {number} [opts.maxBytes=DEFAULT_MAX_BYTES]
+ * @returns {Promise<object>} parsed JSON
+ * @throws on any validation, network, redirect, size, or parse failure
+ */
+export async function fetchCidDocument(docUrl, opts = {}) {
+  // Cache hit (or recent failure) — return immediately. On hit we
+  // delete-then-set so this entry moves to the tail of the Map's
+  // insertion order, giving LRU eviction without a separate structure.
+  const cached = profileCache.get(docUrl);
+  if (cached) {
+    const ttl = cached.failureTtl ? PROFILE_FAILURE_TTL : PROFILE_CACHE_TTL;
+    if (Date.now() - cached.timestamp < ttl) {
+      profileCache.delete(docUrl);
+      profileCache.set(docUrl, cached);
+      if (cached.failureTtl) throw new Error(cached.error);
+      return cached.profile;
+    }
+    profileCache.delete(docUrl);
+  }
+
+  try {
+    const profile = await fetchCidDocumentNoCache(docUrl, opts);
+    setCached(docUrl, { profile, timestamp: Date.now() });
+    return profile;
+  } catch (err) {
+    setCached(docUrl, {
+      timestamp: Date.now(),
+      failureTtl: true,
+      error: err.message,
+    });
+    throw err;
+  }
+}
+
+/** Insert into the bounded LRU; evict the oldest entry past the cap. */
+function setCached(url, entry) {
+  profileCache.set(url, entry);
+  while (profileCache.size > PROFILE_CACHE_MAX) {
+    const oldest = profileCache.keys().next().value;
+    if (oldest === undefined) break;
+    profileCache.delete(oldest);
+  }
+}
+
+async function fetchCidDocumentNoCache(docUrl, opts = {}) {
+  const maxBytes = opts.maxBytes ?? DEFAULT_MAX_BYTES;
+  const originalOrigin = new URL(docUrl).origin;
+  let currentUrl = docUrl;
+
+  for (let hop = 0; hop <= MAX_REDIRECTS; hop++) {
+    const isLastAllowedHop = hop === MAX_REDIRECTS;
+    const validation = await validateExternalUrl(currentUrl, {
+      requireHttps: process.env.NODE_ENV === 'production',
+      blockPrivateIPs: true,
+      resolveDNS: true,
+    });
+    if (!validation.valid) {
+      throw new Error(`SSRF protection: ${validation.error}`);
+    }
+
+    const controller = new AbortController();
+    const timer = setTimeout(() => controller.abort(), FETCH_TIMEOUT_MS);
+    let res;
+    try {
+      res = await fetch(currentUrl, {
+        headers: { Accept: 'application/ld+json, application/json;q=0.9' },
+        redirect: 'manual',
+        signal: controller.signal,
+      });
+    } finally {
+      clearTimeout(timer);
+    }
+
+    if (res.status >= 300 && res.status < 400) {
+      if (isLastAllowedHop) {
+        throw new Error(`too many redirects (>${MAX_REDIRECTS})`);
+      }
+      const loc = res.headers.get('location');
+      if (!loc) throw new Error(`redirect ${res.status} without Location`);
+      const nextUrl = new URL(loc, currentUrl).toString();
+      const nextOrigin = new URL(nextUrl).origin;
+      if (nextOrigin !== originalOrigin) {
+        throw new Error(`cross-origin redirect refused: ${originalOrigin} → ${nextOrigin}`);
+      }
+      currentUrl = nextUrl;
+      continue;
+    }
+
+    if (!res.ok) throw new Error(`HTTP ${res.status}`);
+
+    const ct = (res.headers.get('content-type') || '').toLowerCase();
+    if (!ct.includes('json')) {
+      throw new Error(`unexpected content-type: ${ct || '(none)'}`);
+    }
+
+    const declared = Number(res.headers.get('content-length'));
+    if (Number.isFinite(declared) && declared > maxBytes) {
+      throw new Error(`CID document too large (Content-Length=${declared} > ${maxBytes})`);
+    }
+    const text = await readBodyWithCap(res, maxBytes);
+    return JSON.parse(text);
+  }
+  throw new Error('profile fetch loop exited unexpectedly');
+}
+
+async function readBodyWithCap(res, maxBytes) {
+  const reader = res.body?.getReader?.();
+  if (!reader) {
+    const text = await res.text();
+    if (Buffer.byteLength(text, 'utf8') > maxBytes) {
+      throw new Error(`CID document too large (>${maxBytes} bytes)`);
+    }
+    return text;
+  }
+  const chunks = [];
+  let total = 0;
+  for (;;) {
+    const { value, done } = await reader.read();
+    if (done) break;
+    total += value.byteLength;
+    if (total > maxBytes) {
+      try { await reader.cancel(); } catch { /* noop */ }
+      throw new Error(`CID document too large (>${maxBytes} bytes)`);
+    }
+    chunks.push(value);
+  }
+  return Buffer.concat(chunks.map((c) => Buffer.from(c.buffer, c.byteOffset, c.byteLength))).toString('utf8');
+}