Remove text on context validation and refer to DI instead.

Author: msporny

index.html

@@ -4843,115 +4843,6 @@ <h3>Verification</h3>
 
       </section>
 
-      <section class="normative">
-        <h3>Context Validation</h3>
-
-        <p>
-This section contains an algorithm that [=verifiers=] MUST run after running the
-algorithm in Section [[[#verification]]], when validating a [=verifiable
-credential=] or a [=verifiable presentation=]. This algorithm takes a document
-([=map=] |inputDocument|) and a set of approved JSON-LD Contexts ([=map=]
-|approvedContexts|) and returns a [=map=] that contains the following:
-        </p>
-
-        <ul>
-          <li>
-a status ([=boolean=] |status|)
-          </li>
-          <li>
-a [=conforming document=] ([=map=] |document|)
-          </li>
-          <li>
-zero or more warnings ([=list=] of [=ProblemDetails=] |warnings|)
-          </li>
-          <li>
-zero or more errors ([=list=] of [=ProblemDetails=] |errors|)
-          </li>
-        </ul>
-
-        <p>
-The context validation algorithm is as follows:
-        </p>
-
-        <ol class="algorithm">
-          <li>
-Set |result|.|status| to `false`.
-          </li>
-          <li>
-For each |contextValue| expressed in every `@context` property, ensure that
-either:
-            <ol class="algorithm">
-              <li>
-The |contextValue| exists in |approvedContexts| and matches an exact value
-or a cryptographic hash associated with the matching approved context, or
-              </li>
-              <li>
-optionally, if any of the context values do not exist in |approvedContexts|,
-clone the `@context` property and remove each context value that was
-not in |approvedContext| from the clone. Set |result|.|document| to
-the result of running the <a data-cite="JSON-LD11-API#compaction-algorithm">
-JSON-LD Compaction Algorithm</a> with the |inputDocument| and
-the cloned and modified context as inputs.
-              </li>
-            </ol>
-          </li>
-          <li>
-If no errors occurred in the previous step, set |result|.|status| to `true` and,
-if |result|.|document| is not set, set it to |inputDocument|. If errors
-occurred, set |result|.|status| to `false`, remove the |document| property from
-|result|, and add at least one
-<a href="#MALFORMED_VALUE_ERROR">MALFORMED_VALUE_ERROR</a> to |result|.|errors|.
-          </li>
-          <li>
-Return the value of |result|.
-          </li>
-        </ol>
-
-        <p>
-The purpose of the algorithm above is to ensure that the [=verifier=] has
-explicitly approved of the types of [=verifiable credentials=] and [=verifiable
-presentations=] that it will process. Not checking these JSON-LD Context values
-against known good values, and the semantics that they convey, can lead to
-security vulnerabilities. While the algorithm above provides one way of checking
-these values, and one optional way of safely processing unknown values,
-implementers MAY use alternative approaches, or a different ordering of the
-steps, that provide the same protections.
-        </p>
-
-        <p>
-One such approach would be for a [=verifier=] to configure a JSON-LD Context
-loader, sometimes referred to as a document loader, to use only local copies of
-approved context files which would guarantee that 1) context files will never
-change, and 2) the cryptographic hashes will never change, effectively
-resulting in the same result as the algorithm above.
-        </p>
-
-        <p>
-Another approach a [=verifier=] could use would be to use a list of well known
-context URLs and their associated approved cryptographic hashes, without storing
-every context file locally, which would allow contexts to be safely loaded and
-cached from the network without compromising the security expectations of the
-[=verifier=]. This approach would also be effectively equivalent to the
-algorithm provided in this section.
-        </p>
-
-        <p>
-Yet another valid approach would be for the [=holder=] to
-<a data-cite="JSON-LD11-API#compaction-algorithm">compact</a> a [=verifiable
-credential=] or [=verifiable presentations=] to exactly what a [=verifier=]
-requests, omitting additional issuer-specific context values that an [=issuer=]
-used when issuing the original document. As long as the securing mechanism's
-verification algorithm provides a successful verification result, such
-transformations are valid and would result in full URLs for terms that were
-previously compacted by the omitted context. That is, a term that was
-previously compacted to `foo` based on an issuer-supplied context that is
-unknown to a [=verifier=] would instead be "compacted" to something like
-`https://vocabulary.example#foo` once the unknown context is omitted and the
-compaction algorithm is applied by the [=verifier=].
-        </p>
-
-      </section>
-
       <section>
         <h3>Problem Details</h3>