From 94ee832ed9075586527448ec418e42ce7996adb5 Mon Sep 17 00:00:00 2001
From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 17 Dec 2023 12:22:06 -0500
Subject: [PATCH] Remove duplicated normative statements in conformance
 section.

---
 index.html | 35 -----------------------------------
 1 file changed, 35 deletions(-)

diff --git a/index.html b/index.html
index a2c2ce8f7..a01d8a2b4 100644
--- a/index.html
+++ b/index.html
@@ -603,8 +603,6 @@ <h3>Use Cases and Requirements</h3>
 <a href="#securing-mechanisms"></a>.
         </p>
 
-        </p>
-
         <p>
 A <dfn class="lint-ignore">conforming issuer implementation</dfn> produces
 <a>conforming documents</a>, MUST include all required properties in the
@@ -628,39 +626,6 @@ <h3>Use Cases and Requirements</h3>
 <a>conforming verifier implementations</a>.
         </p>
 
-        <p>
-<a>Verifiable credentials</a> and <a>verifiable presentations</a> MUST be
-protected using a securing mechanism as described in Section
-<a href="#securing-mechanisms"></a>. Having and verifying proofs,
-which might be dependent on the syntax of the proof (for example, using the JSON
-Web Signature of a JSON Web Token for proofing a key holder), are an essential
-part of processing <a>verifiable credentials</a> and
-<a>verifiable presentations</a>. At the time of publication, Working Group
-members had implemented such protection using at least three proof mechanisms:
-        </p>
-
-        <ul>
-          <li>
-Securing Verifiable Credentials using JOSE and COSE [[VC-JOSE-COSE]].
-          </li>
-          <li>
-Securing Verifiable Credentials using Data Integrity Proofs [[VC-DATA-INTEGRITY]].
-          </li>
-        </ul>
-
-        <p>
-Implementers are advised to note that not all proof mechanisms are standardized
-as of the publication date of this specification. The group expects some of
-these mechanisms, as well as new ones, to mature independently and become
-standardized in time. Given there are multiple valid proof mechanisms, this
-specification does not standardize on any single digital signature mechanism.
-One of the goals of this specification is to provide a data model that can be
-protected by a variety of current and future digital proof mechanisms.
-Conformance to this specification does not depend on the details of a particular
-proof mechanism; it requires clearly identifying the mechanism used by
-each <a>verifiable credential</a> and <a>verifiable presentation</a>.
-        </p>
-
         <p>
 This document also contains examples that contain characters that are invalid
 JSON, such as inline comments (<code>//</code>) and the use of ellipsis