javascript-solid-server 0.0.178 → 0.0.179

package/docs/lws.md

@@ -1,16 +1,17 @@
 # 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/).
+JSS is aligned end-to-end 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/) — pod profiles are CID-shaped, users add keys via the [doctor](https://jss.live/doctor/), and the server accepts strict LWS10-CID JWTs as an HTTP auth method alongside the existing Solid-OIDC and NIP-98 paths.
 
-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.
+Convergence tracker: [#386](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/issues/386). FPWD-alignment audit: [#319](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/issues/319).
 
-## Three levels of compatibility
+## Compatibility, by level
 
 | | 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 |
+| **2. Profile carries keys** | The CID document actually declares `verificationMethod` entries an LWS verifier can look up by `kid` | ✅ Browser-side via the [doctor](https://jss.live/doctor/) — [B.2](https://github.com/JavaScriptSolidServer/doctor/pull/2) for Nostr/Multikey, [B.3](https://github.com/JavaScriptSolidServer/doctor/pull/4) for ES256K/JsonWebKey. The doctor authenticates as the WebID owner via Solid-OIDC and PATCHes the VM into the profile. |
+| **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) | ✅ Shipped in v0.0.177 ([#398](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/pull/398)). Strict FPWD §4 — ES256K is the focus algorithm; ES256, ES384, EdDSA, RS256 also accepted. |
+| **Bonus: NIP-98 → WebID** | A Schnorr-signed NIP-98 request authenticates as the WebID (not `did:nostr:`) when the pubkey is declared as a CID `verificationMethod` referenced from `authentication` | ✅ Shipped in v0.0.178 ([#400](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/pull/400)). No client-side change — the doctor's B.2 output is enough to light it up. |
 
 ## What Phase A actually does
 
@@ -37,35 +38,42 @@ A freshly-created pod's `profile/card.jsonld` looks like this (excerpt — the e
 }
 ```
 
-## What Phase B will add
+## Adding keys (Phase B — via the doctor)
 
-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:
+The [doctor](https://jss.live/doctor/) is a separate browser-side tool that signs in to your pod via Solid-OIDC and writes verificationMethod entries to your profile. After the round-trip your profile has:
 
 ```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": "..." } }
+  { "id": "...#nostr-key-1", "type": "Multikey",   "controller": "...#me",
+    "publicKeyMultibase": "fe70102…" },
+  { "id": "...#lws-key-1",   "type": "JsonWebKey", "controller": "...#me",
+    "publicKeyJwk": { "kty": "EC", "crv": "secp256k1", "alg": "ES256K", "x": "…", "y": "…" } }
 ],
-"authentication": ["...#nostr-1", "...#did-key-1", "...#passkey-1"]
+"authentication": ["...#nostr-key-1", "...#lws-key-1"]
 ```
 
+The Multikey entry handles did:nostr binding + NIP-98 lookup; the JsonWebKey entry handles strict LWS10-CID JWT auth. Both can be the same secp256k1 key — different signature schemes (Schnorr vs ECDSA), same private key.
+
 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)
+## Server-side verifier (Phase 3 — `src/auth/lws-cid.js`)
+
+When an incoming request carries an LWS-CID JWT (detected by an `Authorization: Bearer <jwt>` whose JWT-header `kid` is an http(s) URL with a fragment), JSS:
+
+1. Confirms `sub === iss === client_id` (canonicalized via URL parsing) — that URI is the WebID being claimed
+2. Validates `aud` includes the server origin, `exp` not past, `iat` recent, lifetime ≤ 1 hour
+3. Fetches the WebID profile through the shared SSRF guard — manual redirects with same-origin enforcement, 256 KB body cap, bounded LRU cache
+4. Confirms the profile's `@id` equals the JWT's `sub` (closes a profile-substitution attack)
+5. Looks up `kid` in `verificationMethod`; the entry must be referenced from `authentication` and its `controller` must match the profile's outer `controller`
+6. Verifies the JWT signature per RFC7515 §5.2. ES256K via `@noble/curves` (already in tree from NIP-98); ES256, ES384, EdDSA, RS256 via `jose`
+
+The verifier joins the existing auth methods (Solid-OIDC, NIP-98, Bearer-JWT-from-IDP, WebID-TLS) — preference order is OIDC → LWS-CID → NIP-98 → Bearer fallback (per [#306](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/issues/306)).
 
-When an incoming request carries an LWS-CID JWT, JSS will:
+## NIP-98 → WebID upgrade (`src/auth/nostr.js`)
 
-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
+Built on top of the LWS-CID infrastructure ([#400](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/pull/400)): when a NIP-98 request's signing pubkey is declared as a CID `verificationMethod` (and the VM is in `authentication`) on the resource owner's WebID profile, the request authenticates as the WebID instead of `did:nostr:<pubkey>`. Match is by f-form Multikey or by JsonWebKey full-point (x AND y, BIP-340 even-y). Profile fetch uses the same SSRF guard / cache as the LWS-CID verifier. No client-side change — Nostr clients sign as today.
 
-The verifier joins the existing auth methods (OIDC, NIP-98, etc.) — preference ordering tracked in [#306](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/issues/306).
+So: anyone who's used the doctor's B.2 to add a Nostr Multikey VM gets WebID-based NIP-98 sign-in for free.
 
 ## Spec references
 
@@ -76,9 +84,12 @@ The verifier joins the existing auth methods (OIDC, NIP-98, etc.) — preference
 
 ## Related
 
-- [`docs/authentication.md`](authentication.md) — current JSS auth surface (OIDC, NIP-98, passkey, etc.)
+- [`docs/authentication.md`](authentication.md) — full JSS auth surface (OIDC, NIP-98, LWS-CID, passkey, etc.)
 - [`docs/nostr.md`](nostr.md) — Nostr relay + did:nostr resolution
+- [doctor](https://github.com/JavaScriptSolidServer/doctor) — the browser-side diagnostic + add-keys app
 - [#386](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/issues/386) — convergence tracker
-- [#388](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/pull/388) — Phase A PR
+- [#388](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/pull/388) — Phase A (profile shape)
+- [#398](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/pull/398) — Phase 3 (LWS-CID JWT verifier)
+- [#400](https://github.com/JavaScriptSolidServer/JavaScriptSolidServer/pull/400) — NIP-98 → WebID via VM lookup
 - [#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.178",
+  "version": "0.0.179",
   "description": "A minimal, fast Solid server",
   "main": "src/index.js",
   "type": "module",

package/src/auth/nostr.js

@@ -26,7 +26,7 @@ import { secp256k1 } from '@noble/curves/secp256k1';
 import crypto from 'crypto';
 import { resolveDidNostrToWebId } from './did-nostr.js';
 import { fetchCidDocument } from './cid-doc-fetch.js';
-import { normalizeControllers } from './lws-cid.js';
+import { normalizeControllers } from './lws-cid.js'; // shared JSON-LD controller helper
 
 // NIP-98 event kind (references RFC 7235)
 const HTTP_AUTH_KIND = 27235;
@@ -503,6 +503,68 @@ function firstHeaderValue(v) {
   return first || null;
 }
 
+/**
+ * Confirm that a verified Nostr pubkey is declared as a CID
+ * verificationMethod referenced from `authentication` in the given
+ * WebID's profile. Used by the Schnorr-login IdP path (#403): once
+ * the signature is verified and the user has typed their username,
+ * the IdP layer can derive the candidate WebID and ask this whether
+ * the verified pubkey actually belongs to that WebID.
+ *
+ * Mirrors the same controller-consistency / subject-identity /
+ * authentication-membership checks as the resource-side path
+ * (tryResolveViaCidVerificationMethod) so the two paths apply the
+ * same key-binding semantics.
+ *
+ * Returns true on match, false on any failure (fetch, VM not in
+ * authentication, subject mismatch, controller mismatch, bad input).
+ *
+ * @param {string} webId - canonical fragment-bearing WebID URI (e.g.
+ *   `https://alice.example.com/profile/card.jsonld#me`). The profile's
+ *   own `@id` must match this exactly after absolutization.
+ * @param {string} pubkeyHex - 32-byte x-only Nostr pubkey hex
+ * @returns {Promise<boolean>}
+ */
+export async function verifyNostrPubkeyAgainstWebId(webId, pubkeyHex) {
+  if (typeof webId !== 'string' || !webId) return false;
+  if (typeof pubkeyHex !== 'string' || !/^[0-9a-f]{64}$/i.test(pubkeyHex)) return false;
+  const docUrl = stripHash(webId);
+  let profile;
+  try {
+    profile = await fetchCidDocument(docUrl);
+  } catch {
+    return false;
+  }
+  if (!profile || typeof profile !== 'object' || Array.isArray(profile)) return false;
+
+  // Confirm the profile actually identifies itself as the WebID we're
+  // asking about — otherwise a profile hosted at the WebID's URL could
+  // declare a different fragment as its subject and trick us. Both
+  // sides absolutized so a relative @id (e.g. "#me") resolves against
+  // docUrl and a webId without fragment (which the docstring no longer
+  // permits, but be defensive) doesn't accidentally match a fragment
+  // form.
+  const subject = absolutize(profile['@id'] || profile.id, docUrl);
+  const expectedSubject = absolutize(webId, docUrl);
+  if (!subject || subject !== expectedSubject) return false;
+
+  const vm = findNostrVmInProfile(profile, pubkeyHex.toLowerCase(), docUrl);
+  if (!vm) return false;
+  if (!isInProofPurpose(profile, 'authentication', vm.id, docUrl)) return false;
+
+  // Controller consistency: the VM's `controller` MUST be in the
+  // profile's expected controller set (declared `controller`, with
+  // @id fallback). Without this, a profile with a Nostr-keyed VM
+  // controlled by some unrelated identity would pass — a binding the
+  // actual subject never asserted. Mirrors the resource-path check.
+  const expectedCtrls = normalizeControllers(profile.controller ?? profile['@id'] ?? profile.id, docUrl);
+  if (expectedCtrls.length === 0) return false;
+  const vmCtrls = normalizeControllers(vm.controller, docUrl);
+  if (!vmCtrls.some((c) => expectedCtrls.includes(c))) return false;
+
+  return true;
+}
+
 /**
  * Find a verificationMethod whose key material matches the Nostr
  * x-only pubkey hex. Two encodings supported:

package/src/idp/interactions.js

@@ -3,12 +3,12 @@
  * Handles the user-facing parts of the authentication flow
  */
 
-import { authenticate, findById, findByWebId, createAccount, updateLastLogin, setPasskeyPromptDismissed } from './accounts.js';
+import { authenticate, findById, findByUsername, findByWebId, createAccount, updateLastLogin, setPasskeyPromptDismissed } from './accounts.js';
 import { loginPage, consentPage, errorPage, registerPage, passkeyPromptPage } from './views.js';
 import * as storage from '../storage/filesystem.js';
 import { createPodStructure } from '../handlers/container.js';
 import { validateInvite } from './invites.js';
-import { verifyNostrAuth } from '../auth/nostr.js';
+import { verifyNostrAuth, getNostrPubkey, verifyNostrPubkeyAgainstWebId } from '../auth/nostr.js';
 
 // Security: Maximum body size for IdP form submissions (1MB)
 const MAX_BODY_SIZE = 1024 * 1024;
@@ -658,6 +658,41 @@ export async function handlePasskeySkip(request, reply, provider) {
   }
 }
 
+/**
+ * Pull the optional `username` field out of a schnorr-login POST.
+ *
+ * JSS registers a wildcard parseAs:'buffer' content-type parser
+ * (src/server.js), so request.body for application/x-www-form-urlencoded
+ * arrives as a Buffer that needs string-decode + URLSearchParams. JSON
+ * and already-parsed object bodies are also accepted for flexibility.
+ *
+ * Returns either:
+ *   - { tooLarge: true } if the body exceeds MAX_BODY_SIZE (matching
+ *     handleLogin / handleRegisterPost — caller emits 413).
+ *   - { username: string } otherwise, possibly empty.
+ */
+function parseUsernameField(request) {
+  const body = request.body;
+  if (!body) return { username: '' };
+  const ct = (request.headers?.['content-type'] || '').toLowerCase();
+  if (Buffer.isBuffer(body) && body.length > MAX_BODY_SIZE) return { tooLarge: true };
+  if (typeof body === 'string' && body.length > MAX_BODY_SIZE) return { tooLarge: true };
+
+  let bag = {};
+  if (Buffer.isBuffer(body) || typeof body === 'string') {
+    const s = Buffer.isBuffer(body) ? body.toString() : body;
+    if (ct.includes('application/json')) {
+      try { bag = JSON.parse(s); } catch { bag = {}; }
+    } else {
+      try { bag = Object.fromEntries(new URLSearchParams(s).entries()); }
+      catch { bag = {}; }
+    }
+  } else if (typeof body === 'object') {
+    bag = body;
+  }
+  return { username: (bag.username || '').toString().trim() };
+}
+
 /**
  * Handle POST /idp/interaction/:uid/schnorr-login
  * Authenticates user via Schnorr signature (NIP-98)
@@ -689,16 +724,43 @@ export async function handleSchnorrLogin(request, reply, provider) {
     const identity = authResult.webId;
     request.log.info({ identity, uid }, 'Schnorr auth verified');
 
-    // Try to find an existing account linked to this identity
+    // Try to find an existing account linked to this identity. The
+    // primary path: identity is already a WebID (e.g. resolved via the
+    // existing did:nostr DID-doc resolver) and an account exists for it.
     let account = await findByWebId(identity);
 
     if (!account) {
-      // No account linked to this did:nostr
-      // For now, return error - user needs to link their did:nostr to an account
-      // Future: could auto-create account or prompt for linking
+      // Fallback: if the user typed a username on the login form, check
+      // whether the verified Nostr pubkey is declared as a CID
+      // verificationMethod referenced from `authentication` in that
+      // user's WebID profile (#400's IdP-side parallel — #403). The
+      // signature has already been verified above, so this is just
+      // "does this verified pubkey belong to the typed user".
+      const parsed = parseUsernameField(request);
+      if (parsed.tooLarge) {
+        return reply.code(413).type('application/json').send({
+          success: false,
+          error: 'Request body exceeds maximum size.',
+        });
+      }
+      const typedUsername = parsed.username;
+      if (typedUsername) {
+        const candidate = await findByUsername(typedUsername);
+        if (candidate?.webId) {
+          const pubkey = await getNostrPubkey(request);
+          if (pubkey && await verifyNostrPubkeyAgainstWebId(candidate.webId, pubkey)) {
+            account = candidate;
+            request.log.info({ accountId: account.id, webId: candidate.webId, uid },
+              'Schnorr login resolved via typed username + profile VM');
+          }
+        }
+      }
+    }
+
+    if (!account) {
       return reply.code(403).type('application/json').send({
         success: false,
-        error: 'No account linked to this identity. Please register or link your Schnorr key to an existing account.'
+        error: 'No account linked to this identity. Type your username and add a Schnorr verificationMethod to your WebID profile (or link via did:nostr DID document).'
       });
     }
 

package/src/idp/views.js

@@ -381,12 +381,21 @@ export function loginPage(uid, clientId, error = null, passkeyEnabled = true, sc
         // Sign with NIP-07 extension
         const signedEvent = await window.nostr.signEvent(event);
 
+        // Read the typed username so the server can resolve which
+        // account this Nostr key belongs to, in case the existing
+        // did:nostr DID-doc resolver doesn't have a binding yet.
+        // The signature is verified BEFORE the username is consulted —
+        // typing someone else's username doesn't grant access.
+        const typedUsername = (document.getElementById('username')?.value || '').trim();
+
         // Send to server
         const response = await fetch(authUrl, {
           method: 'POST',
           headers: {
-            'Authorization': 'Nostr ' + btoa(JSON.stringify(signedEvent))
-          }
+            'Authorization': 'Nostr ' + btoa(JSON.stringify(signedEvent)),
+            'Content-Type': 'application/x-www-form-urlencoded'
+          },
+          body: typedUsername ? 'username=' + encodeURIComponent(typedUsername) : ''
         });
 
         const result = await response.json();

package/test/nostr-cid-vm.test.js

@@ -16,7 +16,7 @@ import { describe, it, before, beforeEach, after } from 'node:test';
 import assert from 'node:assert';
 import { secp256k1 } from '@noble/curves/secp256k1';
 import { generateSecretKey, getPublicKey, finalizeEvent } from '../src/nostr/event.js';
-import { verifyNostrAuth } from '../src/auth/nostr.js';
+import { verifyNostrAuth, verifyNostrPubkeyAgainstWebId } from '../src/auth/nostr.js';
 import { _clearProfileCacheForTests } from '../src/auth/cid-doc-fetch.js';
 
 /** Compute the BIP-340 even-y JWK coordinates for an x-only Nostr pubkey. */
@@ -492,6 +492,59 @@ describe('NIP-98 + CID verificationMethod lookup (#399)', () => {
     assert.strictEqual(r.webId, WEBID);
   });
 
+  // --- IdP Schnorr-login helper (#403) ---------------------------------
+
+  describe('verifyNostrPubkeyAgainstWebId', () => {
+    it('returns true when the pubkey is a Multikey VM in authentication', async () => {
+      _clearProfileCacheForTests();
+      nextProfile = buildProfile({ pubkey: pk });
+      const ok = await verifyNostrPubkeyAgainstWebId(WEBID, pk);
+      assert.strictEqual(ok, true);
+    });
+
+    it('returns false when the pubkey is in verificationMethod but NOT in authentication', async () => {
+      _clearProfileCacheForTests();
+      nextProfile = buildProfile({ pubkey: pk, withAuth: false });
+      const ok = await verifyNostrPubkeyAgainstWebId(WEBID, pk);
+      assert.strictEqual(ok, false);
+    });
+
+    it('returns false when the profile has no matching VM', async () => {
+      _clearProfileCacheForTests();
+      const otherPk = getPublicKey(generateSecretKey());
+      nextProfile = buildProfile({ pubkey: otherPk });
+      const ok = await verifyNostrPubkeyAgainstWebId(WEBID, pk);
+      assert.strictEqual(ok, false);
+    });
+
+    it("returns false when the profile's @id differs from the asked WebID", async () => {
+      _clearProfileCacheForTests();
+      nextProfile = { ...buildProfile({ pubkey: pk }), '@id': `${DOC_URL}#bob` };
+      const ok = await verifyNostrPubkeyAgainstWebId(WEBID, pk);
+      assert.strictEqual(ok, false);
+    });
+
+    it('returns false on bad input', async () => {
+      assert.strictEqual(await verifyNostrPubkeyAgainstWebId('', pk), false);
+      assert.strictEqual(await verifyNostrPubkeyAgainstWebId(WEBID, 'not-hex'), false);
+      assert.strictEqual(await verifyNostrPubkeyAgainstWebId(WEBID, ''), false);
+    });
+
+    it('returns false when VM controller is unrelated to profile controller', async () => {
+      _clearProfileCacheForTests();
+      // VM with right Multikey but its controller points at a different
+      // identity — the profile's outer controller is the WebID, but the
+      // VM claims to be controlled by `https://attacker.example/#me`.
+      // This is the "key bound by an unrelated controller" attack the
+      // controller-consistency check defends against.
+      const profile = buildProfile({ pubkey: pk });
+      profile.verificationMethod[0].controller = 'https://attacker.example/profile/card.jsonld#me';
+      nextProfile = profile;
+      const ok = await verifyNostrPubkeyAgainstWebId(WEBID, pk);
+      assert.strictEqual(ok, false);
+    });
+  });
+
   it('still rejects an invalid signature regardless of the profile', async () => {
     const url = `https://${POD_HOST}/private/data.ttl`;
     const { authHeader } = nip98Authorization({ method: 'GET', url, secretKey: sk });