Abstract the dependencies on JSON for the core protocol

[tplooker]

Currently in several parts of the spec, explicit usage of JSON is defined, for example several definitions in the terminology section refer to JSON. Several locations in the spec also make use of JSON specific algorithms or structures, such as requiring public keys being in JWK format and or the canonicalisation algorithm applied when creating commitments uses JCS.

Future implementations of sidetree may want to leverage alternative data serialisation formats such as CBOR, Message Pack or Protocol Buffers hence creating this abstraction in the spec may be a useful

[OR13]

Here is a related issue: https://github.com/json-ld/json-ld.org/issues/463

The question remains: "what do you sign over"... for JOSE... thats JSON strings.... once we leave behind the requirement for JOSE, we can use COSE or sign over CBOR-LD / IPLD etc...

I would expect support for multiple representations to be one of the most important features of spec v2... however, i don't see how we won't end up with switch statements everywhere or breaking changes due to the reliance on JCS and JOSE.

[csuwildcat]

Are we still interested in this topic? Given the switch to canonicalized plain JSON, and the assumption of compression of files with gzip, I don't think we're going to get much benefit in terms of comparative file/op sizes. The question is then what we feel a change to CBOR would get us? What do you think?

[OR13]

I think Sidetree should position itself as a JSON based DID Method toolkit.... and not try and stretch to support a representation that has never been defined....

I also think Sidetree should restrict itself to JSON-LD only, since we don't support the "arbitrary properties" feature of the DID Core JSON representation.... and since the DID Core JSON only representation is not being developed with best security practices, and receives little contribution from community members.

One JSON representation that is both JSON and JSON-LD.... its the simplest solution to this problem.

Both Microsoft and Google return JSON-LD that is valid with content-type JSON... if Sidetree does something else, it will be a mistake.... and will make sidetree more complicated / vulnerable for 0 benefit.

Tl;DR; Sidetree should just use JSON internally, and should just produce JSON-LD externally, (which is JSON)...

[troyronda]

From WG discussion:

The Sidetree protocol relies on JOSE and is therefore JSON for internal protocol data structures.