Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

SEP-0010: Revert home domain verification and relax manage data operation constraints (v2.1.0) #740

Merged
merged 5 commits into from
Oct 14, 2020
Merged

SEP-0010: Revert home domain verification and relax manage data operation constraints (v2.1.0) #740

Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
72b4450
SEP-0010: Revert home domain verification and relax manage data opera…
leighmcculloch Oct 5, 2020
9bb6226
Set date
leighmcculloch Oct 8, 2020
6409685
Be explicit about where the client and server accounts are stored in …
leighmcculloch Oct 8, 2020
de05e0f
Be explicit that the home domain is ignored by the client
leighmcculloch Oct 8, 2020
9ab7597
Merge branch 'master' into sep10-v2.1.0
leighmcculloch Oct 14, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
21 changes: 12 additions & 9 deletions ecosystem/sep-0010.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,8 +6,8 @@ Title: Stellar Web Authentication
Author: Sergey Nebolsin <sergey@mobius.network>, Tom Quisel <tom.quisel@gmail.com>, Leigh McCulloch <@leighmcculloch>, Jake Urban <jake@stellar.org>
Status: Active
Created: 2018-07-31
Updated: 2020-08-14
Version 2.0.0
Updated: 2020-??-??
leighmcculloch marked this conversation as resolved.
Show resolved Hide resolved
Version 2.1.0
```

## Simple Summary
Expand All @@ -23,7 +23,8 @@ 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, and that the value contains the home domain used to request the challenge.
1. The client verifies that the transaction has a single Manage Data operation containing the user's account and a nonce.
leighmcculloch marked this conversation as resolved.
Show resolved Hide resolved
1. The client verifies that if the transaction has other Manage Data operations they all contain the server's account.
leighmcculloch marked this conversation as resolved.
Show resolved Hide resolved
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
Expand Down Expand Up @@ -68,7 +69,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 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.
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).

#### Request

Expand Down Expand Up @@ -97,9 +98,11 @@ 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: '<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 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).
* operations:
* `manage_data(source: client_account, key: '<home domain> auth', value: random_nonce())`
leighmcculloch marked this conversation as resolved.
Show resolved Hide resolved
* 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).
* zero or more `manage_data(source: server_account, ...)` reserved for future use
* 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.

Expand Down Expand Up @@ -136,8 +139,7 @@ To validate the challenge transaction the following steps are performed by the s
* 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 that:
* has a non-null source account
* has the service's home domain as the key of the operation
* has a non-null source account
leighmcculloch marked this conversation as resolved.
Show resolved Hide resolved
* 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;
Expand All @@ -147,6 +149,7 @@ To validate the challenge transaction the following steps are performed by the s
* if the operation's source account does not exist:
* verify that client signature count is one;
* verify that client signature is correct for the master key of the account address;
* verify that transaction containing additional Manage Data operations have their source account as the server signing key;
* verify that transaction sequenceNumber is equal to zero;
* use operations's source account to determine the authenticating client and perform any additional service-specific validations.

Expand Down