Update DataNotification.md

docs/tutorial/DataNotification.md

@@ -24,7 +24,7 @@ A typical workflow using notification is:
 *  Consumer starts to receive notifications for that topic and processes the message to synchronize with the OSDU state.
 *  Consumer periodically rotates the "secret" used for subscription.
 
-The topics below describe these steps/APIs in detail that allow consumers to create such integrated workflows using DE Notification.
+The topics below describe these steps/APIs in detail that allow consumers to create such integrated workflows using OSDU Notification.
 
 [Back to Table of Contents](#TOC)
 
@@ -110,7 +110,7 @@ Below are the details of the two types of Subscriptions and the challenge proces
 
 </details>
 
-Before creating an HMAC Subscription, the consumer needs to make sure that "GET" is supported on the endpoint being registered with DE Notification and the endpoint accepts query parameters named "crc" & "hmac".  DE Notification will send a "GET" request on this endpoint with a random crc, and expects a response hash generated using the crc & the secret value (i.e. "testSecret" in the example above). 
+Before creating an HMAC Subscription, the consumer needs to make sure that "GET" is supported on the endpoint being registered with OSDU Notification and the endpoint accepts query parameters named "crc" & "hmac".  OSDU Notification will send a "GET" request on this endpoint with a random crc, and expects a response hash generated using the crc & the secret value (i.e. "testSecret" in the example above). 
 
 In addition, consumers may also want to validate the hmac field, which is the signature that will be used when a message is pushed to this endpoint. The signature verification must be used in the push endpoint implementation before processing the messages, to ensure that the message is coming from OSDU Notification.
 
@@ -297,7 +297,7 @@ private byte[] computeHmacSha256(final byte[] data, final byte[] key) throws Exc
 ```
 </details>
 
-Before creating a GSA Subscription, the consumer needs to make sure that "GET" is supported on the endpoint being registered with DE Notification and it accepts a query parameter named "crc".  DE Notification will send a "GET" request on this endpoint with a random crc, and expects a response hash generated using crc & the private_key_id field from the Service account used for subscription.
+Before creating a GSA Subscription, the consumer needs to make sure that "GET" is supported on the endpoint being registered with OSDU Notification and it accepts a query parameter named "crc".  OSDU Notification will send a "GET" request on this endpoint with a random crc, and expects a response hash generated using crc & the private_key_id field from the Service account used for subscription.
 
 In addition, consumers may also want to validate the google id token provided as "authorization" header, which will be generated using the audience & key provided. The google id token must be used in the push endpoint implementation before processing the messages, to ensure that the message is coming from OSDU Notification.
 
@@ -575,7 +575,7 @@ The notification service expects a response with the code in the 200-299 range f
 ## Update secret for a Subscription <a name="update-subscription"></a>
 Consumers might want to regularly update their secret for the Subscriptions to avoid security issues.
 
-This can be done using the DE Notification update subscription API. Consumers must update the "GET" endpoint first to point to new secret, as the same verification will be performed again with new secret value.
+This can be done using the OSDU Notification update subscription API. Consumers must update the "GET" endpoint first to point to new secret, as the same verification will be performed again with new secret value.
 
 The change in secret takes effect immediately.