Where will the DID contexts(s) live?

[dmitrizagidulin]

Will the eventual https://www.w3.org/2019/did/v1 and the current https://w3id.org/did/v0.11 context for DIDs be version controlled in this repository now, or will it continue to reside at the CCG repo?

If the former, I would propose to pull over PR #272 - Add a contexts/README.md to explain the DID context versioning scheme over to this repo as well, since the topic of @context versioning may be confusing to the wider audience.

[OR13]

I recommend that both the human documentation and the JSON-LD contexts be hosted under this repo, and that we minimize use of / or links to 3rd party services which may have the ability to alter documentation or contexts in ways that impact usability or security.

It will also be easer to ensure documentation is up to date if a single PR can fix both the context and the human readable content.

Understanding of context processing is a requirement for understanding the security and usability of DIDs, I'm very much in favor of centralizing that trust here, I think many people don't realize how awesome JSON-LD is, and since DID Documents are JSON-LD, we have a responsibility to be up front about the security implications of working with JSON-LD.

[iherman]

My question/comment is on the URL used for the context file. At the moment, it ishttps://www.w3.org/2019/did/v1. I do not know whether, by now, this is cast in concrete; in many cases such context files (and possible namespace documents if separate terms are to be properly defined in RDF, too) are put under /ns at W3C. Like, for example, http://www.w3.org/ns/anno.jsonld for annotations or https://www.w3.org/ns/pub-context for publication manifests. (I know that the VC context file is under /2018/, though).

If this is not yet too late, I would propose to move the context file to https://www.w3.org/ns/did/v1.

Whichever way we go, setting up a redirect from that URL to a github repo file shouldn't be a problem. This is how, for example, https://www.w3.org/ns/pub-context is managed (although in that case, the context file is managed in a separate repo on github).

[msporny]

On the 2019-10-15 call, we got to consensus on these items:

• Host the context on W3C.
• Redirect, during FPWD/WD to github pages for w3c/did-spec... then lock it down (serve it directly from W3C) once we hit CR/PR/REC.

We didn't have consensus on:

• What the URL will be, whether or it will be hosted at w3.org/ns/ or a date-space
• Whether or not we'll version the context.

We need to get consensus on the last two in order to make progress. I heard concern from @iherman and @philarcher on the latter two items.

[dmitrizagidulin]

As I've argued in the DID context versioning PR, versioning the context is highly desirable (and even necessary, in our situation).

[OR13]

without versioning, how can we offline these contexts? won't that lead to lots of confusion over which offline context was used?

I'm in favor of datespace over namespace, appears to add more useful information than ns.

[iherman]

This issue was discussed in a meeting.

• No actions or resolutions

View the transcript

5.1. context hosting #5
Manu Sporny: See Issue #5
Brent Zundel: Opinions?
Ivan Herman: There are two issues. Where and what URL.
… The usual place is w3.org/ns/…
… I propose we use the same method. The document can be stored elsewhere and have a redirect.
Manu Sporny: https://w3c.github.io/vc-data-model/#example-1-a-simple-example-of-a-verifiable-credential
Manu Sporny: We had this discussion in VCWG.
… We decided to not use ns because of the emotional response.
Manu Sporny: https://www.w3.org/2018/credentials/v1
Manu Sporny: There is not a redirect.
… During working drafts we redirected to the github updated version.
… The other thing was say in the spec that we will not change the context after the spec is finalized.
… This allows caching or hardcoding by developers.
… I hope we can use the same approach.
Ivan Herman: Whether we use ns or not: I find the date space more difficult personally
… but I won’t lie down the road over this.
… Redirect to github during development is my intention also.
… After we go to recommendation, it should be fixed.
Ivan Herman: I don’t know if we need to discuss versioning right now.
Phil Archer: The discusion re: persistant URL is of interest to me.
Phil Archer: See W3C Peristence policy
Phil Archer: The date space may not persist.
… Version numbers are problematic, ask DanBri and the Foaf URL
Amy Guy: I wanted to remind people that having the context on github made actual use difficult.
Orie Steele: +1 for hosting on github pages
Dmitri Zagidulin: Can we please host at github with a proper file extension.
Manu Sporny: Versioning must be accounted for.
… Most problems were with the hosting not the actual developers.
… Extensions and Mime types in particular.
Dmitri Zagidulin: (would like to remind everyone about the writeup / explainer about versioning contexts, over at w3c-ccg/did-spec#272 )
Manu Sporny: During development will create a moving target necessarily.
… VCWG had the same debates.
… Can we summarize where we have consensus?
Brent Zundel: Can we wrap up?
Justin Richer: Some people will see the URLs as just a place for comparing.
Manu Sporny: +1 to Justin_R — yes, this isn’t a “purely Linked Data” world we’re working in here…
Manu Sporny: also – just to be clear… I’d personally be opposed to /ns/ URL and non-versioned (and we have good reasons for that)… I’ll have to see what our corporate position is.
Ivan Herman: Amy confirmed that redirection can be set up with proper types, so that is not a problem
Brent Zundel: Let’s move discussion to the issue.
Manu Sporny: I think we have consensus around hosting at W3C. Versioning on the github.
… No consensus on ns or versioning.
… I will summarize in the issue.
Manu Sporny: I summarized context issue here – #5 (comment)

[OR13]

Some discussion from the CCG call: w3c-ccg/community#88

TL;DR; did spec is one of the entry points for JSON-LD, we need to define clearly in this repo readme how to contribute to JSON-LD contexts and documentation, and how to work with associated topics like VCs.

[msporny]

We didn't have consensus on:

• What the URL will be, whether or it will be hosted at w3.org/ns/ or a date-space

For whatever reason, there is a non-trivial number of technologists that go apoplectic when we even mention the word "namespace" and divert the discussion into all the reasons "namespaces were a horrible idea for XML, a horrible idea for RDF, and a horrible idea now." We should avoid putting people using this technology into the position of having to have that discussion with anyone, because there are no winners when you trigger that discussion. So, let's not trigger that discussion by using the /ns/ namespace. :)

There are also other reasons having to do with versioning that we may want to avoid the /ns/ base URL elaborated upon below.

We didn't have consensus on:

• Whether or not we'll version the context.

We spent A LOT of time on this exact question in the Verifiable Claims WG. I went off looking for the links/threads and found 9 out of many more of them... and it's all hard to follow. So, I'm going to attempt to summarize here.

The Verifiable Credentials specification states the following about the @context:

The value of the @context property MUST be an ordered set where the first item is a URI with the value https://www.w3.org/2018/credentials/v1. For reference, a copy of the base context is provided in Appendix § B. Base Context. Subsequent items in the array MUST express context information and be composed of any combination of URIs or objects. It is RECOMMENDED that each URI in the @context be one which, if dereferenced, results in a document containing machine-readable information about the @context.

NOTE: Though this specification requires that a @context property be present, it is not required that the value of the @context property be processed using JSON-LD. This is to support processing using plain JSON libraries, such as those that might be used when the verifiable credential is encoded as a JWT. All libraries or processors MUST ensure that the order of the values in the @context property is what is expected for the specific application. Libraries or processors that support JSON-LD can process the @context property using full JSON-LD processing as expected.

The data available at https://www.w3.org/2018/credentials/v1 is a static document that is never updated and SHOULD be downloaded and cached. The associated human-readable vocabulary document for the Verifiable Credentials Data Model is available at https://www.w3.org/2018/credentials. This concept is further expanded on in Section § 5.3 Extensibility.

That text was hard won and represents a best practice when attempting to build bridges between the Linked Data community and those that don't want to use (but still stay compatible with) Linked Data (which is an important subset of the community working on VCs and DIDs).

Fundamentally, we need to version the context and we need to year-stamp the URL... here's why:

We need to version the context .../did/v1 because people will want a frozen in time document that they can refer to, cache, and hard code into their applications. People that don't want to do JSON-LD processing will use that string to trigger certain processing modes in their application.

We need to year-stamp the URL .../2019/did/v1 because 1) we do want to signal to developers how old the thing they're using is and 2) we may need to publish revisions that are equivalent in semantics, but different in implementation.

Regarding reason #1 above - developer signalling - We do this for the same reason, the LD Security specs put dates on all cryptographic-y things -- so people know, hmm... I'm using SecureFoo2011 ... and it's 2019... I should probably check to see if there is anything more modern published than that.

Regarding reason #2 above - publishing revisions - We may do .../2019/did/v1 and five years later, may find a subtle but nasty bug, or want to upgrade to JSON-LD 1.2 and want to publish .../2024/did/v1 ... and at that time, we'll probably have to publish this as well .../2024/did/v2. This versioning scheme allows future WGs to potentially make significant breaking changes between v1 and v2 and not affect deployed/legacy implementations. This decoupling is very powerful and ensures that the work isn't saddled with more legacy concerns than necessary when moving forward.

For all of these reasons, we should publish the context at:

https://www.w3.org/2019/did/v1

and the vocabulary at:

https://www.w3.org/2019/did/

[iherman]

We need to get consensus on the last two in order to make progress. I heard concern from @iherman and @philarcher on the latter two items.

To be very clear, as far as I am concerned, I am fairly neutral on both these issues. I just have comments:

• Other communities (that face similar issues with developers averse to RDF) have decided to use /ns URI-s (e.g., Web Annotation) and that issue was never raised; the advantage of /ns is that it is short and easy to remember, plus:
• I repeat @philarcher's argument on the call: the W3C setup (including the agreements with MIT) is such that the content of https://www.w3.org/TR/* and https://www.w3.org/ns/* will remain alive in perpetuity, even if W3C disappears at some point. No such commitment exists, afaik, for date space, i.e., for https://www.w3.org/2019/*. Whether this is a consideration we want to take on board is not for me to tell. (@philarcher is that correct?)
• On versioning: I am afraid this is a debate that have been raging ever since I remember... But there is a tendency for such vocabularies to stay cast in concrete in practice, even if the content evolves. The foaf namespace URI is still xmlns.com/foaf/0.1, and the community has never changed it that after all (although that was the plan, initially). The same for the RDF namespace (ugly as it may be). I realize JSON-LD is a little bit different because the caching issue becomes more explicit, but if there is a commitment that the context file does not change frequently (say, once every 2-3 years) then this should be manageable...

But these are just my comments, not serious concerns. I go with whatever the WG feels comfortable with; at this point, I think it is more important to decide so that we can move on.

[iherman]

One more note on versioning, this time in favor of having it explicit in the URL. I do not know whether it may be required, by some DID methods, to store an immutable DID document. If that is the case, then the fact of referring to a stable and also immutable context file does make sense (even if, strictly speaking, even if the context file changes the DID document does not, but the information deduced from it may change, and that may not be acceptable).

[msporny]

I repeat @philarcher's argument on the call: the W3C setup (including the agreements with MIT) is such that the content of https://www.w3.org/TR/* and https://www.w3.org/ns/* will remain alive in perpetuity, even if W3C disappears at some point. No such commitment exists, afaik, for date space, i.e., for https://www.w3.org/2019/*. Whether this is a consideration we want to take on board is not for me to tell. (@philarcher is that correct?)

Since we are freezing these contexts when we hit PR, I don't think this is a concern. For example, our software libraries, which do JSON-LD processing, ship with the static contexts. For those that don't to JSON-LD processing, they just do a string compare. So, if W3C ever disappears, our application space for VCs and DIDs will be unaffected because of the way we've designed the technologies.

[msporny]

I do not know whether it may be required, by some DID methods, to store an immutable DID document.

Most DID Methods have this requirement, because there are use cases where you have to be able to go back in time for a DID Document and interpret its contents as it existed in the past, which means that if the JSON-LD Context were to ever change (semantically), that historical document could get misinterpreted.

[iherman]

I do not know whether it may be required, by some DID methods, to store an immutable DID document.

Most DID Methods have this requirement, because there are use cases where you have to be able to go back in time for a DID Document and interpret its contents as it existed in the past, which means that if the JSON-LD Context were to ever change (semantically), that historical document could get misinterpreted.

O.k., that is a compelling argument for the versioning indeed.

[TallTed]

Last I knew, the date URIs (w3.org/yyyy/group/etc) were based on the inception year of the group publishing the doc, not the year of publication of that doc. This may be relevant to keep in mind in this discussion (or it may have changed without my noticing, in which case, please disregard this comment).

[iherman]

Last I knew, the date URIs (w3.org/yyyy/group/etc) were based on the inception year of the group publishing the doc, not the year of publication of that doc.

Although this is not some sort of a cast-in-concrete rule, it is indeed the way it is usually done.

[iherman]

Following @msporny's lead in #76, I try to bring a closure to this issue.

I think we seem to have, by now, a consensus on:

• Host the context on W3C.
• Redirect, during FPWD/WD to github pages for w3c/did-spec... then lock it down (serve it directly from W3C) once we hit PR/REC. (It is up to the editor's whether they prefer to keep the context file in a separate repo or as part of the spec's repo.)
• The context URI includes a version identification.

This changes the consensus level of #5 (comment) insofar as the version in the context seems to be not only preferred, but even necessary for some (like @dmitrizagidulin, per #5 (comment)). I have also removed the CR phase as a possibility to "freeze" the context as the time of freezing this; implementations may come up with issues during CR, so I we should keep the redirect until the publication of the PR. It is only at PR phase that the content of the spec become cast in concrete, and I believe the context file should follow that.

We don't have consensus on:

• What the URL will be, whether or it will be hosted at w3.org/ns/ or a date-space

I will, therefore, add two comments to the issue, use thumbs up/down (and only those) to cast your vote. Only explicit votes will count. I.e., speak now or forever hold your peace...

I would say give this a week before we declare a winner.

[iherman]

The context file's URL should be: https://www.w3.org/ns/did/v1

[iherman]

The context file's URL should be: https://www.w3.org/2019/did/v1

[iherman]

@burnburn @brentzundel has this issue been closed? At the moment there are practically no votes on either way. Would be good to have a decision on this for the FPWD.

(To be clear: it is, process-wise, o.k. to change the context URI in the spec later, but it would not be a good idea to do so. Ie, not finalizing this issue does not mean stopping the FPWD publication.)

Related to #91

[brentzundel]

what about https://www.w3.org/ns/did/2019/v1, that way we have the preservation guarantees of ns AND the date information?

[iherman]

@brentzundel that is doable

[burnburn]

I like it @brentzundel . Let's see if any objections before 5 Nov call. If no serious flaws with it (other than not liking the character string "ns"), we will go with this.

[msporny]

Let's see if any objections before 5 Nov call. If no serious flaws with it (other than not liking the character string "ns"), we will go with this.

-1 for these reasons:

• it is yet another unnecessary variation
• We don't need the preservation guarantees because we include the context and hash in the spec itself.
• it doesn't solve the kneejerk reaction to "ns"

Strongly opposed.

[rhiaro]

From a content-type perspective it looks like it is served correctly

[burnburn]

Objection to close and objection (as editor) on the resolution. I don't see how the WG was educated on the topic before the straw poll was called, specifically, I can't see where the points against the straw poll item was discussed in the minutes.

@msporny there are no editorial grounds for objection as the resolution was properly taken, since opportunity was made available for anyone on the call to argue for any position they preferred. Neither Dave Longley nor Dmitri argued in the direction you prefer, so we had no reason to believe you would object at this point.

However, any individual not on the call can object, as you have done, that their position was not sufficiently represented during the discussion. So as of now, this change is on hold and must be reverted or marked in the document as still under discussion. If neither of those steps occurs before evening Ivan's time (@iherman ), he has been instructed to halt publication of the FPWD. Not publishing would be unfortunate.

Personally, I believe that those on the call who care about this issue were aware of your opinions, understood them, and took them into account during the decision. However, I can't read minds (yet), so we have to resolve this as stated above.

[dmitrizagidulin]

@burnburn Minor correction - I was not on that call, otherwise I would have brought up Manu's point.

[burnburn]

@burnburn Minor correction - I was not on that call, otherwise I would have brought up Manu's point.

Apologies. It doesn't matter at this point, though. Manu has raised an objection and we will address it or the editors must revert.

[msporny]

If neither of those steps occurs before evening Ivan's time (@iherman ), he has been instructed to halt publication of the FPWD. Not publishing would be unfortunate.

You don't need to hold the FPWD hostage over this... that's extremely bad form.

Go ahead and publish, I'm rescinding my objection because of the unnecessary coupling the chairs and staff have made between this decision and the FPWD.

This decision is going to inevitably kick off a request to do a normative change to the VC spec if the VCWG is re-chartered and has a number of downsides that are problematic (and were not discussed during the call).

[msporny]

Neither Dave Longley nor Dmitri argued in the direction you prefer

These two are different people, with different opinions on matters. We often don't agree with one another (but eventually get there over time). No one should assume that any of us speak for the other.

I'm standing down, publish the FPWD, we'll resolve this later.

[burnburn]

You don't need to hold the FPWD hostage over this... that's extremely bad form.

Go ahead and publish, I'm rescinding my objection because of the unnecessary coupling the chairs and staff have made between this decision and the FPWD.

Whoa, whoa, whoa. You objected to a change that went into a document that will be published in a permanently fixed form (FPWD). Holding off on publishing was done FOR YOU, MANU. ONLY FOR YOU.
Believe me, no one else is objecting to the current content of the document. If you are happy for FPWD to go forward regardless of the timing of when this change is backed out, GREAT!

The only coupling here was to avoid YOU complaining that the group went ahead and published an FPWD with a change you didn't agree to.

If you are NOT objecting to that, let's publish the FPWD as planned. If the change is backed out before then, wonderful. If not, okay. Either way your objection is in no way being dropped or ignored.

Please feel free to reach out to me or Brent directly if you would like to further discuss your belief that the chairs are in any way trying to force you to do anything.

[burnburn]

Manu and I just talked on the phone. @iherman based on Manu's comments above regarding publication of the FPWD there is no reason to hold up tomorrow's publication. The group will revisit this issue if/when @msporny would like an opportunity to explain his concerns with the approach taken in the resolution.

[iherman]

@burnburn great. However, I would propose not to close this issue, in contrast to what we said above.

[peacekeeper]

We could add a NOTE or ISSUE box to https://w3c.github.io/did-core/#contexts, stating that this is still under discussion?

[msporny]

If you are happy for FPWD to go forward regardless of the timing of when this change is backed out, GREAT!

Yes, happy for the FPWD to go out in it's current state.

The only coupling here was to avoid YOU complaining that the group went ahead and published an FPWD with a change you didn't agree to.

Thanks for being sensitive to this... my intent was not to hold up the FPWD, trusting that I could object here and the group would revisit the issue at some undetermined time in the future.

If you are NOT objecting to that, let's publish the FPWD as planned.

Not objecting to the publication of the FPWD, please proceed with the content as is.

I would like the opportunity to discuss after the FPWD publication in it's current state what happens now that the WG has chosen to go this direction (new information -- basically, we just did something differently from VCWG and we need to reconcile the two approaches to avoid confusing the developer/W3C WG community) and see if the WG would like to reconsider based on that new information.

[OR13]

related...

w3c/did-extensions#3
#187

[OR13]

IMO, this is a critical blocker, and cannot be closed.

[msporny]

My concern here is that the group doesn't have a strategy for versioning and caching and contexts (and registry entries) and we're making decisions in a piecemeal fashion that may paint us into a corner. I don't think we can close this issue w/o understanding what that strategy is... whatever it is.

So, next step is to publish a concrete strategy for versioning and documenting that thinking in the DID Core implementation guide.

[dmitrizagidulin]

@msporny

So, next step is to publish a concrete strategy for versioning and documenting that thinking in the DID Core implementation guide.

I agree, and I would propose the text in w3c-ccg/did-spec#272 as the starting document for that versioning strategy.

[OR13]

w3c/did-extensions#17

^ related

[msporny]

We've made progress on this:

• DID Core context lives in DID Core Registries.
• W3C ns points to DID Core registries.

We still need to decide:

• Where 3rd party contexts can live.
• Versioning strategy for core context.
• Versioning strategy for extensions context?
• Do we need a suggested versioning strategy for 3rd party extensions?

[lrosenthol]

Where 3rd party contexts can live.

Why can't they live anywhere they want? It's my context, I'll host it in my environment...

Do we need a suggested versioning strategy for 3rd party extensions?

Same answer. It's my extension, let me versioning it any way I want...

[OR13]

@lrosenthol yes, i agree. I have added an example of such to the did core registries:

https://w3c.github.io/did-core-registries/#gpgverificationkey2020

[rhiaro]

I think this issue can be closed, given development of the DID Spec Registries, which is where the contexts now live.

[brentzundel]

Marked pending close for more than a week, closing.

[iherman]

This was a temporary glitch with github. It should be all right now.

…

On 5 Feb 2021, at 15:50, Marek ***@***.***> wrote: Hello all, curious where is "https://www.w3.org/2018/credentials/v1 <https://www.w3.org/2018/credentials/v1>" now? It resolves to a Github 404 page, so our builds and tests are failing. Should we use another URL? Might be good to update all the documentation and give a warning prior to removing a page like that.