Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-28 22:14:10 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

Take into account the 1 is case

Browse source
This commit is contained in:
Andrew Morgan 2019-08-13 13:29:35 +01:00
parent f313b49c26
commit cb1e3b8373
1 changed files with 28 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

44
proposals/2229-rebind-existing-3pid.md
View file

@ -29,19 +29,28 @@ currently have bound to their Matrix ID, and bind/unbind addresses as they
desire. desire.
When implementating this functionality, a technicality in the spec was found When implementating this functionality, a technicality in the spec was found
to prevent the ability to bind the same 3PID to multiple identity servers. to prevent certain abilities for a user. A user could not add a 3PID to their
The line "The homeserver must check that the given email address is **not** homeserver before binding it to an identity server. It also prevents users
already associated with an account on this homeserver." appears under the from binding the same 3PID to multiple identity servers. The line "The
[POST 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) /_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 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). 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 When a user adds an email to their account on their homeserver, they can
homeserver keeps a record and attaches the address to the local account. choose to bind that email to an identity server at the same time. This is
Then, if the user switches to identity server B to try and do the same, the specified through a `bind` boolean. If the user first adds the 3PID with
homeserver will reject the second request as this address has already been `bind: false`, then decides they want to bind that 3PID to an identity server
bound. 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 ## 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 **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. 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 In doing so, users would be able to rebind their 3PIDs, even if the
servers, even if the homeserver has already been made aware of it. homeserver has already been made aware of it.
## Tradeoffs ## Tradeoffs
Identity servers will still let 3PIDs be rebound to another Matrix ID, while 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 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 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 ## Potential issues
@ -86,7 +96,9 @@ None.
## Conclusion ## Conclusion
By lifting the restriction of not allowing a user to bind a 3PID multiple 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 times, we allow the basic ability of publishing a 3PID after associating it
the same account. This not only allows the user to play around and gain a with an account, as well as allow users to interact with multiple identity
better understanding of the purpose of an identity server, but it is also one servers on the same account with the same 3PIDs. This not only allows the
step towards further decentralisation in the identity server space. 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.