Add change notification expectations to Security Considerations.

index.html

@@ -2965,18 +2965,26 @@ <h2>Notification of DID Document Changes</h2>
 addresses on file.
       </p>
       <p>
-In the case of a [=DID=], there is no intermediary registrar or account
-provider to generate such notifications. However, if the [=verifiable data
-registry=] on which the [=DID=] is registered directly supports change
-notifications, a subscription service can be offered to [=DID controllers=].
-Notifications could be sent directly to the relevant [=service endpoints=]
-listed in an existing [=DID=].
+In the case of a [=DID=], there is no intermediary registrar or account provider
+to generate such notifications. However, if the [=verifiable data registry=] on
+which the [=DID=] is registered directly supports change notifications, or a
+monitoring service is used, a subscription service can be offered to [=DID
+controllers=]. Notifications could be sent directly to the relevant [=service
+endpoints=] listed in an existing [=DID document=].
       </p>
       <p>
 If a [=DID controller=] chooses to rely on a third-party monitoring service
 (other than the [=verifiable data registry=] itself), this introduces another
 vector of attack.
       </p>
+      <p>
+Any sort of change notification service is expected to be hardened against
+spoofing, denial of service, linkability, and other attacks on security or
+privacy. Mitigations such as integrity-protecting change notification messages
+and their sources, binding notifications to previous cryptographic hashes of the
+[=DID document=], and enforcement of rate limits are expected to be documented
+and be a core part of change notification service specifications.
+      </p>
     </section>
 
     <section>