Possible bug with `@json` being treated as invalid `type` in frame

[dlongley]

This issue stems from: digitalbazaar/jsonld.js#506

It relates to step 1.3 in the Framing Algorithm where a frame's validity is being checked.

It seems that either that step doesn't appropriately allow for @json (which is a valid JSON-LD type) or that the algorithm should have stopped recursing when @json was detected and just accepted whatever the value was (since it cannot recurse into @json datatypes, presumably). I didn't look more closely to determine which way to go here with the algorithm (whether it's the former simple fix or not), but I expect that some test cases could help shake it out.

[pasquale95]

Hi @dlongley, have you news on this issue?
Have contributors had a look inside of the PR and gave some feedback? If there are issues in the PR let me know and I will fix it, otherwise I would advice to merge it since this feature is quite requested for correctly frame JSON-LD credentials.

[davidlehn]

@pasquale95 I'm not sure about any required spec changes. However, it would be good to propose some simplified tests in this repo to check the jsonld.js code change works. I assume tests can use inline contexts. If there are variations of the issue, it would be good to add them in case there are other code paths that need a fix. We need the tests so all implementations will have the same behavior.

[pasquale95]

@dlongley @davidlehn I don't exactly understand how testing works in this repository, but I've defined a small example in my PR #144.
Could you please have a look and tell me if it's fine?
For better understanding I would still suggest to have a look at the original issue description.

[pasquale95]

@dlongley @davidlehn any update on this PR?

[gkellogg]

There's some odd special-case stuff going on here. Because "ex:info" is defined with @type: @json, the content of the frame gets expanded as a value object. Normally, the value either needs to match exactly, or include a wildcard, but you can't wildcard the value, as it is treated as raw JSON.

I first tried the following:

{
  "@context": {
    "ex": "http://example.org/vocab#",
    "ex:info": {"@type": "@json"}
  },
  "ex:info": {
    "@value": {},
    "@type": "@json"
  }
}

but that fails, as I described, as it is expanded to { "@value": { "@value": {}, "@type": "@json" }, "@type": "@json" }

However, I got it to work as follows:

{
  "@context": {
    "ex": "http://example.org/vocab#",
    "ex:info": {"@type": "@json"}
  },
  "http://example.org/vocab#info": {
    "@value": {},
    "@type": "@json"
  }
}

(it would also work with just "http://example.org/vocab#info": {}, although it would match values which were't JSON value objects.

No spec changes are necessary, but an informative note to describe how to match JSON literals would be useful.

[pasquale95]

@gkellogg if this is not a bug, can you advice me on how should I define the correct frame for this json-ld?

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vdl/v1"
  ],
  "type": [
    "VerifiableCredential",
    "Iso18013DriversLicenseCredential"
  ],
  "credentialSubject": {
    "id": "did:key:z6MkiiViqftXJKZNnWwpS7aKM7jiJBbGiFEZzPSKYB8p8oyy",
    "license": {
      "type": "Iso18013DriversLicense",
      "document_number": "542426814",
      "family_name": "TURNER",
      "given_name": "SUSAN",
      "portrait": "/9j/4AAQSkZJRgABAQEAkACQA...gcdgck5HtRRSClooooP/2Q==",
      "birth_date": "1998-08-28",
      "issue_date": "2018-01-15T10:00:00Z",
      "expiry_date": "2022-08-27T12:00:00Z",
      "issuing_country": "US",
      "issuing_authority": "AL",
      "driving_privileges": [
        {
          "codes": [
            {
              "code": "D"
            }
          ],
          "vehicle_category_code": "D",
          "issue_date": "2019-01-01",
          "expiry_date": "2027-01-01"
        },
        {
          "codes": [
            {
              "code": "C"
            }
          ],
          "vehicle_category_code": "C",
          "issue_date": "2019-01-01",
          "expiry_date": "2017-01-01"
        }
      ],
      "un_distinguishing_sign": "USA"
    }
  }
}

The context https://w3id.org/vdl/v1 is available here (the URL itself is not working anymore). Using your testing nomenclature, the document above is the in.jsonld and my goal is to frame the driving_privileges field which is of "@type": "@json".

I tried with the frame below but it doesn't work:

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://w3id.org/vdl/v1"
  ],
  "type": ["VerifiableCredential", "Iso18013DriversLicenseCredential"],
  "credentialSubject": {
    "@explicit": true,
    "license": {
      "type": "Iso18013DriversLicense",
      "@explicit": true,
      "driving_privileges": {}
    }
  }
}

Any help would be really appreciate.

[gkellogg]

In the frame, you’ll need to use some other term expanding to the same IRI for “driving_privilages”; other the full IRI it expands to, itself, or a compact IRI form. The issue is that the frame gets expanded when framing, then it is no longer an empty value, but an expanded JSON value, which prevents it from matching anything.

[pasquale95]

I don't understand. The issue is in the fact that "@type": "@json" is considered as an invalid type inside the frame, but this is incorrect since such type is a valid JSON-LD type.
The frame gets expanded and the json attribute gets expanded as well, but the check of the existence of such attribute declared in the frame (e.g. driving_privileges from the frame.jsonld) inside the document to frame (e.g. in the in.jsonld) is done by looking if the attribute key in expanded form (namely https://w3id.org/vdl/v1/#driving_privileges) is amongst the keys inside the document to frame in expanded form (see here). Hence, when the subframe {"@type": "@json", "@value": {}} is checked by _validateFrame, the @json type should be among the ones accepted. Therefore this PR.

Additionally, I don't understand why the @json attributes should be handled differently from the other attributes inside the frame. This would make framing more cumbersome without any specific reason.

[gkellogg]

The key is that the Framing algorithm works by first expanding the frame, which in the original case, results in the following:

[
  {
    "http://example.org/vocab#info": [
      {
        "@type": "@json",
        "@value": {
          "@value": {},
          "@type": "@json"
        }
      }
    ]
  }
]

To match a value, it would need to exactly match that value object (note the value object, itself, containing @value, rather than being a template to match anything with @type: @json. This is described in Matching on Values and the Value Pattern Matching Algorithm, and this is not a kind of wildcard.