JSON vs JSON-LD cross-compatibility guidance for implementers

[travisleithead]

This is part of the feedback from Microsoft's ballot response to the DID Core spec transition to REC AC review. As it pertains to future work on that spec, @iherman encouraged me to file it here for consideration in the charter process (as applicable). See also w3c/did-core#836, w3c/did-wg-charter#13.

Microsoft recommends additional non-normative guidance on cross-compatibility between the JSON and JSON-LD representations in Section 6. We further recommend that implementers use the simpler JSON representation, to enhance interoperability and avoid complications and incompatibilities arising from JSON-LD processing.

[peacekeeper]

+1 to adding additional guidance on compatibility between the JSON and JSON-LD (and other) representations. The WG has spent a lot of time on this topic, without really coming to a shared understanding that everybody agrees to. Therefore, I believe it would be valuable to revisit this topic after some time (once there is more implementation experience).

-1 to explicitly recommending one representation over another, but +1 to pointing out pros and cons of specific representations.

[iherman]

The issue was discussed in a meeting on 2021-08-31

• no resolutions were taken

View the transcript

### 6. Next DID WG Charter _See github issue [did-wg-charter#11](https://github.com/w3c/did-core/issues/836), [did-wg-charter#12](https://github.com/w3c/did-imp-guide/issues/42), [did-wg-charter#13](https://github.com/w3c/did-wg-charter/issues/13)._ > *Brent Zundel:* [https://github.com/w3c/did-wg-charter/issues](https://github.com/w3c/did-wg-charter/issues) **Brent Zundel:** the reason this is a longer topic is due to issues that have been raised that we should discuss … the goal is to go through them briefly, then I encourage WG members to respond in the issues … the first issue is "one foundational key representation please" from Microsoft. … this has received extensive discussion in the WG already **Drummond Reed:** folks are still encouraged to reply in the issue, especially with citations to our earlier discussions of those topics. **Brent Zundel:** Microsoft is recommending non-normative guidance on cross-compatibility between JSON and JSON-LD … this sort of non-normative guidance would, in Brent's opinion, be in scope under the new charter … but would also retrod well-trodden ground … Microsoft would also like the WG to take the challenge to define a universal, mandatory-to-implement DID method … this would take the WG out of maintenance mode **Joe Andrieu:** There was a proposal to include `did:web` and `did:key` in the charter, but that was not done in order to keep it a maintenance WG … so this could be a chance to do that **Kyle Den Hartog:** `did:key` could work, but worried that `did:web` would derail the conversation … and not sure what would be the third **Brent Zundel:** The question of what DID methods could reach consensus would be challenging … `did:peer` might also be a candidate that could reach consensus **Ted Thibodeau Jr.:** Going through the exercise of determining which DID methods could become normative could be a work item for the W3C Credentials Community Group … but the DID Rubric might be a better tool for evaluating this **Drummond Reed:** likes the idea of looking at the DID Rubric and taking an evolutionary path

[msporny]

We further recommend that implementers use the simpler JSON representation, to enhance interoperability and avoid complications and incompatibilities arising from JSON-LD processing.

-1, this was heavily debated during while creating DID Core -- to not pick favorite syntaxes, implementers are welcome to use what they feel is appropriate. +1 to language and tooling that helps implementers ensure that their implementations work correctly across all serializations. The solution here is to build validation tooling for DID Document implementers, not to favor one syntax over another.

[brentzundel]

The current scope of the draft charter supports making such updates to the DID Implementation Guide. Since this issue is pertinent to that note, I am transferring this issue to that repository.