Add JSON-LD Context for v1.1

[msporny]

This PR is an attempt to address issue #859 and #850 by adding a v1.1 JSON-LD Context and updating all examples in the specification to use the new context URL.

---

Preview | Diff

[decentralgabe]

non blocking, I am struggling to remember where we landed on w3id ... since we have registries in this WG could we migrate what's on w3id to one of the w3c managed registries?

[msporny]

Here's the latest discussion on w3id.org for the controller document: w3c/controller-document#66 (comment)

Note that this URL https://w3id.org/security redirects to the security vocabulary maintained by the VCWG for the Data Integrity specifications. The only thing on w3id.org are redirect instructions to the VCWG document:

https://github.com/perma-id/w3id.org/blob/master/security/.htaccess

We need to add text to the following effect when we make the DID Core spec depend on the controller doc spec (effectively, "the hash of the base context is X... don't ever load it from the network"):

https://w3c.github.io/controller-document/#json-ld-context

Does that answer your question @decentralgabe ? We've got a few more PRs we need to do to align the guidance in the controller document and DID Core (and hope to do those alignments in future PRs after we've based DID Core on the controller doc spec).

[iherman]

@decentralgabe, the issue was raised (several times) and, at the moment, there is no change (in agreement with the w3c management on the DI CR).

[msporny]

there is no change (in agreement with the w3c management on the DI CR).

Meaning, W3C Management didn't see an issue with the way w3id.org is operated today and don't see a reason that W3C needs to take over management of the website. This is because we tell people to not load these contexts from the network, provide static copies, and provide hashes for the contexts in the specs.

[decentralgabe]

Thanks, yes that addresses my comment. The language you noted will be useful to add.

[iherman]

I am a little bit worried by the proliferation of somewhat identical context files. We are clearly ignoring the DRY principle.

Specifically: by using the Context import of JSON-LD, we could import, e.g., https://w3id.org/security/multikey/v1 or https://w3id.org/security/jwk/v1 and avoid repeating the information in this context file.

I realize that this may complicate the processing steps from a security and efficiency point of view (regarding caching, integrity checking, etc). But this approach may lead to maintenance issues down the line.

I approve the PR insofar as this is not a blocking comment.

[msporny]

@iherman wrote:

I realize that this may complicate the processing steps from a security and efficiency point of view (regarding caching, integrity checking, etc). But this approach may lead to maintenance issues down the line.

Yes, that's the problem that was raised as a "security concern" a year or more ago, that imported contexts might be loaded from the network or trigger "extra processing" that "might be dangerous". All of that was analyzed as FUD -- if you cache contexts permanently and never load them from the network, then this isn't an issue. That said, people will still complain about "the complexity of not knowing what is being imported", which again is FUD, but it's easier to just repeat the declarations than import them (and have to deal w/ the FUD).

There are two benefits in including all content in the context file:

• A human analyzing it to ensure it has what you think it has is easier, and
• There is a slight performance boost by having everything local (though, it's negligible)

To put it another way, if we imported contexts, I expect that we'd see objections (again).

[iherman]

To put it another way, if we imported contexts, I expect that we'd see objections (again).

Ok, this is probably not worth the trouble. The is on us (maintainers of the spec), but we will live.