diff --git a/index.html b/index.html
index 201cde126..7b6eeeac0 100644
--- a/index.html
+++ b/index.html
@@ -3558,7 +3558,7 @@ <h3>Reserved Extension Points</h3>
             <tr>
               <td>`confidenceMethod`</td>
               <td>
-A property used for specifying one or more methods that a verifier 
+A property used for specifying one or more methods that a verifier
 might use to increase their confidence that the value of an attribute in or of
 a verifiable credential or verifiable presentation is accurate, including but not
 limited to attributes such as `initialRecipient` (a/k/a `issuee`), `presenter`,
@@ -3952,6 +3952,78 @@ <h3>Media Type Precision</h3>
           </p>
         </section>
 
+        <section class="informative">
+          <h2>JSON Processing</h2>
+
+          <p>
+While the media types describing conforming documents defined in this
+specification always express JSON-LD, JSON-LD processing is not required to be
+performed, since JSON-LD is JSON. Some scenarios where processing a
+<a>verifiable credential</a> or a <a>verifiable presentation</a> as JSON is
+desirable include, but are not limited to:
+          </p>
+
+          <ul>
+            <li>
+Before securing or after verifying content
+that requires <a href="https://csrc.nist.gov/glossary/term/data_integrity">data
+integrity</a>, such as a
+<a>verifiable credential</a> or <a>verifiable presentation</a>.
+            </li>
+            <li>
+When performing JSON Schema validation, as described in Section
+<a href="#data-schemas"></a>.
+            </li>
+            <li>
+When serializing or deserializing <a>verifiable credentials</a> or
+<a>verifiable presentations</a> into systems that store or index their contents.
+            </li>
+            <li>
+When operating on <a>verifiable credentials</a> or <a>verifiable
+presentations</a> in a software application, after verification or validation
+is performed for securing mechanisms that require an understanding of
+and/or processing of JSON-LD.
+            </li>
+            <li>
+When an application chooses to process the media type using the `+json`
+structured media type suffix.
+            </li>
+          </ul>
+
+          <p>
+That is, JSON processing is allowed as long as the document being consumed or
+produced is a <a>conforming document</a>. If JSON processing is desired, an
+implementer is advised to follow the following rule:
+          </p>
+
+          <ul>
+            <li>
+Ensure that all values associated with a `@context` property are in the
+expected order, the contents of the context files match known good
+cryptographic hashes for each file, and domain experts have deemed that the
+contents are appropriate for the intended use case.
+            </li>
+          </ul>
+
+          <p>
+Using static context files with a JSON Schema is one acceptable approach to
+implementing the rule above. This can ensure proper term identification,
+typing, and order, when a JSON document is processed as JSON-LD.
+          </p>
+
+          <p>
+The rule above guarantees semantic interoperability between JSON and JSON-LD for
+literal JSON keys mapped to URIs by the `@context` mechanism. While JSON-LD
+processors will use the specific mechanism provided and can verify that all
+terms are correctly specified, JSON-based processors implicitly accept the same
+semantics without performing any JSON-LD transformations, but instead by
+applying the above rules. In other words, the context in which the data exchange
+happens is explicitly stated for both JSON and JSON-LD by using the same
+mechanism. With respect to JSON-based processors, this is achieved in a
+lightweight manner, without having to use JSON-LD processing libraries.
+          </p>
+
+        </section>
       </section>
 
       <section>