@context URL in the spec: https://www.w3.org/ns/did/v1.1 does not resolve

[wip-abramson]

The context URL: https://www.w3.org/ns/did/v1.1

Does not directly resolve to the context file. Rather it proposes a redirect to: https://www.w3.org/ns/did-vocab/v1.var

@jandrieu and I think this is an error in the deployment infrastructure.

[w3cbot]

This was discussed during the #did meeting on 21 August 2025.

View the transcript

@context URL in the spec: https://www.w3.org/ns/did/v1.1 does not resolve #901

<ottomorac> w3c/did#901

<ottomorac> Issue opened by Will, regarding the same context URL. Which he claims does not directly resolve to the context file, but instead redirects to the vocab file.

<manu> We should make this resolve: https://www.w3.org/ns/did/v1.1rc1

manu: True does not resolve and it should. However, the way we work, we publish an Release Candidate in that namespace, because people will get ahead and use it and then we get interop issue. We can publish it, but only make RC1 resolve, so that when someone does it wrong, it won't blow up the ecosystem.

ivan: Regardless, I'm messed up by the redirection, and why it doesn't work and who should have done that. Manu should provide direction.

manu: Yes -- to take it offline to go through it.

<Wip> +1 having RC makes sense to me

<ottomorac> +1 makes sense

manu: Before that discussion. Anyone object to do an RC1 published to that location. Then we will update after candidate rec. Will do RC2 and so on as needed until final. Give implementers stability and guidance to what is coming.

---

[msporny]

@pchampin Can you please ensure that the following URL:

https://www.w3.org/ns/did/v1.1rc1

serves the contents of the following file (which will be put in place once PR #905 has been merged):

https://w3c.github.io/did/context/v1.1rc1

Later, when we publish as REC, we will add the finalized v1.1 file (which is almost certainly going to be the v1.1rc1 file).

[pchampin]

@pchampin Can you please ensure that the following URL:

https://www.w3.org/ns/did/v1.1rc1

serves the contents of the following file (which will be put in place once PR #905 has been merged):

https://w3c.github.io/did/context/v1.1rc1

Later, when we publish as REC, we will add the finalized v1.1 file (which is almost certainly going to be the v1.1rc1 file).

Will do, but I'd rather wait until #905 is merged.

Also, am I correct in assuming that https://www.w3.org/ns/did/v1 should now serve the content of https://w3c.github.io/did/context/v1 ?
(currently, it serves https://w3c.github.io/did-extensions/vocabs/v1/context.jsonld)

[pchampin]

actually, I did setup the proxy (which is visible because https://www.w3.org/ns/did/v1.1rc1 now shows Github's 404).
It will serve the correct content once #905 is merged.

Also, am I correct in assuming that https://www.w3.org/ns/did/v1 should now serve the content of https://w3c.github.io/did/context/v1 ?
(currently, it serves https://w3c.github.io/did-extensions/vocabs/v1/context.jsonld)

I didn't do that yet, of course, waiting for #905 to be merged, and for @msporny to confirm that this is the intended plan.

[msporny]

Waiting for @msporny to confirm that https://www.w3.org/ns/did/v1 should serve the content from https://w3c.github.io/did/context/v1.

https://www.w3.org/ns/did/v1 should be a static file served directly from the W3 servers (it should be locked in and not changed -- and not a redirect). This is to ensure that someone that makes a mistake on the Github repo doesn't then cause a static, REC-locked file to accidentally change (just like we don't update historical TR documents in place unless there are serious extenuating circumstances).

[msporny]

The following files now resolve:

• https://www.w3.org/ns/did/v1
• https://www.w3.org/ns/did/v1.1rc1

Closing.

[pchampin]

Waiting for @msporny to confirm that https://www.w3.org/ns/did/v1 should serve the content from https://w3c.github.io/did/context/v1.

https://www.w3.org/ns/did/v1 should be a static file served directly from the W3 servers (it should be locked in and not changed -- and not a redirect). This is to ensure that someone that makes a mistake on the Github repo doesn't then cause a static, REC-locked file to accidentally change (just like we don't update historical TR documents in place unless there are serious extenuating circumstances).

Got it. Now v1 and v1.1rc1 are served from static files stored on w3.org .