Unable to override security context

[OR13]

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.

[OR13]

and of course, hacking node modules to update security vocab breaks every other test I have.

[OR13]

changing these does nothing, I see the document loader does not attempt to load the expected URIs:

SECURITY_CONTEXT_URL: 'https://identity.foundation/context/security',
      SECURITY_CONTEXT_V1_URL: 'https://identity.foundation/context/security-v1.jsonld',
      SECURITY_CONTEXT_V2_URL: 'https://identity.foundation/context/security-v2.jsonld',
      SECURITY_PROOF_URL: 'https://identity.foundation/context/security#proof',
      SECURITY_SIGNATURE_URL: 'https://identity.foundation/context/security#signature',

[OR13]

My goal is to demonstrate that a DIF document loader won't make any network requests, but still supports extensibility :) I'm not trying to reinvent the wheel here.

[OR13]

Pretty sure this is the line that breaks this: https://github.com/digitalbazaar/jsonld-signatures/blob/cf1e11f06da8564ebf46416741f9594b949da493/lib/ProofSet.js#L122

SECURITY_PROOF_URL is not a constant if it needs to be changed to align with a custom document loader.

[OR13]

actually, it may be here: https://github.com/digitalbazaar/jsonld-signatures/blob/cf1e11f06da8564ebf46416741f9594b949da493/lib/ProofSet.js#L290

[dlongley]

My first question is to ask:

When I change:

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

Change it where? Why are you trying to do that? If you're trying to change it such that it modifies the prefix for already defined terms, that would change the global mappings and break everything ... so it makes sense that it wouldn't work. You shouldn't have to do anything with that prefix in an existing context in order to add new terms, extend anything, or load the context from somewhere else.

Could you elaborate on what the problem is or what you're trying to accomplish? I think we may be too down in the weeds here with trying to debug an attempted solution where a different one might be better.

[OR13]

I changed it here: https://github.com/decentralized-identity/context/blob/master/did-v1.jsonld#L8

I added documentation for all sec terms I could find:

https://github.com/decentralized-identity/context/pull/1

Then I tested linked data signatures against all did methods in the universal resolver using jsonld-signatures and the Default / W3 and new DIF Context.

here are the results: https://travis-ci.org/decentralized-identity/context/builds/642227864#L285

[OR13]

My goal was to consolidate all contexts needed to evaluate the security of linked data signatures, and then attempt to minimize them and document them fully for the custom context case. This clearly communicates the barrier to adoption (you need to be able to update json files and markdown), and can be used to support updating of the "decentralized contexts", we can also test compatibility across the cases I mentioned.

[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.