SEP-0010: Add back home domain verification with clarity (v3.0.0) (#746)

### What
Add back the home domain verification, but with greater clarity about exactly what the home domain is.

### Why
In v2.1.0 the home domain verification that was added in v2.0.0 was removed because the exact contents of the home domain field could be interpreted in at least two different ways that led to inconsistent implementations. The home domain is still present in the SEP-10 challenge transaction and this change provides clarity to what it should contain and how clients should verify it. This change represents the intended understanding of the home domain field. See v2.0.0 and v2.1.0 for prior context.

### Notes
Servers should use this change to verify that they are placing the correct value for the home domain into the challenge transaction. Once clients implement v3.0.0 they will reject challenge transactions from servers who are providing home domain values that are incorrect.

Co-authored-by: Sergey Nebolsin <nebolsin@gmail.com>
Co-authored-by: Jake Urban <jake@stellar.org>
Co-authored-by: Alex Cordeiro <accordeiro@users.noreply.github.com>

ecosystem/sep-0010.md

@@ -6,8 +6,8 @@ Title: Stellar Web Authentication
 Author: Sergey Nebolsin <@nebolsin>, Tom Quisel <tom.quisel@gmail.com>, Leigh McCulloch <@leighmcculloch>, Jake Urban <jake@stellar.org>
 Status: Active
 Created: 2018-07-31
-Updated: 2020-10-23
-Version 2.1.1
+Updated: 2020-11-06
+Version 3.0.0
 ```
 
 ## Simple Summary
@@ -18,12 +18,24 @@ This SEP defines the standard way for clients such as wallets or exchanges to cr
 
 This protocol is a variation of mutual challenge-response, which uses Stellar transactions to encode challenges and responses.
 
-The authentication flow is as follows:
+It involves three components:
+- A domain hosting a [SEP-1 stellar.toml](sep-0001.md) containing a `WEB_AUTH_ENDPOINT` and `SIGNING_KEY`, referred to as the home domain.
+- An endpoint providing the GET and POST operations discussed in this document.
+- A client who will authenticate using a Stellar account.
+
+The discovery flow is as follows:
+
+1. The client retrieves the `stellar.toml` from the home domain in accordance with [SEP-1 stellar.toml](sep-0001.md).
+1. The client looks up the `WEB_AUTH_ENDPOINT` and `SIGNING_KEY` from the `stellar.toml`.
 
-1. The client obtains a unique [`challenge`](#challenge), which is represented as specially formed Stellar transaction
+The authentication flow is as follows:
+1. The client obtains a unique [`challenge`](#challenge) from the `WEB_AUTH_ENDPOINT`, which is represented as specially formed Stellar transaction
 1. The client verifies that the transaction has an invalid sequence number 0.  This is extremely important to ensure the transaction isn't malicious.
-1. The client verifies that the transaction is signed by the `SIGNING_KEY` specified by the requested service's [SEP-1 stellar.toml](sep-0001.md).
-1. The client verifies that the transaction's first operation is a Manage Data operation that has its source account set to the user's account and value set to a nonce value. The client ignores the home domain included.
+1. The client verifies that the transaction is signed by the `SIGNING_KEY` obtained through discovery flow.
+1. The client verifies that the transaction's first operation is a Manage Data operation that has its:
+   1. Source account set to the user's account.
+   1. Key set to `<home domain> auth` where the home domain is the home domain from the discovery flow.
+   1. Value set to a nonce value.
 1. The client verifies that if the transaction has other operations they are Manage Data operations that all have their source accounts set to the the server's account.
 1. The client signs the transaction using the secret key(s) of signers for the user's Stellar account
 1. The client submits the signed challenge back to the server using [`token`](#token) endpoint
@@ -69,7 +81,8 @@ In order for browsers-based wallets to validate the CORS headers, as [specified
 
 ### Challenge
 
-This endpoint must respond with a Stellar transaction signed by the server that has an invalid sequence number (0) and thus cannot be executed on the Stellar network. The client can then sign the transaction using standard Stellar libraries and submit it to [`token`](#token) endpoint to prove that they control their account. This approach is compatible with hardware wallets such as Ledger. The client must also verify the server's signature to be sure the challenge is signed by the `SIGNING_KEY` from the server's [`stellar.toml`](sep-0001.md).
+This endpoint must respond with a Stellar transaction signed by the server that has an invalid sequence number (0) and thus cannot be executed on the Stellar network. The client can then sign the transaction using standard Stellar libraries and submit it to [`token`](#token) endpoint to prove that they control their account. This approach is compatible with hardware wallets such as Ledger. The client must also verify the server's signature to be sure the challenge is signed by the `SIGNING_KEY`, and the home domain in the challenge is the home domain from the discovery flow.
+
 
 #### Request
 
@@ -82,7 +95,7 @@ Request Parameters:
 Name      | Type          | Description
 ----------|---------------|------------
 `account` | `G...` string | The stellar account that the wallet wishes to authenticate with the server
-`home_domain` | string | (optional) The [fully qualified domain name](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) of the service requiring authentication. SEP-10 signing servers used to generate tokens for multiple different web services can use this parameter to create valid tokens for each service. If not provided by the client, a default should be used.
+`home_domain` | string | (optional) The home domain the client would like to authenticate. Servers that generate tokens for multiple home domains can use this parameter to identify which home domain the client hopes to authenticate. If not provided by the client, the server should assume a default for backwards compatibility with older clients.
 
 Example:
 
@@ -100,7 +113,7 @@ On success the endpoint must return `200 OK` HTTP status code and a JSON object
   * time bounds: `{min: now(), max: now() + 900 }` (we recommend expiration of 15 minutes to give user time to sign transaction)
   * operations:
     * `manage_data(source: client_account, key: '<home domain> auth', value: random_nonce())`
-      * The value of key is the fully qualified domain name of the web service requiring authentication followed by `auth`. It can be at most 64 characters.
+      * The value of key is the home domain the challenge is authenticating, followed by `auth`. It can be at most 64 characters.
       * The value must be 64 bytes long. It contains a 48 byte cryptographic-quality random string encoded using base64 (for a total of 64 bytes after encoding).
     * zero or more `manage_data(source: server_account, ...)` reserved for future use
   * signature by the service's stellar.toml `SIGNING_KEY`
@@ -140,6 +153,7 @@ To validate the challenge transaction the following steps are performed by the s
 * verify that transaction has time bounds set, and that current time is between the minimum and maximum bounds;
 * verify that transaction contains a single [Manage Data](https://www.stellar.org/developers/guides/concepts/list-of-operations.html#manage-data) operation that:
   * has a non-null source account
+  * has the home domain as the key of the operation
 * verify that transaction envelope has a correct signature by server's signing key;
 * if the operation's source account exists:
   * verify that client signatures count is one or more;