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

flesh out

Browse Source
pull/977/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 # Allowing 3PID Owners to Rebind
This is a proposal to allow 3PID owners to rebind their 3PIDs using the `POST 3PID
/_matrix/client/r0/account/3pid/email/requestToken` endpoint. The spec noun
currently states that if a user tries to call this endpoint with an email A third-party identifier such as an email address or phone number, that
address they already own, then the request should be rejected. 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
This MSC calls for those requests to be accepted iff the requesting user server](https://matrix.org/docs/spec/identity_service/r0.2.1.html).
currently has the 3PID bound to their Matrix ID, marking them as the user in
control of this 3PID. 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,
This would allow users to bind their 3PIDs to different servers, even if the as well as allowing a user to interact with multiple identity servers while
homeserver has already been made aware of it. they're logged in.
--- TODO, below --- 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 ## Proposal
*Here is where you'll reinforce your position from the introduction in more detail, as well as cover This proposal calls for allowing 3PID owners to rebind their 3PIDs using the
the technical points of your proposal. Including rationale for your proposed solution and detailing [POST
why parts are important helps reviewers understand the problem at hand. Not including enough detail /_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
can result in people guessing, leading to confusing arguments in the comments section. The example /_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)
here covers why templates are important again, giving a stronger argument as to why we should have endpoints by extending the definition of what homeservers should check before rejecting a bind.
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.
The default template should be a markdown document because the MSC process requires authors to write Homeservers should reject the binding of a 3PID if it already been bound,
a proposal in markdown. Using other formats wouldn't make much sense because that would prevent authors **unless** the requesting user is the one who originally bound that 3PID. If
from copy/pasting the template. so, then they should be able to bind it again if they choose.
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.
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 ## Tradeoffs
*This is where alternative solutions could be listed. There's almost always another way to do things Identity servers will still let 3PIDs be rebound to another Matrix ID, while
and this section gives you the opportunity to highlight why those ways are not as desirable. The a single homeserver won't let a 3PID transition between two users. If one
argument made in this example is that all of the text provided by the template could be integrated thinks about typical internet services however, you aren't allowed to simply
into the proposals introduction, although with some risk of losing clarity.* take an email address from another account even if you have control of it.
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.
## Potential issues ## Potential issues
*Not all proposals are perfect. Sometimes there's a known disadvantage to implementing the proposal, Newer clients will expect homeservers to allow them to switch between
and they should be documented here. There should be some explanation for why the disadvantage is identity servers and bind/rebind emails as they please. If dealing with an
acceptable, however - just like in this example.* 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
Someone is going to have to spend the time to figure out what the template should actually have in it. dealing with an old homeserver, versus the 3PID already being bound on this
It could be a document with just a few headers or a supplementary document to the process explanation, homeserver by another user.
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.
## Security considerations ## Security considerations
*Some proposals may have some security aspect to them that was addressed in the proposed solution. This None.
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.
## Conclusion ## Conclusion
*Repeating the problem and solution in different words helps reviewers understand the problem a bit more. By lifting the restriction of not allowing a user to bind a 3PID multiple
This section should wrap up any loose ends left in the document, as well as cover a brief overview of the times, we unlock the ability to interact with multiple identity servers on
content in each section. Note that the example here doesn't touch on the specific implementation details the same account. This not only allows the user to play around and gain a
described in the "Proposal" section - just the high-level points made there.* better understanding of the purpose of an identity server, but it is also one
step towards further decentralisation in the identity server space.
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.

Write Preview
Loading…
Cancel
Save