diff --git a/index.html b/index.html
index ca7271b45..4274a8071 100644
--- a/index.html
+++ b/index.html
@@ -2230,7 +2230,7 @@ <h3>Data Schemas</h3>
             </p>
             <p>
 If multiple schemas are present, validity is determined according to the
-processing rules outlined by each associated <code>credentialSchema</code> 
+processing rules outlined by each associated <code>credentialSchema</code>
 <code>type</code> property.
             </p>
           </dd>
@@ -3625,6 +3625,82 @@ <h3>Reserved Extension Points</h3>
         </p>
 
       </section>
+
+      <section class="normative">
+        <h3>Ecosystem Compatibility</h3>
+
+        <p>
+There are a number of digital credential formats that do not natively use the
+data model provided in this document, but are aligned with a number of concepts
+in this specification. At the time of publication, examples of these digital
+credential formats include
+<a href="https://www.rfc-editor.org/rfc/rfc7519.html">
+JSON Web Tokens</a> (JWTs),
+<a href="https://www.rfc-editor.org/rfc/rfc8392.html">
+CBOR Web Tokens</a> (CWTs),
+<a href="https://www.iso.org/standard/69084.html">ISO-18013-5:2021</a>
+(mDLs),
+<a href="https://hyperledger.github.io/anoncreds-spec/">
+AnonCreds</a>,
+<a href="https://www.ietf.org/archive/id/draft-mcnally-envelope-02.html">
+Gordian Envelopes</a>, and
+<a href="https://www.ietf.org/archive/id/draft-ssmith-acdc-02.html">
+Authentic Chained Data Containers</a> (ACDCs).
+        </p>
+
+        <p>
+If conceptually aligned digital credential formats can be transformed into a
+<a>conforming document</a> according to the rules provided in this section, they
+are considered <em>"compatible with the W3C Verifiable Credentials ecosystem"</em>.
+A <a>conforming document</a> is either a <a>verifiable credential</a> serialized
+as the `application/vc+ld+json` media type or a <a>verifiable presentation</a>
+serialized as the `application/vp+ld+json` media type. Specifications that
+describe how to perform transformations that enable compatibility with
+the Verifiable Credentials ecosystem:
+        </p>
+
+        <ul>
+          <li>
+MUST identify whether the transformation to this data model is one-way-only or
+round-trippable.
+          </li>
+          <li>
+MUST preserve the `@context` values when performing round-trippable
+transformation.
+          </li>
+          <li>
+MUST result in a <a>conforming document</a> when transforming to the data
+model described by this specification.
+          </li>
+          <li>
+MUST specify a registered media type for the input document.
+          </li>
+          <li>
+SHOULD provide a test suite that demonstrates that the specified transformation
+algorithm to the data model in this specification results in
+a <a>conforming document</a>.
+          </li>
+          <li>
+SHOULD ensure that all semantics utilized in the transformed
+<a>conforming document</a> follow best practices for Linked Data. See
+Section <a href="#getting-started"></a>, Section
+<a href="#extensibility"></a>, and Linked Data Best Practices [[?LD-BP]]
+for additional guidance.
+          </li>
+        </ul>
+
+        <p class="note" title="What constitutes a verifiable credential?">
+Readers are advised that a digital credential is only considered
+compatible with the W3C Verifiable Credentials ecosystem if it is a
+<a>conforming document</a> and it utilizes at least one securing mechanism, as
+described by their respective requirements in this specification. While some communities might call some digital
+credential formats that are not <a>conforming documents</a>
+"verifiable credentials", doing so does NOT make that digital credential
+compliant to this specification.
+        </p>
+
+      </section>
+
     </section>
 
     <section>