SEP-24: Signature only for URL callbacks

The callback signature discussed here does not apply to postMessage type callbacks

ecosystem/sep-0024.md

@@ -6,7 +6,7 @@ Title: Hosted Deposit and Withdrawal
 Author: SDF
 Status: Active
 Created: 2019-09-18
-Updated: 2022-07-11
+Updated: 2022-08-19
 Version 2.6.0
 ```
 
@@ -87,10 +87,12 @@ In order for browsers-based wallets to validate the CORS headers, as [specified
 
 This protocol involves the transfer of value, and so HTTPS is required for all endpoints for security.  Wallets and anchors should refuse to interact with any insecure HTTP endpoints.
 
-## Callback signature
+## URL Callback signature
 
-This protocol involves the optional use of callbacks that the Anchor can issue to update the wallet on ```status``` of a transaction.
-In order to validate the integrity and provenance of the callback, the Anchor MUST include a signature in an additional HTTP Header `X-Stellar-Signature`.
+_Note that the signature discussed here is only for **URL callbacks** and does not apply to **`postMessage` callbacks**_
+
+This protocol involves the optional use of URL callbacks that the Anchor can issue to update the wallet on ```status``` of a transaction.
+In order to validate the integrity and provenance of the callback, the Anchor MUST include a signature in an additional HTTP Header `X-Stellar-Signature`. 
 This Header MUST follow the specification: `X-Stellar-Signature: t=<timestamp>, s=<base64 signature>` where:
 * __timestamp__ is the current Unix timestamp (number of seconds since epoch) at the time the callback is sent. This is used to assure the freshness of the request and to prevent this request to be replayed in the future. 
 * __base64 signature__ is the base64 encoding of the request signature. We explain below how to compute and verify this signature. The signature is computed using the Stellar private key linked to the `SIGNING_KEY` field of the anchor's [`stellar.toml`](sep-0001.md). Note that the timestamp and the Wallet hostname will be part of the signature to prevent replay and relay attacks.
@@ -424,8 +426,8 @@ The basic parameters are summarized in the table below.
 
 Name | Type | Description
 -----|------|------------
-`callback` | string | (optional) [`postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) or a URL that the anchor should `POST` a JSON message to when the user successfully completes the interactive flow. The callback needs to be signed by the anchor and the signature needs to be verified by the wallet according to the [callback signature specification](#callback-signature).
-`on_change_callback` | string | (optional) [`postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) or a URL that the anchor should `POST` a JSON message to when the `status` or `kyc_verified` properties change. The callback needs to be signed by the anchor and the signature needs to be verified by the wallet according to the [callback signature specification](#callback-signature).
+`callback` | string | (optional) [`postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) or a URL that the anchor should `POST` a JSON message to when the user successfully completes the interactive flow. If the callback is a URL (not a `postMessage`), it needs to be signed by the anchor and the signature needs to be verified by the wallet according to the [callback signature specification](#callback-signature).
+`on_change_callback` | string | (optional) [`postMessage`](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) or a URL that the anchor should `POST` a JSON message to when the `status` or `kyc_verified` properties change. If the callback is a URL (not a `postMessage`), it needs to be signed by the anchor and the signature needs to be verified by the wallet according to the [callback signature specification](#callback-signature).
 
 The URL supplied by both callback parameters should receive the full transaction object.