Apply editorial suggestions to added text.

Co-authored-by: Ted Thibodeau Jr <[email protected]>

index.html

@@ -570,38 +570,40 @@ <h3>Authorization</h3>
 mechanism agnostic.
       </p>
       <p>
-The VC API is meant to be a generic API that can be useful in many 
-scenarios that require the issuance, possession, presentation, and/or 
-verification of Verifiable Credentials. As such there are the following 
-classifications of use cases that the implementer should consider.
-      </p>
-      <p>
-<i>Public</i>. A Public API is one that can be called with no authorization. 
-Examples include an open witness or timestamp service (a trusted service that 
-can digitally sign a message with a timestamp for an audit trail purpose), or 
-an open retail coupon endpoint ("15% off cheeseburgers"). Public verifiers 
-may exist as well, acting as a agnostic third party to a trust scenario.
-      </p>
-      <p>
-<i>Permissioned</i>. Permissionsed authorization requires the entity making 
-the API call to have an access control token issued from a mutually trusted 
-source. These permissions grant access to the API but make no assumptions 
-about credential subjects, previous interactions, or the like. Permissioned 
-access is particularly useful in service-to-service based workflows, where 
-credential subjects are not directly involved. 
-      </p>
-      <p>
-<i>Bound</i>. Bound authorization involves scenarios where the API calls are 
-tightly coupled, linked, or bound to another out-of-band process that has 
-authenticated the holder/subject to the API interaction. These use cases include 
-but are not limited to, for example, issuance of subject specific identity claims 
-directly to the subject in question, or verification of credentials to qualify the 
-holder for service at the verifier. Examples of methods to bind activity on one 
-channel to a VC API call include CHAPI, OpenID Connect, and Grant Negotiation 
-Authorization protocol. Developers implementing bound authorization will need to take 
-steps to ensure the appropriate level of assurance is achieved in the flow to properly 
-protect the binding.
+The VC API is meant to be generic and useful in many scenarios that require
+the issuance, possession, presentation, and/or verification of Verifiable
+Credentials. To this end, implementers should consider the following
+classifications of use cases:
       </p>
+      <ul>
+        <li>
+<i>Public</i>. A Public API is one that can be called with no authorization.
+Examples include an open witness or timestamp service (a trusted service that
+can digitally sign a message with a timestamp for an audit trail purpose), or
+an open retail coupon endpoint ("15% off cheeseburgers"). Public verifiers
+may exist as well, to act as an agnostic third party in a trust scenario.
+      </li>
+      <li>
+<i>Permissioned</i>. Permissioned authorization requires the entity making
+the API call to have an access control token issued from a mutually trusted
+source. These permissions grant access to the API, but make no assumptions
+about credential subjects, previous interactions, or the like. Permissioned
+access is particularly useful in service-to-service based workflows, where
+credential subjects are not directly involved.
+      </li>
+      <li>
+<i>Bound</i>. Bound authorization involves scenarios where the API calls are
+tightly coupled, linked, or bound to another out-of-band process that has
+authenticated the holder/subject to the API interaction. These use cases include,
+but are not limited to, issuance of subject-specific identity claims directly to
+the subject in question, or verification of credentials to qualify the holder for
+service at the verifier, for example. Examples of methods to bind activity on one
+channel to a VC API call include CHAPI, OpenID Connect, and the Grant Negotiation
+Authorization protocol. Developers implementing bound authorization will need to
+take steps to ensure the appropriate level of assurance is achieved in the flow
+to properly protect the binding.
+        </li>
+      </ul>
       <p>
 The rest of this section gives examples of the authorization technologies that have 
 been contemplated for use by conforming implementations. Other equivalent authorization