Tracker for converging the existing profile/key-linking issues (#42, #6, #4, #39, #86, #319) onto the W3C Linked Web Storage 1.0 Authentication Suite FPWDs published 2026-04-23 — and on the substrate they delegate to, W3C Controlled Identifiers v1.0.

This issue does not propose a new design from scratch. It captures the design that fell out of reading the LWS FPWDs against JSS's current state, so future PRs can reference one place.

Key insight

LWS auth FPWDs delegate identity-document semantics to W3C Controlled Identifiers 1.0. A WebID becomes LWS-conformant for self-signed auth (LWS10-CID, LWS10-did:key) by being a valid CID document — i.e. by carrying verificationMethod, authentication, assertionMethod, controller, publicKeyJwk/publicKeyMultibase triples. No separate DID document needed for the WebID-controlled case.

This converges several historically separate JSS workstreams onto one mechanism.

Current JSS state

src/webid/profile.js already declares cid: and lws: prefixes (prep work landed) but writes zero verification material. The path to conformance is additive — no breaking changes to existing profiles.

Proposed profile shape

A WebID with three keys: a Nostr secp256k1 (NIP-98), a did:key Ed25519 (LWS10), and a passkey/WebAuthn credential.

{
  "@context": [
    "https://www.w3.org/ns/cid/v1",
    {
      "foaf": "http://xmlns.com/foaf/0.1/",
      "solid": "http://www.w3.org/ns/solid/terms#",
      "schema": "http://schema.org/",
      "pim": "http://www.w3.org/ns/pim/space#",
      "ldp": "http://www.w3.org/ns/ldp#",
      "owl": "http://www.w3.org/2002/07/owl#",
      "lws": "https://www.w3.org/ns/lws#",
      "nostr": "https://w3id.org/nostr/vocab#",
      "alsoKnownAs": { "@id": "https://www.w3.org/ns/activitystreams#alsoKnownAs", "@type": "@id" },
      "sameAs":      { "@id": "owl:sameAs", "@type": "@id" }
    }
  ],
  "id": "https://alice.solid.social/profile/card.jsonld#me",
  "type": ["foaf:Person"],
  "controller": "https://alice.solid.social/profile/card.jsonld#me",

  "verificationMethod": [
    { "id": "...#nostr-key-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-key-1", "...#did-key-1", "...#passkey-1"],
  "assertionMethod":  ["...#did-key-1"],

  "alsoKnownAs": ["did:nostr:124c0…", "did:key:z6Mk…"],
  "sameAs":      "did:nostr:124c0…"
}

Notes:

• https://www.w3.org/ns/cid/v1 is the first @context entry. CID-aware verifiers process this directly; existing JSS predicates (oidcIssuer, pim:storage, ldp:inbox, service, …) live in the inline prefix object so JSON-LD output is byte-stable for everything else.
• Nostr secp256k1 uses did:nostr's multikey recipe (parity byte + multicodec 0xe7,0x01 + base16-lower) so a NIP-98 verifier can decode straight to the 32-byte x-only key without dereferencing a DID document.
• alsoKnownAs is the forward link to DID URIs (matches did:nostr's conventional binding); sameAs keeps the existing src/auth/did-nostr.js resolver working unchanged.

Verification flow (key K → WebID W)

1. Identify subject from credential: sub (LWS-CID JWT), pubkey hex (NIP-98), DID URI (did:key), credential ID (WebAuthn)
2. Fetch the WebID profile (which is the CID document)
3. Find matching verificationMethod — by kid for JWT, by raw key match for NIP-98
4. Confirm it appears in authentication (or assertionMethod for credential issuance)
5. Verify the cryptographic proof using that key
6. Confirm the verification method's controller is W (or W is its own controller)

This is profile-only for LWS-CID and WebAuthn; profile-or-DID-doc for did:nostr (existing two-way owl:sameAs ↔ alsoKnownAs from #42); DID-doc-only for did:key (the DID is the public key).

Migration path

Smallest delta — ~80–120 LOC:

Back-compat: profiles created without keys are byte-identical to today. Existing JSS resolvers (did-nostr, webid-tls) continue to work; the new design generalises the WebID-TLS pattern (cert:key → verificationMethod).

Open spec choices (FPWDs don't bind us; we get to decide)

Phasing

This tracker captures design. Concrete shippable phases:

Phase 1 — Profile emits keys (PR-shaped):

• src/webid/profile.js accepts keys[]; emits CID triples
• @context array form
• New pods at signup get the keys they registered with
• No verifier-side changes yet — purely additive
• Tests for the JSON-LD structure

Phase 2 — Migration command:

• jss migrate add-keys to upgrade existing pods
• Idempotent; safe to re-run

Phase 3 — LWS10-CID verifier:

• Server-side support for LWS-CID JWTs (sub/iss/client_id triple equality, kid lookup)
• Existing did:nostr / WebID-TLS verifiers stay; new LWS-CID joins them
• This is what Align JSS auth modules with LWS 1.0 Authentication Suite (FPWDs 2026-04-23) #319 / Support did:key Authentication (LWS10 Spec) #86 actually need

Phase 4 — Cross-protocol unification:

• Single "self-signed identity" verifier wrapping NIP-98, LWS-CID, did:key, WebID-TLS
• All four resolve K→W against the same verificationMethod/authentication declarations
• Auth-method preference order (Auth middleware: prefer OIDC/DPoP over NIP-98 when both are present on a request #306) becomes a config

Refs

• W3C Controlled Identifiers v1.0
• LWS 1.0 Authentication: SSI via Controlled Identifiers (FPWD 2026-04-23)
• LWS 1.0 Authentication: SSI via did:key (FPWD 2026-04-23)
• W3C news announcement
• did:nostr DID Method Specification

Converges these issues

• Spec: did:nostr to WebID Resolution #42 (Spec: did:nostr → WebID Resolution)
• Align JSS auth modules with LWS 1.0 Authentication Suite (FPWDs 2026-04-23) #319 (Align JSS auth modules with LWS 1.0 FPWDs)
• Phase 2: Link did:nostr to WebID profiles (owl:sameAs) #6 (Phase 2: Link did:nostr to WebID profiles via owl:sameAs)
• Add did:nostr SSO and Schnorr (NIP-98) authentication #4 (did:nostr SSO + Schnorr/NIP-98 — done; this is the LWS-aligned next step)
• Add tests for did:nostr to WebID resolution #39 (Tests for did:nostr → WebID resolution)
• Support did:key Authentication (LWS10 Spec) #86 (Support did:key Authentication, LWS10 Spec)
• LWS Protocol Mode Support (Draft/Future) #87 (LWS Protocol Mode Support — separate concern: data plane, not auth)
• Extract Minimal Viable LWS Server #89 (Extract Minimal Viable LWS Server)
• Add WebID-TLS authentication support #67 (WebID-TLS — the existing precedent for "profile declares its keys")
• Auth middleware: prefer OIDC/DPoP over NIP-98 when both are present on a request #306 (Auth middleware preference order)