[Task] Implement JSON-LD output format for DID Documents

[JelleMillenaar]

Description

Implement JSON-LD output format for DID Documents. Previous iteration of this Issue held more DID Core updates, but they have either been tackled or have their own issues right now.

Resources

• JSON-LD

To-do list

Create a task-specific to-do list . Please link PRs that match the To-do list item behind the item after it has been submitted.

• [ ] Allow output of JSON-LD (Aka, just add the default context)

Change checklist

Add an x to the boxes that are relevant to your changes, and delete any items that are not.

• [ ] The feature or fix is implemented in Rust and across all bindings whereas possible.
• [ ] The feature or fix has sufficient testing coverage
• [ ] All tests and examples build and run locally as expected
• [ ] Every piece of code has been document according to the documentation guidelines.
• [ ] If conceptual documentation (mdbook) and examples highlighting the feature exist, they are properly updated.
• [ ] If the feature is not currently documented, a documentation task Issue has been opened to address this.

[m-renaud]

Just to make sure I understand:

1. Reading through the code it looks like the created and updated fields in did::Properties should be moved to a new DIDMetadata struct, correct?
2. Since currently the Properties are the the first generic parameter to the "core" Document type, we would likely need to introduce a new type param to Document to be generic over a specific "metadata", correct?

And one other question: Would we want unique "input metadata" and "output metadata" types? The new spec says "Input and output metadata is often involved during the DID Resolution"

[l1h3r]

1. Reading through the code it looks like the created and updated fields in did::Properties should be moved to a new DIDMetadata struct, correct?

Yes and there are already distinct types for this, just not really utilized - resolution is still awkward and easier if you use the Client directly and not the generic DID resolver (the difference is mostly just the input/output formats)

2. Since currently the Properties are the the first generic parameter to the "core" Document type, we would likely need to introduce a new type param to Document to be generic over a specific "metadata", correct?

The data structures stored on the Tangle are going to change soon(ish); this will make Properties redundant and provide much clearer separation between the Document and metadata.

we probably won't need to use generics