From fc5e1964aab66c4c8983413d80ad0f23b941e662 Mon Sep 17 00:00:00 2001
From: Manu Sporny <msporny@digitalbazaar.com>
Date: Mon, 12 Jan 2026 11:49:22 -0500
Subject: [PATCH 1/3] Add change notification expectations to Security
 Considerations.

---
 index.html | 20 ++++++++++++++------
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/index.html b/index.html
index 2ec7cde6..4c6a46dc 100644
--- a/index.html
+++ b/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 to 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 rate limits are expected to be documented and be a core
+part of change notification service specifications.
+      </p>
     </section>
 
     <section>

From e58a09ed0320ad150709e325f310bd7247f2e434 Mon Sep 17 00:00:00 2001
From: Manu Sporny <msporny@digitalbazaar.com>
Date: Tue, 13 Jan 2026 10:29:30 -0500
Subject: [PATCH 2/3] Fix grammar in change notification section.

Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
---
 index.html | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/index.html b/index.html
index 4c6a46dc..7656e5dc 100644
--- a/index.html
+++ b/index.html
@@ -2979,11 +2979,11 @@ <h2>Notification of DID Document Changes</h2>
       </p>
       <p>
 Any sort of change notification service is expected to be hardened against
-spoofing, denial of service, linkability, and other attacks to security or
+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 rate limits are expected to be documented and be a core
-part of change notification service specifications.
+[=DID document=], and enforcement of rate limits are expected to be documented
+and be a core part of change notification service specifications.
       </p>
     </section>
 

From cb2a18986f2ef1e6d5cc58b7404a2076341f69e9 Mon Sep 17 00:00:00 2001
From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 21 Feb 2026 15:54:43 -0500
Subject: [PATCH 3/3] Remove Notification of DID Document Changes section.

---
 index.html | 37 -------------------------------------
 1 file changed, 37 deletions(-)

diff --git a/index.html b/index.html
index 7656e5dc..58bf5d33 100644
--- a/index.html
+++ b/index.html
@@ -2944,49 +2944,12 @@ <h2>Non-Repudiation</h2>
 [=DID resolution=] process.
         </li>
         <li>
-The subject is monitoring for unauthorized updates as elaborated upon in
-[[[#notification-of-did-document-changes]]].
-        </li>
-        <li>
 The subject has had adequate opportunity to revert malicious updates according
 to the authorization mechanism for the [=DID method=].
         </li>
       </ul>
     </section>
 
-    <section>
-      <h2>Notification of DID Document Changes</h2>
-
-      <p>
-One mitigation against unauthorized changes to a [=DID document=] is
-monitoring and actively notifying the [=DID subject=] when there are changes.
-This is analogous to helping prevent account takeover on conventional
-username/password accounts by sending password reset notifications to the email
-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, 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>
       <h3>Revocation in Trustless Systems</h3>