# Interoperable use of JSON for `did:web` DIDs

As currently specified, the [did:web method](https://w3c-ccg.github.io/did-method-web/) hardcodes a `.json` extension for DID document retrieval, be it from the `.well-known` default or for specific users. It simultaneously expects that document to be a JSON-LD document (see step 3 under [Create](https://w3c-ccg.github.io/did-method-web/#create-register)).

At the same time, the [DID Implementation Guide](https://www.w3.org/TR/did-imp-guide/) has a [whole multipage section](https://www.w3.org/TR/did-imp-guide/#drawbacks) cautioning against the risks involved in mixing up JSON and JSON-LD, and not using the prescribed media types being `application/did+json` and `application/did+ld+json`.

This is cause for some consternation.

If there is one thing that the past 30 years of standards have taught us, it's that, particularly in a heavily distributed context with many actors and no central enforcement, you get *a lot* more interoperability by creating standards that match how people use technology rather than trying to shoehorn people into some narrow pet peeve about correctness. There's a lot more of them than there are of you, and implementers care more about making their users happy than standard wonks.

The truth of the matter is that the vast majority of `did:web` documents are, because their URLs end in `.json`, going to be served as `application/json`. In fact it's very likely that DID documents in general (at least those that use a JSON syntax), being produced and served using JSON tools, are going to end up serving their documents as `application/json` no matter what. And the second that this is common, processors will just accept it.

Now, in a perfect world people would stop making up media types like `application/did+ld+json` that won't gain traction, but this isn't a perfect world and the Implementation Guide's warning about attacks based on differing semantics between JSON and JSON-LD are real. This kind of attack is *exactly* what you get from using media types in this way and is the primary reason why authoritative metadata must die a fiery death.

Here's the fix: we need to define how DID processors process `application/json` documents. This is done as follows:

1. If there is an `@context` key at the root of the document, process it according to the JSON-LD rules. If you aren't able to do so, then reject the document.
2. Otherwise, process the document according to the JSON rules. If you aren't able to do so, then reject the document.

That's it. The benefits are that:

* This is a lot more robust and is safe against authoritative metadata antipatterns.
* It matches likely real-world usage.
* It makes it possible to completely ignore `application/did+json` and `application/did+ld+json`.