From cb1e3b8373d04d2b2e9ca659d2517299027335af Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 13 Aug 2019 13:29:35 +0100 Subject: [PATCH] Take into account the 1 is case --- proposals/2229-rebind-existing-3pid.md | 44 ++++++++++++++++---------- 1 file changed, 28 insertions(+), 16 deletions(-) diff --git a/proposals/2229-rebind-existing-3pid.md b/proposals/2229-rebind-existing-3pid.md index 11b2e370..ce658121 100644 --- a/proposals/2229-rebind-existing-3pid.md +++ b/proposals/2229-rebind-existing-3pid.md @@ -29,19 +29,28 @@ currently have bound to their Matrix ID, and bind/unbind addresses as they desire. When implementating this functionality, a technicality in the spec was found -to prevent the ability to bind the same 3PID to multiple identity servers. -The line "The homeserver must check that the given email address is **not** -already associated with an account on this homeserver." appears under the -[POST +to prevent certain abilities for a user. A user could not add a 3PID to their +homeserver before binding it to an identity server. It also prevents users +from binding the same 3PID to multiple identity servers. The line "The +homeserver must check that the given email address is **not** already +associated with an account on this homeserver." appears under the [POST /_matrix/client/r0/account/3pid/email/requestToken](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-account-3pid-email-requesttoken) endpoint description. The same goes for the [equivalent msisdn (phone) endpoint](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-account-3pid-msisdn-requesttoken). -When a user binds their 3PID through a homeserver to identity server A, the -homeserver keeps a record and attaches the address to the local account. -Then, if the user switches to identity server B to try and do the same, the -homeserver will reject the second request as this address has already been -bound. +When a user adds an email to their account on their homeserver, they can +choose to bind that email to an identity server at the same time. This is +specified through a `bind` boolean. If the user first adds the 3PID with +`bind: false`, then decides they want to bind that 3PID to an identity server +to make themselves discoverable by it, by making another request with `bind: +true`. The homeserver will reject the second request, because this 3PID is +already tied to the user's account. + +Similarly, when a user initially sends their 3PID with `bind: true` through a +homeserver to identity server A, the homeserver keeps a record and attaches +the address to the local account. If the user then switches to identity +server B to try and do the same, the homeserver will reject the second +request as this address has already been bound. ## Proposal @@ -56,15 +65,16 @@ Homeservers should reject the binding of a 3PID if it already been bound, **unless** the requesting user is the one who originally bound that 3PID. If so, then they should be able to bind it again and again if they so choose. -In doing so, users would be able to bind their 3PIDs to multiple identity -servers, even if the homeserver has already been made aware of it. +In doing so, users would be able to rebind their 3PIDs, even if the +homeserver has already been made aware of it. ## Tradeoffs Identity servers will still let 3PIDs be rebound to another Matrix ID, while a single homeserver won't let a 3PID transition between two users. If one thinks about typical internet services however, you aren't allowed to simply -take an email address from another account even if you have control of it. +take an email address from another account even if you have control of it, so +this shouldn't be too unintuitive. ## Potential issues @@ -86,7 +96,9 @@ None. ## Conclusion By lifting the restriction of not allowing a user to bind a 3PID multiple -times, we unlock the ability to interact with multiple identity servers on -the same account. This not only allows the user to play around and gain a -better understanding of the purpose of an identity server, but it is also one -step towards further decentralisation in the identity server space. +times, we allow the basic ability of publishing a 3PID after associating it +with an account, as well as allow users to interact with multiple identity +servers on the same account with the same 3PIDs. This not only allows the +user to play around and gain a better understanding of the purpose of an +identity server, but it is also one step towards further decentralisation in +the identity server space.