JSS is aligned end-to-end with the W3C Linked Web Storage 1.0 Authentication Suite (FPWDs published 2026-04-23) and its substrate, W3C Controlled Identifiers v1.0 — pod profiles are CID-shaped, users add keys via the doctor, and the server accepts strict LWS10-CID JWTs as an HTTP auth method alongside the existing Solid-OIDC and NIP-98 paths.

Convergence tracker: #386. FPWD-alignment audit: #319.

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):

{
  "@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.
}

The 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:

"verificationMethod": [
  { "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-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.

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).

Built on top of the LWS-CID infrastructure (#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.

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.

• W3C CID v1.0 — Controlled Identifiers
• LWS 1.0 SSI via CID (FPWD 2026-04-23)
• LWS 1.0 SSI via did:key (FPWD 2026-04-23)
• W3C announcement

• docs/authentication.md — full JSS auth surface (OIDC, NIP-98, LWS-CID, passkey, etc.)
• docs/nostr.md — Nostr relay + did:nostr resolution
• doctor — the browser-side diagnostic + add-keys app
• #386 — convergence tracker
• #388 — Phase A (profile shape)
• #398 — Phase 3 (LWS-CID JWT verifier)
• #400 — NIP-98 → WebID via VM lookup
• #389 — @context array form support (turtle conneg)
• #390 — @type:'@json' literal handling (turtle conneg)