Replace "client" with more appropriate terms

index.html

@@ -1682,7 +1682,7 @@ <h3>Key types and formats</h3>
 
         <p class="note">
 Caching and expiration of the keys in a <a>DID document</a> is entirely the
-responsibility of <a>DID resolvers</a> and other clients. For more information,
+responsibility of <a>DID resolvers</a> and requesting parties. For more information,
 see Section <a href="#resolution"></a>.
         </p>
 
@@ -2975,7 +2975,7 @@ <h3>
         </h3>
 
         <p>
-The <a>DID method</a> specification MUST specify how a client creates a
+The <a>DID method</a> specification MUST specify how a <a>DID controller</a> creates a
 <a>DID</a> and its associated <a>DID document</a> on the <a>verifiable data registry</a>,
 including all cryptographic operations necessary to establish proof of control.
         </p>
@@ -2987,9 +2987,9 @@ <h3>
         </h3>
 
         <p>
-The <a>DID method</a> specification MUST specify how a client uses a <a>DID</a>
+The <a>DID method</a> specification MUST specify how a <a>DID resolver</a> uses a <a>DID</a>
 to request a <a>DID document</a> from the <a>verifiable data registry</a>,
-including how the client can verify the authenticity of the response.
+including how the <a>DID resolver</a> can verify the authenticity of the response.
         </p>
       </section>
 
@@ -2999,7 +2999,7 @@ <h3>
         </h3>
 
         <p>
-The <a>DID method</a> specification MUST specify how a client can update a
+The <a>DID method</a> specification MUST specify how a <a>DID controller</a> can update a
 <a>DID document</a> on the <a>verifiable data registry</a>, including all cryptographic
 operations necessary to establish proof of control, <em>or</em> state that
 updates are not possible.
@@ -3021,7 +3021,7 @@ <h3>
         </h3>
 
         <p>
-The <a>DID method</a> specification MUST specify how a client can deactivate a
+The <a>DID method</a> specification MUST specify how a <a>DID controller</a> can deactivate a
 <a>DID</a> on the <a>verifiable data registry</a>, including all cryptographic
 operations necessary to establish proof of deactivation, <em>or</em> state that
 deactivation is not possible.
@@ -3699,7 +3699,7 @@ <h2>
       <p>
 In a <a>decentralized identifier</a> architecture, there are no centralized
 authorities to enforce key or signature expiration policies. Therefore
-<a>DID resolvers</a> and other client applications need to validate that keys
+<a>DID resolvers</a> and requesting parties need to validate that keys
 were not expired at the time they were used. Because some use cases might have
 legitimate reasons why already-expired keys can be extended, make sure a key
 expiration does not prevent any further use of the key, and implementations
@@ -3816,7 +3816,7 @@ <h2>
 particularly relevant because of caching. For <a>DID methods</a> tied to a
 global source of truth, a direct, just-in-time lookup of the latest version of a
 <a>DID document</a> is always possible. However, it seems likely that layers of
-cache might eventually sit between a client and that source of truth. If they
+cache might eventually sit between a <a>DID resolver</a> and that source of truth. If they
 do, believing the attributes of an object in the <a>DID document</a> to have a
 given state, when they are actually subtly different, might invite exploits.
 This is particularly true if some lookups are of a full <a>DID document</a>, and
@@ -3958,7 +3958,7 @@ <h2>
 that default to preserving anonymity and pseudonymity. To reduce
 <a href="https://en.wikipedia.org/wiki/Device_fingerprint">
   digital fingerprints</a>,
-share common settings across client implementations, keep negotiated options to
+share common settings across requesting party implementations, keep negotiated options to
 a minimum on wire protocols, use encrypted transport layers, and pad messages to
 standard lengths.
       </p>