@context must lead with the DID context (did/v1.1), not cid/v1 — DID Core conformance #136
Description
Bug
DID documents use an @context that leads with the Controlled Identifier context and omits the DID context:
"@context": ["https://www.w3.org/ns/cid/v1", "https://w3id.org/nostr/context"]This violates the DID Core normative requirement that the @context be https://www.w3.org/ns/did/v1.1 (or an array whose first item is that string). As written, a did:nostr document is arguably a Controlled Identifier document, not a DID document.
How it surfaced
Raised by Will Abramson in the W3C CCG mailing list thread:
I found it interesting that you used the Controlled Identifier context … rather than the DID context. I think this may make it a Controlled Identifier, not a Decentralized Identifier … it seems in conflict with this normative MUST from the DID spec: … The serialized value of @context MUST be the JSON String https://www.w3.org/ns/did/v1.1, or a JSON Array where the first item is that string …
How it happened
We moved to https://www.w3.org/ns/cid/v1 in #90 specifically to get Multikey / publicKeyMultibase well-defined under JSON-LD (the older DID context didn't cover them), and missed that it displaces the required DID context. Not a design choice — a refactor slip.
Fix (pending confirmation)
Lead with the DID v1.1 context:
"@context": ["https://www.w3.org/ns/did/v1.1", "https://w3id.org/nostr/context"]The DID v1.1 context is aligned with Controlled Identifiers and should incorporate Multikey / publicKeyMultibase, so cid/v1 can likely be dropped (or kept after did/v1.1 for safety). Awaiting Will's confirmation on whether did/v1.1 fully subsumes the CID terms before deciding drop-vs-keep. (Also keeps room to layer an LWS context later — did/v1.1 just has to stay first.)
Scope (coordinated change)
The cid/v1 @context is hardcoded in several places — all must move together:
- Spec examples (index.html)
- Conformance vectors (test-vectors/test-vectors-generated.json) — cc @amir-hameed-mir for the generator
- nostr-beacon (src/diddoc.js)
- did-nostr resolver (src/diddoc.js)
Refs
- Multikey is undefined under the declared @context: reference CID v1.0? (concrete case for #68) #90 — where cid/v1 was adopted
- Publication readiness: path to a W3C Community Group Draft Report #100 — publication readiness
- did-btc-spec#7 — the CCG thread where it was raised
Activity
amir-hameed-mir commented on Jul 1, 2026
@melvincarvalho Thanks for catching this. I agree that https://www.w3.org/ns/did/v1.1 should be the first entry in @context to satisfy the normative requirement from DID Core. My inclination is to keep both contexts for now:
"@context": [
"https://www.w3.org/ns/did/v1.1",
"https://www.w3.org/ns/cid/v1",
"https://w3id.org/nostr/context"
]
That keeps us fully compliant with DID Core while preserving compatibility with any CID terms until we confirm whether did/v1.1 completely subsumes them. If it does, we can simplify the context list later; if not, keeping both is the safer and more interoperable approach.
melvincarvalho commented on Jul 1, 2026
Looks good, let's wait for what Will says, and then I think we can add both to a v0.1.1
amir-hameed-mir commented on Jul 1, 2026
@melvincarvalho yes sure , we can keep backward compatibility while still be complaint to normative requirements
melvincarvalho commented on Jul 1, 2026
Did some hands-on verification with a JSON-LD processor (jsonld.js) against the actually-deployed W3C contexts. Findings:
1. https://www.w3.org/ns/did/v1.1 isn't published yet. It currently returns a 300 (Multiple Choices) — only did/v1 (1.0) and did/v1.1rc1 (a release candidate) are deployed on w3.org. So a document whose @context dereferences did/v1.1 fails to expand today:
2. did/v1.1rc1 self-contains the terms. The RC context defines Multikey and publicKeyMultibase directly (no @import of cid). So under DID 1.1, cid/v1 is redundant for these — DID 1.1 already carries them.
3. did/v1 (1.0) does not define Multikey / publicKeyMultibase — which is exactly why we moved to cid/v1 in #90. A 1.0-based context still needs cid alongside.
4. Keeping both is safe (no conflict). All combinations expand cleanly with every term preserved — no @protected redefinition errors:
So @amir-hameed-mir's "keep both" is technically fine — just note cid/v1 becomes redundant once we're on DID 1.1.
The actual blocker is the unpublished did/v1.1 URL. The clean end-state is:
…but that won't dereference until w3.org publishes the v1.1 context at the canonical URL.
Open question to take back to Will / the DID WG: is https://www.w3.org/ns/did/v1.1 scheduled to be published at the canonical URL soon?
Either way this ships as v0.1.1 across the spec, vectors, nostr-beacon, and did-nostr.
amir-hameed-mir commented on Jul 1, 2026
@melvincarvalho I agree that did/v1.1 should ultimately be the canonical first context to satisfy the DID Core requirement. However, since https://www.w3.org/ns/did/v1.1 is not yet published, I think the safest approach for now is to keep cid/v1 alongside the deployed DID context. Once the canonical DID 1.1 context is available and confirmed to fully subsume the CID terms, we can simplify the @context accordingly.
Lead @context with did/v1 for DID Core conformance (#136) (#139)
Bump spec version to 0.1.1 (#143)
fix(did): lead DID document @context with did/v1 (did:nostr 0.1.1) (#618