From 1c40143460be343205b4e6658e7625df66618fef Mon Sep 17 00:00:00 2001 From: Jake Urban Date: Fri, 14 Aug 2020 10:07:39 -0700 Subject: [PATCH 1/7] make SIGNING_KEY required and change manage data op value --- ecosystem/sep-0010.md | 50 ++++++++++++++++++++++--------------------- 1 file changed, 26 insertions(+), 24 deletions(-) diff --git a/ecosystem/sep-0010.md b/ecosystem/sep-0010.md index d9052e40e..d66af5995 100644 --- a/ecosystem/sep-0010.md +++ b/ecosystem/sep-0010.md @@ -3,10 +3,10 @@ ``` SEP: 0010 Title: Stellar Web Authentication -Author: Sergey Nebolsin , Tom Quisel , Leigh McCulloch <@leighmcculloch> +Author: Sergey Nebolsin , Tom Quisel , Leigh McCulloch <@leighmcculloch>, Jake Urban Status: Active Created: 2018-07-31 -Updated: 2020-04-03 +Updated: 2020-08-14 Version 1.3.1 ``` @@ -22,19 +22,21 @@ The authentication flow is as follows: 1. The client obtains a unique [`challenge`](#challenge), 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 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 -1. The server checks that the user's account exists -1. If the user's account exists: +2. 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). +3. The client verifies that the transaction includes a Manage Data operation containing a `home_domain` key-value pair, and that the value contains the home domain used to request the challenge. +5. The client signs the transaction using the secret key(s) of signers for the user's Stellar account +6. The client submits the signed challenge back to the server using [`token`](#token) endpoint +7. The server checks that the user's account exists +8. If the user's account exists: 1. The server gets the signers of the user's account - 1. The server verifies the client signatures count is one or more; - 1. The server verifies the client signatures on the transaction are signers of the user's account; - 1. The server verifies the weight provided by the signers meets the required threshold(s), if any - 1. If the signatures check out, the server responds with a [JWT](https://jwt.io) that represents the user's session -1. If the user's account does not exist (optional): - 1. The server verifies the client signature count is one - 1. The server verifies the client signature is correct for the master key of the account -1. Any future calls to the server can be authenticated by including the JWT as a parameter + 2. The server verifies the client signatures count is one or more; + 3. The server verifies the client signatures on the transaction are signers of the user's account; + 4. The server verifies the weight provided by the signers meets the required threshold(s), if any + 5. If the signatures check out, the server responds with a [JWT](https://jwt.io) that represents the user's session +9. If the user's account does not exist (optional): + 6. The server verifies the client signature count is one + 7. The server verifies the client signature is correct for the master key of the account +10. Any future calls to the server can be authenticated by including the JWT as a parameter The flow achieves several things: @@ -66,7 +68,7 @@ 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 can 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` from the server's [`stellar.toml`](sep-0001.md). Additionally, the client must ensure that the challenge transaction was created by the requested service by checking the value of the Manage Data operation. #### Request @@ -94,21 +96,19 @@ On success the endpoint must return `200 OK` HTTP status code and a JSON object * source account set to server's signing account * invalid sequence number (set to 0) so the transaction cannot be run on the Stellar network * 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: ' auth', value: random_nonce())` - * The value of key is not important, but can be the name of the anchor followed by `auth`. It can be at most 64 bytes. - * 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). - * signature by the web service signing account + * operations: `manage_data(source: client_account, key: ' auth', value: '')` + * signature by the service's stellar.toml `SIGNING_KEY` * `network_passphrase`: (optional but recommended) Stellar network passphrase used by the server. This allows the client to verify that it's using the correct passphrase when signing and is useful for identifying when a client or server have been configured incorrectly. Example: ```json { - "transaction": "AAAAAGjeCRajN67nRkVtYO+lpxax9gvitX9FxhZYGXQvs16hAAAAZAAAAAAAAAAAAAAAAQAAAABbcutKAAAAAFty7HYAAAAAAAAAAQAAAAEAAAAAVIx5odtAgqQ+dp4m4QfWntHbOq0hxRCLGI+2Sm0P6EMAAAAKAAAAC01vYml1cyBhdXRoAAAAAAEAAABAG01TL/Ha0YGVrAF6t0UEKP/0Q/NDUymciQBA/CXzYMVlEx2KcHrq3MkpQ9+9sCbCiOYa7wCtusa1tHKygvZRSwAAAAAAAAABL7NeoQAAAEC9v5jdxReIxoCcCXw90dVsIpXwHXkSHUUthCs98D/zpd6TNPvcMgUsQd6cDHzjNk+/00P8M5bHP4rIpFTm7MwN", + "transaction": "AAAAAgAAAAC2c0axdmfUQ/Dq5fRRlvtybUBghi3vdOe3nHnMS6bxHgAAAGQAAAAAAAAAAAAAAAEAAAAAXza9AQAAAABfNhe8AAAAAAAAAAEAAAABAAAAAN1RWGc1gsEPHI/V0igO6YRsOYcwN8m/TuuGysVv4vz3AAAACgAAAAhTREYgYXV0aAAAAAEAAAAWdGVzdGFuY2hvci5zdGVsbGFyLm9yZwAAAAAAAAAAAAFLpvEeAAAAQHbHXU77KC1q+LIt/TffCV/wSlo/2rwuVgIfbV+Bb0yJ9Bd8qk744JxZov8T1iwd4XiN9zlKCHwN2brf1Ka1nA8=", "network_passphrase": "Public Global Stellar Network ; September 2015" } ``` -You can examine the example challenge transaction in the [XDR Viewer](https://www.stellar.org/laboratory/#xdr-viewer?input=AAAAAGjeCRajN67nRkVtYO%2Blpxax9gvitX9FxhZYGXQvs16hAAAAZAAAAAAAAAAAAAAAAQAAAABbcutKAAAAAFty7HYAAAAAAAAAAQAAAAEAAAAAVIx5odtAgqQ%2Bdp4m4QfWntHbOq0hxRCLGI%2B2Sm0P6EMAAAAKAAAAC01vYml1cyBhdXRoAAAAAAEAAABAG01TL%2FHa0YGVrAF6t0UEKP%2F0Q%2FNDUymciQBA%2FCXzYMVlEx2KcHrq3MkpQ9%2B9sCbCiOYa7wCtusa1tHKygvZRSwAAAAAAAAABL7NeoQAAAEC9v5jdxReIxoCcCXw90dVsIpXwHXkSHUUthCs98D%2Fzpd6TNPvcMgUsQd6cDHzjNk%2B%2F00P8M5bHP4rIpFTm7MwN&type=TransactionEnvelope&network=test). +You can examine the example challenge transaction in the [XDR Viewer](https://laboratory.stellar.org/#xdr-viewer?input=AAAAAgAAAAC2c0axdmfUQ%2FDq5fRRlvtybUBghi3vdOe3nHnMS6bxHgAAAGQAAAAAAAAAAAAAAAEAAAAAXza9AQAAAABfNhe8AAAAAAAAAAEAAAABAAAAAN1RWGc1gsEPHI%2FV0igO6YRsOYcwN8m%2FTuuGysVv4vz3AAAACgAAAAhTREYgYXV0aAAAAAEAAAAWdGVzdGFuY2hvci5zdGVsbGFyLm9yZwAAAAAAAAAAAAFLpvEeAAAAQHbHXU77KC1q%2BLIt%2FTffCV%2FwSlo%2F2rwuVgIfbV%2BBb0yJ9Bd8qk744JxZov8T1iwd4XiN9zlKCHwN2brf1Ka1nA8%3D&type=TransactionEnvelope) Every other HTTP status code will be considered an error. For example: @@ -132,7 +132,9 @@ To validate the challenge transaction the following steps are performed by the s * decode the received input as a base64-urlencoded XDR representation of Stellar transaction envelope; * verify that transaction source account is equal to the server's signing key; * 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 and its source account is not null; +* 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 service's home domain as the value 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; @@ -177,10 +179,10 @@ Example: POST https://auth.example.com/ Content-Type: application/json -{"transaction": "AAAAAGjeCRajN67nRkVtYO+lpxax9gvitX9FxhZYGXQvs16hAAAAZAAAAAAAAAAAAAAAAQAAAABbcutKAAAAAFty7HYAAAAAAAAAAQAAAAEAAAAAVIx5odtAgqQ+dp4m4QfWntHbOq0hxRCLGI+2Sm0P6EMAAAAKAAAAC01vYml1cyBhdXRoAAAAAAEAAABAG01TL/Ha0YGVrAF6t0UEKP/0Q/NDUymciQBA/CXzYMVlEx2KcHrq3MkpQ9+9sCbCiOYa7wCtusa1tHKygvZRSwAAAAAAAAACL7NeoQAAAEC9v5jdxReIxoCcCXw90dVsIpXwHXkSHUUthCs98D/zpd6TNPvcMgUsQd6cDHzjNk+/00P8M5bHP4rIpFTm7MwNbQ/oQwAAAEAz+6EANIKAAR8G62OkGzbnkxgyYuFwbbCwvbDbkk8db31I/EyR0gRpcxv7zzBAkn8g48N6x1huJhTUO0CPl28M"} +{"transaction": "AAAAAgAAAAC2c0axdmfUQ/Dq5fRRlvtybUBghi3vdOe3nHnMS6bxHgAAAGQAAAAAAAAAAAAAAAEAAAAAXza9AQAAAABfNhe8AAAAAAAAAAEAAAABAAAAAN1RWGc1gsEPHI/V0igO6YRsOYcwN8m/TuuGysVv4vz3AAAACgAAAAhTREYgYXV0aAAAAAEAAAAWdGVzdGFuY2hvci5zdGVsbGFyLm9yZwAAAAAAAAAAAAJLpvEeAAAAQHbHXU77KC1q+LIt/TffCV/wSlo/2rwuVgIfbV+Bb0yJ9Bd8qk744JxZov8T1iwd4XiN9zlKCHwN2brf1Ka1nA9v4vz3AAAAQPXRinr7u9JJvM3gMUftqDLhURPy+4AMcV6dCrs1fLMd+YOMxMPg9oWvg3JAeiscEUgJ46Xv70zca13bBf5nWgc="} ``` -You can examine the example signed challenge transaction in the [XDR Viewer](https://www.stellar.org/laboratory/#xdr-viewer?input=AAAAAGjeCRajN67nRkVtYO%2Blpxax9gvitX9FxhZYGXQvs16hAAAAZAAAAAAAAAAAAAAAAQAAAABbcutKAAAAAFty7HYAAAAAAAAAAQAAAAEAAAAAVIx5odtAgqQ%2Bdp4m4QfWntHbOq0hxRCLGI%2B2Sm0P6EMAAAAKAAAAC01vYml1cyBhdXRoAAAAAAEAAABAG01TL%2FHa0YGVrAF6t0UEKP%2F0Q%2FNDUymciQBA%2FCXzYMVlEx2KcHrq3MkpQ9%2B9sCbCiOYa7wCtusa1tHKygvZRSwAAAAAAAAACL7NeoQAAAEC9v5jdxReIxoCcCXw90dVsIpXwHXkSHUUthCs98D%2Fzpd6TNPvcMgUsQd6cDHzjNk%2B%2F00P8M5bHP4rIpFTm7MwNbQ%2FoQwAAAEAz%2B6EANIKAAR8G62OkGzbnkxgyYuFwbbCwvbDbkk8db31I%2FEyR0gRpcxv7zzBAkn8g48N6x1huJhTUO0CPl28M&type=TransactionEnvelope&network=test). +You can examine the example signed challenge transaction in the [XDR Viewer](https://laboratory.stellar.org/#xdr-viewer?input=AAAAAgAAAAC2c0axdmfUQ%2FDq5fRRlvtybUBghi3vdOe3nHnMS6bxHgAAAGQAAAAAAAAAAAAAAAEAAAAAXza9AQAAAABfNhe8AAAAAAAAAAEAAAABAAAAAN1RWGc1gsEPHI%2FV0igO6YRsOYcwN8m%2FTuuGysVv4vz3AAAACgAAAAhTREYgYXV0aAAAAAEAAAAWdGVzdGFuY2hvci5zdGVsbGFyLm9yZwAAAAAAAAAAAAJLpvEeAAAAQHbHXU77KC1q%2BLIt%2FTffCV%2FwSlo%2F2rwuVgIfbV%2BBb0yJ9Bd8qk744JxZov8T1iwd4XiN9zlKCHwN2brf1Ka1nA9v4vz3AAAAQPXRinr7u9JJvM3gMUftqDLhURPy%2B4AMcV6dCrs1fLMd%2BYOMxMPg9oWvg3JAeiscEUgJ46Xv70zca13bBf5nWgc%3D&type=TransactionEnvelope) #### Response From fba9de618ce3a8f2603884a38f9b18f4fc10fa4d Mon Sep 17 00:00:00 2001 From: Jake Urban Date: Fri, 14 Aug 2020 10:16:16 -0700 Subject: [PATCH 2/7] fixed the numbering --- ecosystem/sep-0010.md | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-) diff --git a/ecosystem/sep-0010.md b/ecosystem/sep-0010.md index d66af5995..0dc164dc6 100644 --- a/ecosystem/sep-0010.md +++ b/ecosystem/sep-0010.md @@ -22,21 +22,21 @@ The authentication flow is as follows: 1. The client obtains a unique [`challenge`](#challenge), 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. -2. 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). -3. The client verifies that the transaction includes a Manage Data operation containing a `home_domain` key-value pair, and that the value contains the home domain used to request the challenge. -5. The client signs the transaction using the secret key(s) of signers for the user's Stellar account -6. The client submits the signed challenge back to the server using [`token`](#token) endpoint -7. The server checks that the user's account exists -8. If the user's account exists: +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 includes a Manage Data operation containing a `home_domain` key-value pair, and that the value contains the home domain used to request the challenge. +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 +1. The server checks that the user's account exists +1. If the user's account exists: 1. The server gets the signers of the user's account - 2. The server verifies the client signatures count is one or more; - 3. The server verifies the client signatures on the transaction are signers of the user's account; - 4. The server verifies the weight provided by the signers meets the required threshold(s), if any - 5. If the signatures check out, the server responds with a [JWT](https://jwt.io) that represents the user's session -9. If the user's account does not exist (optional): - 6. The server verifies the client signature count is one - 7. The server verifies the client signature is correct for the master key of the account -10. Any future calls to the server can be authenticated by including the JWT as a parameter + 1. The server verifies the client signatures count is one or more; + 1. The server verifies the client signatures on the transaction are signers of the user's account; + 1. The server verifies the weight provided by the signers meets the required threshold(s), if any + 1. If the signatures check out, the server responds with a [JWT](https://jwt.io) that represents the user's session +1. If the user's account does not exist (optional): + 1. The server verifies the client signature count is one + 1. The server verifies the client signature is correct for the master key of the account +1. Any future calls to the server can be authenticated by including the JWT as a parameter The flow achieves several things: From 3beb591c49901c74ce95d6e4ee8a189280b602fa Mon Sep 17 00:00:00 2001 From: Jake Urban Date: Fri, 14 Aug 2020 10:17:14 -0700 Subject: [PATCH 3/7] simplify 2nd added step --- ecosystem/sep-0010.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ecosystem/sep-0010.md b/ecosystem/sep-0010.md index 0dc164dc6..72fbca7e4 100644 --- a/ecosystem/sep-0010.md +++ b/ecosystem/sep-0010.md @@ -23,7 +23,7 @@ The authentication flow is as follows: 1. The client obtains a unique [`challenge`](#challenge), 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 includes a Manage Data operation containing a `home_domain` key-value pair, and that the value contains the home domain used to request the challenge. +1. The client verifies that the transaction includes a Manage Data operation, and that the value contains the home domain used to request the challenge. 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 1. The server checks that the user's account exists From ea9bdfe4944e801472a18f7a17a0b7c4566c2a38 Mon Sep 17 00:00:00 2001 From: Jake Urban Date: Mon, 17 Aug 2020 12:08:40 -0700 Subject: [PATCH 4/7] changes related to PR comments --- ecosystem/sep-0010.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/ecosystem/sep-0010.md b/ecosystem/sep-0010.md index 72fbca7e4..120ba835c 100644 --- a/ecosystem/sep-0010.md +++ b/ecosystem/sep-0010.md @@ -96,19 +96,21 @@ On success the endpoint must return `200 OK` HTTP status code and a JSON object * source account set to server's signing account * invalid sequence number (set to 0) so the transaction cannot be run on the Stellar network * 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: ' auth', value: '')` + * operations: `manage_data(source: client_account, key: ' auth', value: random_nonce())` + * The value of key is the signing server's [fully qualified domain name](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) followed by `auth`. It can be at most 48 characters (64 bytes after encoding). + * 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). * signature by the service's stellar.toml `SIGNING_KEY` * `network_passphrase`: (optional but recommended) Stellar network passphrase used by the server. This allows the client to verify that it's using the correct passphrase when signing and is useful for identifying when a client or server have been configured incorrectly. Example: ```json { - "transaction": "AAAAAgAAAAC2c0axdmfUQ/Dq5fRRlvtybUBghi3vdOe3nHnMS6bxHgAAAGQAAAAAAAAAAAAAAAEAAAAAXza9AQAAAABfNhe8AAAAAAAAAAEAAAABAAAAAN1RWGc1gsEPHI/V0igO6YRsOYcwN8m/TuuGysVv4vz3AAAACgAAAAhTREYgYXV0aAAAAAEAAAAWdGVzdGFuY2hvci5zdGVsbGFyLm9yZwAAAAAAAAAAAAFLpvEeAAAAQHbHXU77KC1q+LIt/TffCV/wSlo/2rwuVgIfbV+Bb0yJ9Bd8qk744JxZov8T1iwd4XiN9zlKCHwN2brf1Ka1nA8=", + "transaction": "AAAAAgAAAADIiRu2BrqqeOcP28PWCkD4D5Rjjsqh71HwvqFX+F4VXAAAAGQAAAAAAAAAAAAAAAEAAAAAXzrUcQAAAABfOtf1AAAAAAAAAAEAAAABAAAAAEEB8rhqNa70RYjaNnF1ARE2CbL50iR9HPXST/fImJN1AAAACgAAADB0aGlzaXNhdGVzdC5zYW5kYm94LmFuY2hvci5hbmNob3Jkb21haW4uY29tIGF1dGgAAAABAAAAQGdGOFlIQm1zaGpEWEY0L0VJUFZucGVlRkxVTDY2V0tKMVBPYXZuUVVBNjBoL09XaC91M2Vvdk54WFJtSTAvQ2UAAAAAAAAAAfheFVwAAABAheKE1HjGnUCNwPbX8mz7CqotShKbA+xM2Hbjl6X0TBpEprVOUVjA6lqMJ1j62vrxn1mF3eJzsLa9s9hRofG3Ag==", "network_passphrase": "Public Global Stellar Network ; September 2015" } ``` -You can examine the example challenge transaction in the [XDR Viewer](https://laboratory.stellar.org/#xdr-viewer?input=AAAAAgAAAAC2c0axdmfUQ%2FDq5fRRlvtybUBghi3vdOe3nHnMS6bxHgAAAGQAAAAAAAAAAAAAAAEAAAAAXza9AQAAAABfNhe8AAAAAAAAAAEAAAABAAAAAN1RWGc1gsEPHI%2FV0igO6YRsOYcwN8m%2FTuuGysVv4vz3AAAACgAAAAhTREYgYXV0aAAAAAEAAAAWdGVzdGFuY2hvci5zdGVsbGFyLm9yZwAAAAAAAAAAAAFLpvEeAAAAQHbHXU77KC1q%2BLIt%2FTffCV%2FwSlo%2F2rwuVgIfbV%2BBb0yJ9Bd8qk744JxZov8T1iwd4XiN9zlKCHwN2brf1Ka1nA8%3D&type=TransactionEnvelope) +You can examine the example challenge transaction in the [XDR Viewer](https://laboratory.stellar.org/#xdr-viewer?input=AAAAAgAAAADIiRu2BrqqeOcP28PWCkD4D5Rjjsqh71HwvqFX%2BF4VXAAAAGQAAAAAAAAAAAAAAAEAAAAAXzrUcQAAAABfOtf1AAAAAAAAAAEAAAABAAAAAEEB8rhqNa70RYjaNnF1ARE2CbL50iR9HPXST%2FfImJN1AAAACgAAADB0aGlzaXNhdGVzdC5zYW5kYm94LmFuY2hvci5hbmNob3Jkb21haW4uY29tIGF1dGgAAAABAAAAQGdGOFlIQm1zaGpEWEY0L0VJUFZucGVlRkxVTDY2V0tKMVBPYXZuUVVBNjBoL09XaC91M2Vvdk54WFJtSTAvQ2UAAAAAAAAAAfheFVwAAABAheKE1HjGnUCNwPbX8mz7CqotShKbA%2BxM2Hbjl6X0TBpEprVOUVjA6lqMJ1j62vrxn1mF3eJzsLa9s9hRofG3Ag%3D%3D&type=TransactionEnvelope) Every other HTTP status code will be considered an error. For example: @@ -179,10 +181,10 @@ Example: POST https://auth.example.com/ Content-Type: application/json -{"transaction": "AAAAAgAAAAC2c0axdmfUQ/Dq5fRRlvtybUBghi3vdOe3nHnMS6bxHgAAAGQAAAAAAAAAAAAAAAEAAAAAXza9AQAAAABfNhe8AAAAAAAAAAEAAAABAAAAAN1RWGc1gsEPHI/V0igO6YRsOYcwN8m/TuuGysVv4vz3AAAACgAAAAhTREYgYXV0aAAAAAEAAAAWdGVzdGFuY2hvci5zdGVsbGFyLm9yZwAAAAAAAAAAAAJLpvEeAAAAQHbHXU77KC1q+LIt/TffCV/wSlo/2rwuVgIfbV+Bb0yJ9Bd8qk744JxZov8T1iwd4XiN9zlKCHwN2brf1Ka1nA9v4vz3AAAAQPXRinr7u9JJvM3gMUftqDLhURPy+4AMcV6dCrs1fLMd+YOMxMPg9oWvg3JAeiscEUgJ46Xv70zca13bBf5nWgc="} +{"transaction": "AAAAAgAAAADIiRu2BrqqeOcP28PWCkD4D5Rjjsqh71HwvqFX+F4VXAAAAGQAAAAAAAAAAAAAAAEAAAAAXzrUcQAAAABfOtf1AAAAAAAAAAEAAAABAAAAAEEB8rhqNa70RYjaNnF1ARE2CbL50iR9HPXST/fImJN1AAAACgAAADB0aGlzaXNhdGVzdC5zYW5kYm94LmFuY2hvci5hbmNob3Jkb21haW4uY29tIGF1dGgAAAABAAAAQGdGOFlIQm1zaGpEWEY0L0VJUFZucGVlRkxVTDY2V0tKMVBPYXZuUVVBNjBoL09XaC91M2Vvdk54WFJtSTAvQ2UAAAAAAAAAAvheFVwAAABAheKE1HjGnUCNwPbX8mz7CqotShKbA+xM2Hbjl6X0TBpEprVOUVjA6lqMJ1j62vrxn1mF3eJzsLa9s9hRofG3AsiYk3UAAABArIrkvqmA0V9lIZcVyCUdja6CiwkPwsV8BfI4CZOyR1Oq7ysvNJWwY0G42dpxN9OP1qz4dum8apG2hqvxVWjkDQ=="} ``` -You can examine the example signed challenge transaction in the [XDR Viewer](https://laboratory.stellar.org/#xdr-viewer?input=AAAAAgAAAAC2c0axdmfUQ%2FDq5fRRlvtybUBghi3vdOe3nHnMS6bxHgAAAGQAAAAAAAAAAAAAAAEAAAAAXza9AQAAAABfNhe8AAAAAAAAAAEAAAABAAAAAN1RWGc1gsEPHI%2FV0igO6YRsOYcwN8m%2FTuuGysVv4vz3AAAACgAAAAhTREYgYXV0aAAAAAEAAAAWdGVzdGFuY2hvci5zdGVsbGFyLm9yZwAAAAAAAAAAAAJLpvEeAAAAQHbHXU77KC1q%2BLIt%2FTffCV%2FwSlo%2F2rwuVgIfbV%2BBb0yJ9Bd8qk744JxZov8T1iwd4XiN9zlKCHwN2brf1Ka1nA9v4vz3AAAAQPXRinr7u9JJvM3gMUftqDLhURPy%2B4AMcV6dCrs1fLMd%2BYOMxMPg9oWvg3JAeiscEUgJ46Xv70zca13bBf5nWgc%3D&type=TransactionEnvelope) +You can examine the example signed challenge transaction in the [XDR Viewer](https://laboratory.stellar.org/#xdr-viewer?input=AAAAAgAAAADIiRu2BrqqeOcP28PWCkD4D5Rjjsqh71HwvqFX%2BF4VXAAAAGQAAAAAAAAAAAAAAAEAAAAAXzrUcQAAAABfOtf1AAAAAAAAAAEAAAABAAAAAEEB8rhqNa70RYjaNnF1ARE2CbL50iR9HPXST%2FfImJN1AAAACgAAADB0aGlzaXNhdGVzdC5zYW5kYm94LmFuY2hvci5hbmNob3Jkb21haW4uY29tIGF1dGgAAAABAAAAQGdGOFlIQm1zaGpEWEY0L0VJUFZucGVlRkxVTDY2V0tKMVBPYXZuUVVBNjBoL09XaC91M2Vvdk54WFJtSTAvQ2UAAAAAAAAAAvheFVwAAABAheKE1HjGnUCNwPbX8mz7CqotShKbA%2BxM2Hbjl6X0TBpEprVOUVjA6lqMJ1j62vrxn1mF3eJzsLa9s9hRofG3AsiYk3UAAABArIrkvqmA0V9lIZcVyCUdja6CiwkPwsV8BfI4CZOyR1Oq7ysvNJWwY0G42dpxN9OP1qz4dum8apG2hqvxVWjkDQ%3D%3D&type=TransactionEnvelope) #### Response From 7b753df9e15e5a9a1fe074959089d30ff75bbd9e Mon Sep 17 00:00:00 2001 From: Jake Urban Date: Mon, 17 Aug 2020 12:17:47 -0700 Subject: [PATCH 5/7] update description of managedata op --- ecosystem/sep-0010.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ecosystem/sep-0010.md b/ecosystem/sep-0010.md index 120ba835c..aefcd7b75 100644 --- a/ecosystem/sep-0010.md +++ b/ecosystem/sep-0010.md @@ -136,7 +136,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 service's home domain as the value of the operation + * has the service's 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; From 59e0c619ad25018240913ab0a00d8a7aef596a64 Mon Sep 17 00:00:00 2001 From: Jake Urban Date: Wed, 19 Aug 2020 13:25:58 -0700 Subject: [PATCH 6/7] update to 2.0 --- ecosystem/sep-0010.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ecosystem/sep-0010.md b/ecosystem/sep-0010.md index aefcd7b75..1810a5d7e 100644 --- a/ecosystem/sep-0010.md +++ b/ecosystem/sep-0010.md @@ -7,7 +7,7 @@ Author: Sergey Nebolsin , Tom Quisel Date: Mon, 24 Aug 2020 11:13:04 -0700 Subject: [PATCH 7/7] changes regarding manage data op key encoding and optional home_domain GET parameter --- ecosystem/sep-0010.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/ecosystem/sep-0010.md b/ecosystem/sep-0010.md index 1810a5d7e..edcacb35d 100644 --- a/ecosystem/sep-0010.md +++ b/ecosystem/sep-0010.md @@ -81,6 +81,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. Example: @@ -97,7 +98,7 @@ On success the endpoint must return `200 OK` HTTP status code and a JSON object * invalid sequence number (set to 0) so the transaction cannot be run on the Stellar network * 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: ' auth', value: random_nonce())` - * The value of key is the signing server's [fully qualified domain name](https://en.wikipedia.org/wiki/Fully_qualified_domain_name) followed by `auth`. It can be at most 48 characters (64 bytes after encoding). + * 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 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). * signature by the service's stellar.toml `SIGNING_KEY` * `network_passphrase`: (optional but recommended) Stellar network passphrase used by the server. This allows the client to verify that it's using the correct passphrase when signing and is useful for identifying when a client or server have been configured incorrectly.