From 9c9c5a8c65db6fcbc7ce2edd0fe555ef34153370 Mon Sep 17 00:00:00 2001 From: Richard van der Hoff Date: Thu, 6 Dec 2018 16:06:17 +0000 Subject: [PATCH] more alternatives --- proposals/1730-cs-api-in-login-response.md | 31 ++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/proposals/1730-cs-api-in-login-response.md b/proposals/1730-cs-api-in-login-response.md index 5d8652c6..93cfc29e 100644 --- a/proposals/1730-cs-api-in-login-response.md +++ b/proposals/1730-cs-api-in-login-response.md @@ -119,3 +119,34 @@ HS. The client would then repeat its `/login` request, and use the specified endpoint for all future C-S interaction. This approach would complicate client implementations. + +### Modify the single-sign-on flow + +It would be possible to modify the single-sign-on flow to allow an alternative +homeserver to be specified for the final `m.login.token`-based call to +`/login` (and subsequent C-S API calls). + +This is discussed in more detail in +[MSC1731](https://github.com/matrix-org/matrix-doc/blob/rav/proposals/homeserver_in_sso_login/proposals/1731-redirect-in-sso-login.md). + +It has the disadvantage of limiting the solution to SSO logins. The solution +presented in this proposal also extends to password-based logins. + +### Use a 3pid login flow + +It has been suggested that we could use a login flow based on third-party +identifiers. + +In the current ecosystem, to do a 3pid login, clients must still be configured +to send their `/login` request to a particular homeserver, which will then take +them through an authentication process. We are therefore still left with the +problem that we need to switch homeservers between login and initial sync. + +An alternative would be for clients to somehow know that they should go through +the single-sign-on process *before* choosing a homeserver, and for the +output of the single-sign-on process to indicate the homeserver to use. This +would require either substantially customised Matrix clients, or substantial +modifications to the login flow in Matrix, possibly involving authenticating +against an identity server. The latter is something which could be considered, +but the scope of the changes required make it impractical in the short/medium +term.