From 6330fff5a4bdb1691898ccd7bfb435cbfda98b11 Mon Sep 17 00:00:00 2001 From: David Baker Date: Mon, 12 Aug 2019 18:13:58 +0100 Subject: [PATCH 1/6] Draft for IS URL in account data --- .../xxxx-identity-server-account-data.md | 74 +++++++++++++++++++ 1 file changed, 74 insertions(+) create mode 100644 proposals/xxxx-identity-server-account-data.md diff --git a/proposals/xxxx-identity-server-account-data.md b/proposals/xxxx-identity-server-account-data.md new file mode 100644 index 000000000..da539f2a2 --- /dev/null +++ b/proposals/xxxx-identity-server-account-data.md @@ -0,0 +1,74 @@ +# Store Identity Server in Account Data + +The URL of the Identity Sever to use is currently specified at registration and +login time and then used for the lifetime of a login session. If users wish to +specify a custom one, they must do so each time they log in on every client. +Once they have chosen an Identity Server to advertise their 3PIDs on, it would +be normal that they would wish to continue using this Identity Server for all +Identity requests in their account accross all clients. This proposal aims to +make this easier. + +## Proposal + +The base URL of the Identity Server is to be stored in user account data. It +shall be stored in the same format as in a .well-known file under the key, +`m.identity_server` and shall comprise a single key, `base_url` which is the +base URL of the ID Server to use (that is, the part before `/_matrix`). + +Upon registration or login, a client MUST refrain from performing any requests +to the Identity Server until the account data has been fetched from the server. +Once it has the account data, it MUST check for the presence of the +`m.identity_server` key. If present, the `base_url` in this key MUST be used +as the Identity Server base URL for the duration of the login session. If this +key is not present, the client SHOULD populate it with the ID Server URL +that was or would have been used in the login/registration process. This may +be either from user input, a .well-known lookup, or a default in the client. + +Client MUST listen for changes in the `m.identity_server` account data value +and update the URL that they use for ID Server requests accordingly UNLESS +the login session and choice of ID Server base URL predates this change, in +which case they SHOULD continue to use the value they are currently using. + +Clients MAY offer a way for users to change the ID server being used. If they +do, the client MUST update the value of `m.identity_server` accordingly. + +The `m.identity_server` may be present with a value of `null`. In this case, +clients MUST treat this as no ID Server URL being set and not perform ID +Server requests, disabling any functionality that requires such requests. + +Conversely, if a user wishes to disable ID Server functionality, the client +shall action this by setting the `base_url` of the `m.identity_server` +account data entry to `null`. + +### Transition Period + +Clients currently logged in with a value configured for the ID Server base +URL SHOULD use the value from `m.identity_server` if it exists or is created, +but otherwise continue to use the URL they had previously. They MUST NOT +populate the `m.identity_server` with their current ID Server base URL. + +## Tradeoffs + +There are a number of ways to transition to this new scheme. Clients could +populate the account data with their current ID Server URL as soon as +possible, and immediately use any new value seen on account data. This +would a much faster migration but any users with clients using different +ID Servers would suddenly find all their clients using the ID Server of +whichever client they updated first. + +## Potential issues + +Users will no longer be able to have different clients configured with +different ID Servers. + +## Security considerations + +An attacker would be able to force all a user clients to use a given ID Server +if they gained control of any of a user's logins. + +## Conclusion + +This makes the ID server an account setting which means it persists between +logins. The intention would be to phase out clients ever asking for an ID +Server URL at registration or login: this will be much easier for users to +understand whilst still retaining the flexibilty for those who want it. From 2c8d112089e9ab1290118d72c40b93a28b29e014 Mon Sep 17 00:00:00 2001 From: David Baker Date: Tue, 13 Aug 2019 18:03:43 +0100 Subject: [PATCH 2/6] assign number --- ...ver-account-data.md => 2230-identity-server-account-data.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename proposals/{xxxx-identity-server-account-data.md => 2230-identity-server-account-data.md} (98%) diff --git a/proposals/xxxx-identity-server-account-data.md b/proposals/2230-identity-server-account-data.md similarity index 98% rename from proposals/xxxx-identity-server-account-data.md rename to proposals/2230-identity-server-account-data.md index da539f2a2..b863cc593 100644 --- a/proposals/xxxx-identity-server-account-data.md +++ b/proposals/2230-identity-server-account-data.md @@ -1,4 +1,4 @@ -# Store Identity Server in Account Data +# MSC2230: Store Identity Server in Account Data The URL of the Identity Sever to use is currently specified at registration and login time and then used for the lifetime of a login session. If users wish to From 229cb67b01c92925dcc5a00c7660189b82fa318e Mon Sep 17 00:00:00 2001 From: David Baker Date: Wed, 14 Aug 2019 09:51:27 +0100 Subject: [PATCH 3/6] Apply suggestions from code review Use fewer formal MUST etc in proposal Co-Authored-By: Travis Ralston --- proposals/2230-identity-server-account-data.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/proposals/2230-identity-server-account-data.md b/proposals/2230-identity-server-account-data.md index b863cc593..3a81fa8ef 100644 --- a/proposals/2230-identity-server-account-data.md +++ b/proposals/2230-identity-server-account-data.md @@ -15,21 +15,21 @@ shall be stored in the same format as in a .well-known file under the key, `m.identity_server` and shall comprise a single key, `base_url` which is the base URL of the ID Server to use (that is, the part before `/_matrix`). -Upon registration or login, a client MUST refrain from performing any requests +Upon registration or login, a client SHOULD refrain from performing any requests to the Identity Server until the account data has been fetched from the server. -Once it has the account data, it MUST check for the presence of the -`m.identity_server` key. If present, the `base_url` in this key MUST be used +Once it has the account data, it SHOULD check for the presence of the +`m.identity_server` key. If present, the `base_url` in this key SHOULD be used as the Identity Server base URL for the duration of the login session. If this key is not present, the client SHOULD populate it with the ID Server URL -that was or would have been used in the login/registration process. This may +that was or would have been used in the login/registration process. This could be either from user input, a .well-known lookup, or a default in the client. -Client MUST listen for changes in the `m.identity_server` account data value -and update the URL that they use for ID Server requests accordingly UNLESS +Client SHOULD listen for changes in the `m.identity_server` account data value +and update the URL that they use for ID Server requests accordingly unless the login session and choice of ID Server base URL predates this change, in which case they SHOULD continue to use the value they are currently using. -Clients MAY offer a way for users to change the ID server being used. If they +Clients can offer a way for users to change the ID server being used. If they do, the client MUST update the value of `m.identity_server` accordingly. The `m.identity_server` may be present with a value of `null`. In this case, From b9b984ae60172892c13efc5702d68c438ceac0e5 Mon Sep 17 00:00:00 2001 From: David Baker Date: Wed, 14 Aug 2019 09:52:13 +0100 Subject: [PATCH 4/6] clarify --- proposals/2230-identity-server-account-data.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/2230-identity-server-account-data.md b/proposals/2230-identity-server-account-data.md index 3a81fa8ef..d26de3e29 100644 --- a/proposals/2230-identity-server-account-data.md +++ b/proposals/2230-identity-server-account-data.md @@ -13,7 +13,8 @@ make this easier. The base URL of the Identity Server is to be stored in user account data. It shall be stored in the same format as in a .well-known file under the key, `m.identity_server` and shall comprise a single key, `base_url` which is the -base URL of the ID Server to use (that is, the part before `/_matrix`). +base URL of the ID Server to use (that is, the part before `/_matrix`, including +`https://`). Upon registration or login, a client SHOULD refrain from performing any requests to the Identity Server until the account data has been fetched from the server. From 9b2ca3cdfe99414e4cf2047c13a20991e32d6aae Mon Sep 17 00:00:00 2001 From: David Baker Date: Tue, 20 Aug 2019 16:19:15 +0100 Subject: [PATCH 5/6] typoes / clarifications Co-Authored-By: Richard van der Hoff <1389908+richvdh@users.noreply.github.com> --- proposals/2230-identity-server-account-data.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/proposals/2230-identity-server-account-data.md b/proposals/2230-identity-server-account-data.md index d26de3e29..98fcfbf11 100644 --- a/proposals/2230-identity-server-account-data.md +++ b/proposals/2230-identity-server-account-data.md @@ -1,6 +1,6 @@ # MSC2230: Store Identity Server in Account Data -The URL of the Identity Sever to use is currently specified at registration and +The URL of the Identity Server to use is currently specified at registration and login time and then used for the lifetime of a login session. If users wish to specify a custom one, they must do so each time they log in on every client. Once they have chosen an Identity Server to advertise their 3PIDs on, it would @@ -11,7 +11,7 @@ make this easier. ## Proposal The base URL of the Identity Server is to be stored in user account data. It -shall be stored in the same format as in a .well-known file under the key, +shall be stored in the same format as in a .well-known file under the event type `m.identity_server` and shall comprise a single key, `base_url` which is the base URL of the ID Server to use (that is, the part before `/_matrix`, including `https://`). @@ -33,7 +33,7 @@ which case they SHOULD continue to use the value they are currently using. Clients can offer a way for users to change the ID server being used. If they do, the client MUST update the value of `m.identity_server` accordingly. -The `m.identity_server` may be present with a value of `null`. In this case, +The `m.identity_server` may be present with a `base_url` of `null`. In this case, clients MUST treat this as no ID Server URL being set and not perform ID Server requests, disabling any functionality that requires such requests. From 1f8cfd57298f68837a315008f8e280eac23e75b4 Mon Sep 17 00:00:00 2001 From: David Baker Date: Wed, 21 Aug 2019 14:19:20 +0100 Subject: [PATCH 6/6] Update migration mechanism --- proposals/2230-identity-server-account-data.md | 16 ++++++---------- 1 file changed, 6 insertions(+), 10 deletions(-) diff --git a/proposals/2230-identity-server-account-data.md b/proposals/2230-identity-server-account-data.md index 98fcfbf11..19fb3062e 100644 --- a/proposals/2230-identity-server-account-data.md +++ b/proposals/2230-identity-server-account-data.md @@ -21,14 +21,11 @@ to the Identity Server until the account data has been fetched from the server. Once it has the account data, it SHOULD check for the presence of the `m.identity_server` key. If present, the `base_url` in this key SHOULD be used as the Identity Server base URL for the duration of the login session. If this -key is not present, the client SHOULD populate it with the ID Server URL -that was or would have been used in the login/registration process. This could -be either from user input, a .well-known lookup, or a default in the client. +key is not present, the client SHOULD use whatever value it would have used prior +to this MSC. It should not update the account data in this situation. Client SHOULD listen for changes in the `m.identity_server` account data value -and update the URL that they use for ID Server requests accordingly unless -the login session and choice of ID Server base URL predates this change, in -which case they SHOULD continue to use the value they are currently using. +and update the URL that they use for ID Server requests accordingly. Clients can offer a way for users to change the ID server being used. If they do, the client MUST update the value of `m.identity_server` accordingly. @@ -43,10 +40,9 @@ account data entry to `null`. ### Transition Period -Clients currently logged in with a value configured for the ID Server base -URL SHOULD use the value from `m.identity_server` if it exists or is created, -but otherwise continue to use the URL they had previously. They MUST NOT -populate the `m.identity_server` with their current ID Server base URL. +Clients will continue to use whatever IS URLs they currently use until the +user sets one explicitly, at which point it will be written to account data +and all clients will start using this value. ## Tradeoffs