Emoji as tags in JSON

[OR13]

It's difficult to implement tagging of "object keys" in JSON because of the requirement that they be strings.

The OWF reference implementation in python uses YAML tags to work around this, but that adds additional language and complexity to implementations.

An alternative is to embed the "tag" as unicode in the JSON key... here is an example:

{
  "array_with_recursive_sd": [
    "boring",
    {
      "foo": "bar",
      "🔴baz": {
        "qux": "quux"
      }
    },
    [
      {
        "🟡": "foo"
      },
      {
        "🟡": "bar"
      }
    ]
  ],
  "test2": [
    {
      "🟡": "foo"
    },
    {
      "🟡": "bar"
    }
  ]
}

[danielfett]

I thought about this, but excluded any "tag the keys" solution as it will never be free from conflicts. (But I do admit that using red and orange dots is unusual enough to make conflicts unlikely in practice :-) )

Also, I don't think this works well for array elements?

[OR13]

yes, as you can see the array element format, is also hybridized... still need an object to represent disclosing an array element.

All of these tricks to figure out what is disclosable or not when issuing are implementation details. You could use JSON Pointer, YAML, or some specific JSON syntax.

When implementers sit down to attempt conformance, this is a major hurdle to quickly confirming the existing test vectors generated from python.

I think it would be best to have 0 additional dependencies for this part (a JSON solution would be best)... Comparing YAML vs JSON Pointer, I think JSON Pointer would be better, since it does not bring in a new language.

We're currently using the YAML approach, but I wrote an inverter that converts from a sd-jwt to a YAML schema with tags here: https://github.com/transmute-industries/vc-jwt-sd

Here are a few examples side by side:

array_with_recursive_sd:
  - boring
  - foo: bar
    !sd baz:
      qux: quux
  - - !sd foo
    - !sd bar
test2:
  - !sd foo
  - !sd bar

{
      "array_with_recursive_sd": [
        "boring",
        {
          "foo": "bar",
          "🔴baz": {
            "qux": "quux"
          }
        },
        [
          {
            "🟡": "foo"
          },
          {
            "🟡": "bar"
          }
        ]
      ],
      "test2": [
        {
          "🟡": "foo"
        },
        {
          "🟡": "bar"
        }
      ]
}

{
  "/array_with_recursive_sd/0": "boring",
  "/array_with_recursive_sd/1/foo": "bar",
  "/array_with_recursive_sd/1/🔴baz/qux": "quux",
  "/array_with_recursive_sd/2/0/🟡": "foo",
  "/array_with_recursive_sd/2/1/🟡": "bar",
  "/test2/0/🟡": "foo",
  "/test2/1/🟡": "bar"
}

With syntax highlighting the yaml example looks very nice... but I still feel that adding YAML as a critical dependency is probably not the best path to increasing implementation / adoption.

[danielfett]

Ah thanks, I didn't realize that the other color has a different meaning.

I don't consider YAML a critical dependency... but it allows for the (practically only) clean and compact definition of the test cases.

I propose that anybody who needs a different format implements a translation (that needs to be run only when updating test cases). I thought about pulling the test cases into their own repository, I suppose that translators into other formats could live there as well, automatically providing us with different representations of the same test cases.

[OR13]

Unless you plan on adding language about recognizing disclosable claims, I think this issue should remain closed.