Problems with prefix expansion when defining new JSON-LD proof suite

Recently we have been working on refactoring the JSON-LD context definition for security-v3 to not use a recursive import style for the prior JSON-LD security contexts and have run into the following issue.

Take the following JSON-LD document (Note I know this is not a valid linked data proof, the example has just been simplified to convey only the issue at hand).

{
  "@context": {
    "BbsBlsSignature2020": {
        "@id": "https://w3id.org/security#BbsBlsSignature2020",
        "@context": {
          "@protected": true,
          "id": "@id",
          "type": "@type",
          "xsd": "http://www.w3.org/2001/XMLSchema#",
          "challenge": "https://w3id.org/security#challenge",
          "created": {
            "@id": "http://purl.org/dc/terms/created",
            "@type": "xsd:dateTime"
          },
          "domain": "https://w3id.org/security#domain",
          "nonce": "https://w3id.org/security#nonce",
          "proofPurpose": {
            "@id": "https://w3id.org/security#proofPurpose",
            "@type": "@vocab",
            "@context": {
              "@protected": true,
              "id": "@id",
              "type": "@type",
              "assertionMethod": {
                "@id": "https://w3id.org/security#assertionMethod",
                "@type": "@id",
                "@container": "@set"
              },
              "authentication": {
                "@id": "https://w3id.org/security#authenticationMethod",
                "@type": "@id",
                "@container": "@set"
              }
            }
          },
          "proofValue": "https://w3id.org/security#proofValue",
          "verificationMethod": {
            "@id": "https://w3id.org/security#verificationMethod",
            "@type": "@id"
          }
        }
      }
  },
  "@type": "BbsBlsSignature2020",
  "created": "2020-04-26T04:21:07Z",
  "verificationMethod": "did:example:489398593#test",
  "proofPurpose": "assertionMethod",
  "proofValue": "jx2VhjyZqUT91e2OhzweJA7G2u2UvmiDtIfmr+wUWNHWno+UOAh0FaNpM8Br+5j2JBkH981/nO1I7/9PFaRrng6NXu7vzDroKtuyj6nHGkMmGq4OMmBzIqRnG3ybin/Sxmu5YwqOxPMRsWH3H+2wSA=="
}

Because this library is written against the security-v2 context (e.g https://w3id.org/security/v2) unless explicitly skipped, an input document will be compacted against this context prior to any other proof related operations, here is where this is done today.

However in doing this operation with the JSON-LD document example provided above, the following results.

{
  "@context": "https://w3id.org/security/v2",
  "type": "sec:BbsBlsSignature2020",
  "created": "2020-04-26T04:21:07Z",
  "proofPurpose": "assertionMethod",
  "proofValue": "jx2VhjyZqUT91e2OhzweJA7G2u2UvmiDtIfmr+wUWNHWno+UOAh0FaNpM8Br+5j2JBkH981/nO1I7/9PFaRrng6NXu7vzDroKtuyj6nHGkMmGq4OMmBzIqRnG3ybin/Sxmu5YwqOxPMRsWH3H+2wSA==",
  "verificationMethod": "did:example:489398593#test"
}

Instead of the expected

{
  "@context": "https://w3id.org/security/v2",
  "type": "https://w3id.org/security#BbsBlsSignature2020",
  "created": "2020-04-26T04:21:07Z",
  "proofPurpose": "assertionMethod",
  "proofValue": "jx2VhjyZqUT91e2OhzweJA7G2u2UvmiDtIfmr+wUWNHWno+UOAh0FaNpM8Br+5j2JBkH981/nO1I7/9PFaRrng6NXu7vzDroKtuyj6nHGkMmGq4OMmBzIqRnG3ybin/Sxmu5YwqOxPMRsWH3H+2wSA==",
  "verificationMethod": "did:example:489398593#test"
}

Example on JSON-LD Playground

It appears the prefix sec that is originally defined in security-v1 and recursively imported into security-v2 is not being applied correctly during the compact operation.

Possible Solution

I noted that if instead of doing the compact operation against just the security-v2 context but instead the following

{
  "@context": [ "https://w3id.org/security/v2", {
        "@version": 1.1,
        "dc": "http://purl.org/dc/terms",
        "sec": "https://w3id.org/security",
        "xsd": "http://www.w3.org/2001/XMLSchema"
       }]
}

The issue with the compact result is resolved.

I also verified that this works when these lines are changed to

    document = await jsonld.compact(
      document, [ constants.SECURITY_CONTEXT_URL, 
       {
        "@version": 1.1,
        "dc": "http://purl.org/dc/terms",
        "sec": "https://w3id.org/security",
        "xsd": "http://www.w3.org/2001/XMLSchema"
       }],
      {documentLoader, expansionMap, compactToRelative: false});

Happy to submit a PR if this is the best solution to the problem although it appears the real issue is with the jsonld.js compact operation.

[dlongley]

@tplooker, Yes, to making the proof suite expect those possible values.

[tplooker]

Note the missing #. Since sec no longer matched the URL prefix in https://w3id.org/security#BbsBlsSignature2020, it was no longer used.

Ah right that makes a lot more sense now, thanks for the clarification and to make things clear for others on the thread too, doing this

document = await jsonld.compact(
      document, [ constants.SECURITY_CONTEXT_URL, 
       {
        "@version": 1.1,
        "dc": "http://purl.org/dc/terms",
        "sec": "https://example.com/completely-different-url",
        "xsd": "http://www.w3.org/2001/XMLSchema"
       }],
      {documentLoader, expansionMap, compactToRelative: false});

Where the document is that shown at the start of the issue, will yield

{
  "@context": "https://w3id.org/security/v2",
  "type": "https://w3id.org/security#BbsBlsSignature2020",
  "created": "2020-04-26T04:21:07Z",
  "proofPurpose": "assertionMethod",
  "proofValue": "jx2VhjyZqUT91e2OhzweJA7G2u2UvmiDtIfmr+wUWNHWno+UOAh0FaNpM8Br+5j2JBkH981/nO1I7/9PFaRrng6NXu7vzDroKtuyj6nHGkMmGq4OMmBzIqRnG3ybin/Sxmu5YwqOxPMRsWH3H+2wSA==",
  "verificationMethod": "did:example:489398593#test"
}

because the sec prefix is defined twice, differently, it forces the expansion of the prefix using the first definition as that is what is the definition of BbsBlsSignature2020 uses.

Until we move away from using the prefix, yes, that will be the expected value.

Ok understood does it make sense to expand our match proof logic to match on the following three values

BbsBlsSignature2020
sec:BbsBlsSignature2020
https://w3id.org/security#BbsBlsSignature2020

I believe this will future proof the suite and perhaps should be a general rule for all future JSON-LD proof suites? As that way when a new version of jsonld-signatures is released programmed against the v3 context, this suite should work with no further changes required?

Yes, I think they are trouble and we should move away from them – for precisely the kinds of the reasons you’ve brought up here. If we could keep prefixes contained to contexts only (so they didn’t leak into data), then they could be used as shortcuts there and it wouldn’t be such an issue, but a feature to enable that behavior just missed the boat in JSON-LD 1.1. Maybe in a future version we can do that, but until then, I do recommend just avoiding them entirely at this point, even thought it makes for a more verbose context.

+1 understood now