Unable to override security context

When I change:

"sec": "https://w3id.org/security#",

to

"sec": "https://identity.foundation/context/security#",

Linked Data Signatures no longer work:

Error: No matching proofs found in the given document.

However… that does not make any sense, since I am just trying to define vocabulary.

I can see in the documentation:

   * Important note: This method assumes that the term `proof` in the given
   * document has the same definition as the `https://w3id.org/security/v2`
   * JSON-LD @context.

This means that in order to properly override the security context, I need to hack node modules and edit security vocab…

This seems like a lot of work to get the document loader to behave as expected…

What is the best way of overriding the security context without editing node_modules?

I don’t think its possible to do given the current module structure:

https://github.com/digitalbazaar/jsonld-signatures/blob/59372054de4c0f8a74704a0f27f7eddd3d3727e4/lib/documentLoader.js#L9

If you are trying to use a customDocumentLoader, you should be able to control how https://w3id.org/security/v2 is loaded… it should not be using a bundled module.

[dlongley]

OR13,

A change to the core sec prefix is not a trivial thing, it can break interoperability for “JSON-only” verifiers (they would need to upgrade to support the new change). That prefix is used to define all of the URLs that the terms map to. A change like that makes it such that any signature signed using the previous definition will not be the same as a signature signed using this new version (using the same deterministic private key). In other words, it can be seen as a breaking change for at least a subset of the community, and one that needs to be discussed in the wider community before it happens. So, it’s not that it can’t happen, but it’s essentially a “hard fork” that, again, merits discussion so people can understand the consequences.

We’re likely to have to do this kind of “hard fork” once LD proofs get to a W3C Recommendation (hopefully getting on its way to that this year via a new W3C WG) as we can put things in the w3 namespace, but, ideally, we’d only do this once. I would say it’s not worth changing what URLs the security terms map to right now – we can instead just move the w3id.org entry to redirect to the new central location for the vocab, etc. This is a backwards-compatibly safe way to do it.

[OR13]

Thanks! This is super helpful.

If I can get the documentation updated, and we can find a new place to host it, it sounds like using w3id.org to point to that new central location is the best solution. Until we experience the hard fork when this stuff hits W3C Recommendation.