diff --git a/index.html b/index.html
index 3b2ff25..b29ed42 100644
--- a/index.html
+++ b/index.html
@@ -565,11 +565,46 @@ <h3>Authorization</h3>
 require conforming <a>VC API clients</a> to utilize secure authorization
 technologies when performing certain types of requests. Each HTTP endpoint
 defined in this document specifies whether or not authorization is required
-when performing a request.
+when performing a request. With the exception of the class of forbidden 
+authorization protocols discussed later in this section, the VC API is authorization 
+mechanism agnostic.
       </p>
       <p>
-This section details the authorization technologies that have been contemplated
-for use by conforming implementations. Other equivalent authorization
+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.
+      </p>
+      <p>
+The rest of this section gives examples of the authorization technologies that have 
+been contemplated for use by conforming implementations. Other equivalent authorization
 technologies can be used. Implementers are cautioned against using non-standard
 or legacy authorization technologies.
       </p>