From d3f21e03605ad1dafb548b0386716103905d6282 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Wed, 5 Jun 2019 17:54:18 +0100 Subject: [PATCH] Address review comments --- proposals/2078-homeserver-password-resets.md | 35 ++++++++++++++------ 1 file changed, 25 insertions(+), 10 deletions(-) diff --git a/proposals/2078-homeserver-password-resets.md b/proposals/2078-homeserver-password-resets.md index 0052c48e..64916931 100644 --- a/proposals/2078-homeserver-password-resets.md +++ b/proposals/2078-homeserver-password-resets.md @@ -31,6 +31,17 @@ an endpoint (with the same parameters as [/_matrix/identity/api/v1/validate/email/submitToken](https://matrix.org/docs/spec/identity_service/r0.1.0.html#post-matrix-identity-api-v1-validate-email-submittoken)) to verify that token. +Consideration was taken not to make `id_server` and optional field. Let's +assume for a moment that it was optional. Now, a client could send a request to +`/requestToken` omitting the `id_server` field. The homeserver however has +opted to continue proxying `/requestToken` to the identity server, even though +it knows this is potentially insecure. The homeserver now has no idea which +identity server to proxy the request to, and must return a failure to the +client. The client could then make another request with an `id_server`, but +we've now made two requests that ended up in the same outcome, instead of one, +in hopes of saving a very small amount of bandwidth by omitting the field +originally. + An additional complication is that in the case of SMS, a full link to reset passwords is not sent, but a short code. The client then asks the user to enter this code, however the client may now not know where to send the code. Should @@ -40,15 +51,19 @@ In order to combat this problem, the field `submit_url` should be added in the response from both the email and msisdn variants of the `/requestToken` Client-Server API, if and only if the verification message contains a code the user is expected to enter into the client (for instance in the case of a short -code through SMS). If this field is omitted, the client should continue the -same behaviour from before, which is to send the token to the identity server -directly. This is intended for backwards compatibility with older servers. - -If the client receives a response to `/requestToken` with `submit_url`, it -should accept the token from user input, then make a POST request to the -content of `submit_url` with the `sid`, `client_secret` and user-entered token. +code through SMS). It SHOULD be in the form of +`/_matrix/identity/api/v1/validate/{3pid_type}/submitToken`, similar to the +[same endpoint that exists in the Identity-Server +API](https://matrix.org/docs/spec/identity_service/r0.1.0.html#post-matrix-identity-api-v1-validate-email-submittoken). +If this field is omitted, the client MUST continue the same behaviour from +before, which is to send the token to the identity server directly. This is +intended for backwards compatibility with older servers. + +If the client receives a response to `/requestToken` with `submit_url`, it MUST +accept the token from user input, then make a POST request to the content of +`submit_url` with the `sid`, `client_secret` and user-entered token. `submit_url` can lead to anywhere the homeserver deems necessary for -verification. This data should be submitted as a JSON body. +verification. This data MUST be submitted as a JSON body. An example exchange from the client's perspective is shown below: @@ -69,7 +84,7 @@ collect a token from the user and then submit it to the provided URL. ``` { "sid": "123abc", - "submit_url": "https://homeserver.tld/path/to/submitToken" + "submit_url": "https://homeserver.tld/_matrix/identity/api/v1/validate/msisdn/submitToken" } ``` @@ -78,7 +93,7 @@ user, say "123456", and then submit that as a POST request to the `"submit_url"`. ``` -POST https://homeserver.tld/path/to/submitToken +POST https://homeserver.tld/_matrix/identity/api/v1/validate/msisdn/submitToken { "sid": "123abc",