profile: declare Multikey/JsonWebKey class names in @context (#417) - #418
Merged
melvincarvalho merged 1 commit intoMay 10, 2026
Merged
profile: declare Multikey/JsonWebKey class names in @context (#417)#418melvincarvalho merged 1 commit into
melvincarvalho merged 1 commit into
Conversation
Copy link
Copy Markdown
Contributor
Sorry, something went wrong.
The default profile generator's `@context` mapped CID v1 *predicate*
terms (`verificationMethod`, `controller`, etc.) but NOT the *class*
names. So a verificationMethod authored with the spec-example shape
`{type: "Multikey", ...}` left the bare term unexpanded:
- in JSON-LD: a JSON-LD processor with no external context
fetcher couldn't resolve "Multikey" to a class IRI
- in Turtle (conneg): `expandUri("Multikey")` returned the bare
string, N3 wrote `<Multikey>`, RFC-3986 resolved that against
the document base — yielding `<pod>/profile/Multikey`, a
fictional class on the pod's own host
Net: the same key on `alice.example.com` and `bob.example.com`
emitted DIFFERENT class IRIs. SPARQL queries on `?s a cid:Multikey`
missed every JSS-issued VM. VC validators couldn't recognize the
type. Same trap for `JsonWebKey`.
Fix: two flat aliases in the profile @context:
"Multikey": "cid:Multikey",
"JsonWebKey": "cid:JsonWebKey"
Why flat aliases (not pre-prefixed CURIE in the JSON-LD payload):
- Naive JSON readers comparing `type === "Multikey"` keep
working — readable, unchanged shape
- JSON-LD processors expand via @context — get the canonical
`https://www.w3.org/ns/cid/v1#Multikey`
- Our Turtle conneg layer (which DOES respect @context per #389
and now #416) expands and N3 writes `cid:Multikey` with the
`cid:` prefix declared at the top of the document — any
Turtle parser resolves it correctly
- Matches the "JSON-LD with flat context aliases" pattern that
consumers like LION/LOSOS rely on
Tests:
- Profile Document: `@context` declares both `Multikey` and
`JsonWebKey` as flat aliases mapping to the CID v1 namespace.
- Turtle conneg: combines the production profile generator's
@context with a synthetic VM `{type: "Multikey", ...}` and
asserts:
a. Turtle contains `cid:Multikey` (or full IRI form)
b. Turtle does NOT contain bare `<Multikey>` (which would
resolve to `<pod>/profile/Multikey`)
c. The publicKeyMultibase value still appears (#416 didn't
regress)
Test count: 772 → 774 in full suite.
Copy link
Copy Markdown
There was a problem hiding this comment.
Pull request overview
This PR fixes a JSON-LD → Turtle interoperability bug in the default WebID profile by ensuring CID v1 verificationMethod class names (Multikey, JsonWebKey) are declared in the profile @context, so bare "type": "Multikey" expands to the canonical https://www.w3.org/ns/cid/v1#Multikey rather than a host-relative <…/profile/Multikey> IRI.
Changes:
- Add flat @context aliases for Multikey and JsonWebKey in the server-generated profile JSON-LD.
- Add unit coverage asserting the new @context mappings are present and CID-namespaced.
- Add a Turtle conneg unit test that injects a bare-term type: "Multikey" VM and asserts Turtle output does not contain a bare <Multikey>.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/webid/profile.js | Extends the generated profile @context with flat aliases for Multikey/JsonWebKey to ensure CID v1 class expansion during conneg. |
| test/webid.test.js | Adds tests validating the new context terms and verifying Turtle conneg expands bare type terms into the CID namespace. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Sorry, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #417. Builds on #416 (Turtle converter accepts id/type aliases on nested objects).
Problem
The server-default profile's @context mapped CID v1 predicates (verificationMethod, controller, publicKeyMultibase, etc.) but NOT the class names Multikey and JsonWebKey. An app PATCHing in a verificationMethod with the spec-example shape {type: "Multikey", ...} triggered:
Per RFC 3986, <Multikey> resolves against the document base — yielding <pod>/profile/Multikey, a fictional class on the pod's own host. Same key on alice.example.com and bob.example.com emitted DIFFERENT class IRIs. VC validators / SPARQL queries against cid:Multikey missed every JSS-issued VM.
Fix
Two flat aliases added to @context in src/webid/profile.js:
The flat-alias shape (vs. pre-prefixed CURIE in the payload) preserves three properties:
This matches the "JSON-LD with flat context aliases" pattern that consumers like LOSOS / LION rely on.
Test plan
Migration note
Existing profiles authored before this change still have the old @context without the class aliases. Their conneg-converted Turtle will continue to emit bare <Multikey> until the profile is re-emitted (e.g. via a profile-rewrite migration or simply a future PUT through this updated emitter). New pods + profiles created via JSS get the fix automatically.
For the live test pod on solid.social specifically, I'll patch its @context manually after this lands so its /.well-known/did/nostr/... and Turtle conneg paths produce clean class IRIs without waiting for a re-emit.