From bf48d01f41122934c402df4719c2e3674eb53276 Mon Sep 17 00:00:00 2001
From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 6 Jan 2024 12:13:04 -0500
Subject: [PATCH] Reflow securing spec section.

---
 index.html | 89 +++++++++++++++++-------------------------------------
 1 file changed, 27 insertions(+), 62 deletions(-)

diff --git a/index.html b/index.html
index 3b9464d0b..2f7fa0537 100644
--- a/index.html
+++ b/index.html
@@ -3984,6 +3984,17 @@ <h3>Securing Mechanism Specifications</h3>
           </dd>
         </dl>
 
+        <p class="issue atrisk"
+           title="Controller document reference might change">
+The Working Group is currently attempting to align the definitions of a
+controller document between [[[?DID-CORE]]], [[[?VC-DATA-INTEGRITY]]], and
+[[[?VC-JOSE-COSE]]]. The goal is to have one specification that each of the
+previously stated specifications, and this specification, can reference for
+the normative statements related to controller documents. The normative
+references to controller documents are expected to change during the
+Candidate Recommendation phase.
+        </p>
+
         <p>
 Securing mechanism specifications SHOULD provide integrity protection for any
 information referenced by a URL that is critical to validation. Mechanisms that
@@ -3992,26 +4003,6 @@ <h3>Securing Mechanism Specifications</h3>
 <a href="#base-context"></a>.
         </p>
 
-        <p>
-Securing mechanism specifications SHOULD register the securing mechanism in the
-<a data-cite="?VC-SPECS#securing-mechanisms">Securing Mechanisms</a> section
-of the [[[?VC-SPECS]]] [[?VC-SPECS]].
-        </p>
-
-        <p class="note"
-           title="Choice of securing mechanism is use-case dependent">
-There are multiple acceptable securing mechanisms, and this specification does
-not mandate any particular securing mechanism for use with
-[=verifiable credentials=] or [=verifiable presentations=].
-The Working Group that produced this specification did standardize two
-securing mechanism options, which are:
-[[[VC-DATA-INTEGRITY]]] [[VC-DATA-INTEGRITY]] and [[[VC-JOSE-COSE]]]
-[[VC-JOSE-COSE]]. Other securing mechanisms that are known to the community
-can be found in the
-<a data-cite="?VC-SPECS#securing-mechanisms">Securing Mechanisms</a> section
-of the [[[?VC-SPECS]]] [[?VC-SPECS]].
-        </p>
-
         <p>
 Securing mechanism specifications that create new types of [=embedded proofs=]
 MUST specify a [=property=] for securing both [=verifiable credentials=] and
@@ -4044,50 +4035,24 @@ <h3>Securing Mechanism Specifications</h3>
           </li>
         </ul>
 
-        <p class="issue atrisk"
-           title="Controller document reference might change">
-The Working Group is currently attempting to align the definitions of a
-controller document between [[[?DID-CORE]]], [[[VC-DATA-INTEGRITY]]], and
-[[[VC-JOSE-COSE]]]. The goal is to have one specification that each of the
-previously stated specifications, and this specification, can reference for
-the normative statements related to controller documents. The normative
-references to controller documents are expected to change during the
-Candidate Recommendation phase.
+        <p>
+Securing mechanism specifications SHOULD register the securing mechanism in the
+<a data-cite="?VC-SPECS#securing-mechanisms">Securing Mechanisms</a> section
+of the [[[?VC-SPECS]]] [[?VC-SPECS]].
         </p>
 
-        <ul>
-          <li>
-The property MUST relate the [=verifiable credential=] or [=verifiable
-presentation=] to a separable and securable [=proof graph=].
-          </li>
-          <li>
-The property MUST define all terms used by the [=proof graph=]. For example,
-the mechanism could define vocabulary specifications and `@context` files
-in the same manner as they are utilized by this specification.
-          </li>
-          <li>
-In the case of a [=verifiable credential=], the property MUST secure the
-[=default graph=].
-          </li>
-          <li>
-In the case of a [=verifiable presentation=], the property MUST secure the
-[=default graph=] of the [=presentation=] as well as every [=proof graph=]
-related to each [=verifiable credential=].
-          </li>
-          <li>
-The property MAY reuse the `proof` property as defined in [[VC-DATA-INTEGRITY]].
-          </li>
-        </ul>
-
-        <p class="issue atrisk"
-           title="Controller document reference might change">
-The Working Group is currently attempting to align the definitions of a
-controller document between [[[?DID-CORE]]], [[[VC-DATA-INTEGRITY]]], and
-[[[VC-JOSE-COSE]]]. The goal is to have one specification that each of the
-previously stated specifications, and this specification, can reference for
-the normative statements related to controller documents. The normative
-references to controller documents are expected to change during the
-Candidate Recommendation phase.
+        <p class="note"
+           title="Choice of securing mechanism is use-case dependent">
+There are multiple acceptable securing mechanisms, and this specification does
+not mandate any particular securing mechanism for use with
+[=verifiable credentials=] or [=verifiable presentations=].
+The Working Group that produced this specification did standardize two
+securing mechanism options, which are:
+[[[VC-DATA-INTEGRITY]]] [[VC-DATA-INTEGRITY]] and [[[VC-JOSE-COSE]]]
+[[VC-JOSE-COSE]]. Other securing mechanisms that are known to the community
+can be found in the
+<a data-cite="?VC-SPECS#securing-mechanisms">Securing Mechanisms</a> section
+of the [[[?VC-SPECS]]] [[?VC-SPECS]].
         </p>
 
       </section>