buildOwnerKeyDocument (src/keys/provision.js:135-147) writes /private/privkey.jsonld with an external context:

'@context': 'https://www.w3.org/ns/cid/v1',
type: 'Multikey',
controller, publicKeyMultibase, secretKeyMultibase

But the WebID profile builder (src/webid/profile.js:56-107) declares the CID vocabulary inline, with a comment explaining exactly why:

"CID v1 vocabulary is declared inline (rather than via an imported context URL) so JSS's JSON-LD → Turtle conneg layer can expand every term without fetching external contexts."

So the two CID-document builders make opposite context choices for the same vocabulary. /private/privkey.jsonld is a pod resource; when conneg'd to Turtle, the external cid/v1 URL is not fetched, so Multikey / controller / publicKeyMultibase / secretKeyMultibase do not expand — the bare-relative-IRI failure mode profile.js describes at lines 95-104. It is therefore not a valid Controlled Identifier document when read as Turtle, which the LWS 1.0 authentication suite requires (the resource MUST be a valid CID-1.0 document).

The LWS WD example uses the external form ["https://www.w3.org/ns/cid/v1"], but JSS's conneg layer deliberately does not fetch external contexts — which is precisely why profile.js inlines. provision.js should do the same.

Proposed fix: make buildOwnerKeyDocument declare the CID terms inline, matching profile.js, with two additions the public profile does not need: secretKeyMultibase, and a type → @type alias (since the doc uses type: "Multikey").

Note for the fix: confirm the canonical IRIs the terms should expand to (profile.js currently maps e.g. Multikey → https://www.w3.org/ns/cid/v1#Multikey; verify that matches what https://www.w3.org/ns/cid/v1 itself expands Multikey to, since CID/Data-Integrity historically use the https://w3id.org/security# namespace). If they differ, that is a separate profile.js correctness question worth resolving in the same pass.

Found while aligning the stack to the did:nostr Multikey/cid shape (cf. #568, nostrcg/did-nostr#90).