`application/did+ld+json` should be revisited

This was discussed during the #did meeting on 19 September 2024.

View the transcript

w3c/did-core#863 application/did+ld+json should be revisited

manu: Strategy to discuss the big rocks first. Class 3, then 2 then 1
… 863 is about the media type. In did-core we said application/did+ld+json
… open question what the media type should be. Cannot have did+ld+json
… some implementors want to use json serialization others jsonld
… Looking at potentially 2 media types
… we could try application/did as the media type
… with the new controller document which supports context injection. We can parse as json if it doesnt have a json if it does have a @context you can parse as jsonld
… if you want to parse as jsonld but it doesn't have a context you can inject one

<ivan> Controller document context injection section

manu: Strongly suggesting we just do application/did to keep it simple
… Need to be clear we are not allowing two different processing models
… thoughts concerns about application/did

<bigbluehat> +1 to `application/did`

<dmitriz> my vote would be for application/did+json. To enable the eventual (and inevitable?) application/did+cbor

markus_sabadello: What does this mean for the abstract data model, if the controller document allows context injection

<Zakim> manu, you wanted to go into polyglot response if it becomes an issue.

manu: Still have the abstract data model. You would still be able to use JSON. Or you can use jsonld. Fundamentally these are interpretted the same. The meaning is the same

markus_sabadello: I want to do this. Seems like we don't need the different representations anymore.

dmitriz: In JSON vs JSONLD we loose track of other things like CBOR and YAML. My vote is for application/did+json
… implementations need to know how to parse the document

ivan: Understand dmitriz opinion. But, the VCWG has decided to use application/vc for verifiable credentials

<Zakim> manu, you wanted to note that we could have CBOR in the future. and to ask if it's "application/json", then what do we do for JSON-LD?

manu: Not closed the door on CBOR or YAML. Could have did+cbor or did+yaml. But what do we do about jsonld. We could say application/did is jsonld
… Or we would have to get a new suffix through the jsonld working group
… Markus, the reason we would have different representations is to support CBOR and YAML
… One more option, for JSONLD DID documents jsonld/we could use application/ld+json/jsonld

decentralgabe: encourage people to consider discussion on an issue

decentralgabe: time for one or two more

w3c / did-core

`application/did+ld+json` should be revisited #863

w3c/did-core#863 application/did+ld+json should be revisited