archive
/
matrix-spec-proposals
mirror of https://github.com/matrix-org/matrix-spec-proposals
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

flesh out

Browse Source
pull/2229/head
Andrew Morgan 5 years ago
parent 783fd78a6f
commit ed4d805d2f
1 changed files with 57 additions and 89 deletions
Show Stats Download Patch File Download Diff File

146
proposals/xxxx-existing-3pid-allowed.md
Unescape Escape View File

@ -1,108 +1,76 @@
# Allowing 3PID Owners to Rebind
This is a proposal to allow 3PID owners to rebind their 3PIDs using the `POST
/_matrix/client/r0/account/3pid/email/requestToken` endpoint. The spec
currently states that if a user tries to call this endpoint with an email
address they already own, then the request should be rejected.
This MSC calls for those requests to be accepted iff the requesting user
currently has the 3PID bound to their Matrix ID, marking them as the user in
control of this 3PID.
This would allow users to bind their 3PIDs to different servers, even if the
homeserver has already been made aware of it.
--- TODO, below ---
3PID
noun
A third-party identifier such as an email address or phone number, that
can be tied to your Matrix ID in order for your contacts outside of
Matrix to find you, typically with the help of an [identity
server](https://matrix.org/docs/spec/identity_service/r0.2.1.html).
As part of the on-going privacy work, Matrix client applications are
attempting to make the concept of an identity server more clear to the user,
as well as allowing a user to interact with multiple identity servers while
they're logged in.
As part of facilitating this work, Matrix clients should be able to allow
users, while logged in, the ability to pick an identity server, see what
3PIDs they currently have bound to their Matrix ID, and bind/unbind 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
/_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)
line. The same goes for the [equivalent msisdn
endpoint](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-account-3pid-msisdn-requesttoken).
If a user binds their email address, through the homeserver to identity
server A, then switches to identity server B to try and do the same, the
homeserver will reject the second request as this email address has already
been bound. This is due to the homeserver attaching the email address user's
accounts whenever a bind is performed through them.
## Proposal
*Here is where you'll reinforce your position from the introduction in more detail, as well as cover
the technical points of your proposal. Including rationale for your proposed solution and detailing
why parts are important helps reviewers understand the problem at hand. Not including enough detail
can result in people guessing, leading to confusing arguments in the comments section. The example
here covers why templates are important again, giving a stronger argument as to why we should have
a template. Afterwards, it goes on to cover the specifics of what the template could look like.*
Having a default template that everyone can use is important. Without a template, proposals would be
all over the place and the minimum amount of detail may be left out. Introducing a template to the
proposal process helps ensure that some amount of consistency is present across multiple proposals,
even if each author decides to abandon the template.
This proposal calls for allowing 3PID owners to rebind their 3PIDs using 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) and [POST
/_matrix/client/r0/account/3pid/msisdn/requestToken](https://matrix.org/docs/spec/client_server/r0.5.0#post-matrix-client-r0-account-3pid-msisdn-requesttoken)
endpoints by extending the definition of what homeservers should check before rejecting a bind.
The default template should be a markdown document because the MSC process requires authors to write
a proposal in markdown. Using other formats wouldn't make much sense because that would prevent authors
from copy/pasting the template.
The template should have the following sections:
* **Introduction** - This should cover the primary problem and broad description of the solution.
* **Proposal** - The gory details of the proposal.
* **Tradeoffs** - Any items of the proposal that are less desirable should be listed here. Alternative
solutions to the same problem could also be listed here.
* **Potential issues** - This is where problems with the proposal would be listed, such as changes
that are not backwards compatible.
* **Security considerations** - Discussion of what steps were taken to avoid security issues in the
future and any potential risks in the proposal.
* **Conclusion** - A repeat of the problem and solution.
Furthermore, the template should not be required to be followed. However it is strongly recommended to
maintain some sense of consistency between proposals.
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 if they choose.
In doing so, it would allow users to bind their 3PIDs to multiple identity
servers, even if the homeserver has already been made aware of it.
## Tradeoffs
*This is where alternative solutions could be listed. There's almost always another way to do things
and this section gives you the opportunity to highlight why those ways are not as desirable. The
argument made in this example is that all of the text provided by the template could be integrated
into the proposals introduction, although with some risk of losing clarity.*
Instead of adding a template to the repository, the assistance it provides could be integrated into
the proposal process itself. There is an argument to be had that the proposal process should be as
descriptive as possible, although having even more detail in the proposals introduction could lead to
some confusion or lack of understanding. Not to mention if the document is too large then potential
authors could be scared off as the process suddenly looks a lot more complicated than it is. For those
reasons, this proposal does not consider integrating the template in the proposals introduction a good
idea.
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.
## Potential issues
*Not all proposals are perfect. Sometimes there's a known disadvantage to implementing the proposal,
and they should be documented here. There should be some explanation for why the disadvantage is
acceptable, however - just like in this example.*
Someone is going to have to spend the time to figure out what the template should actually have in it.
It could be a document with just a few headers or a supplementary document to the process explanation,
however more detail should be included. A template that actually proposes something should be considered
because it not only gives an opportunity to show what a basic proposal looks like, it also means that
explanations for each section can be described. Spending the time to work out the content of the template
is beneficial and not considered a significant problem because it will lead to a document that everyone
can follow.
Newer clients will expect homeservers to allow them to switch between
identity servers and bind/rebind emails as they please. If dealing with an
older homeserver, clients will receive an `HTTP 400 M_THREEPID_IN_USE`.
Clients should be prepared to understand that this may just mean they are
dealing with an old homeserver, versus the 3PID already being bound on this
homeserver by another user.
## Security considerations
*Some proposals may have some security aspect to them that was addressed in the proposed solution. This
section is a great place to outline some of the security-sensitive components of your proposal, such as
why a particular approach was (or wasn't) taken. The example here is a bit of a stretch and unlikely to
actually be worthwhile of including in a proposal, but it is generally a good idea to list these kinds
of concerns where possible.*
By having a template available, people would know what the desired detail for a proposal is. This is not
considered a risk because it is important that people understand the proposal process from start to end.
None.
## Conclusion
*Repeating the problem and solution in different words helps reviewers understand the problem a bit more.
This section should wrap up any loose ends left in the document, as well as cover a brief overview of the
content in each section. Note that the example here doesn't touch on the specific implementation details
described in the "Proposal" section - just the high-level points made there.*
Not having a template for people to follow when making their proposals could lead to large differences
between each MSC. This would make it difficult for reviewers, and there's a potential that some information
could be left out by accident. A template written in the same format the proposal process requires would
give authors the ability to understand how to better explain their own proposal.
A descriptive template would help potential authors comprehend what the proposal process requires by
demonstrating what is expected of a proposal. Although this is more effort up front, it would lead to more
time saved in the future due to questions about the process.
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.

Write Preview
Loading…
Cancel
Save