From 783fd78a6f740b5dffc76184f1103f2d36a523ae Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Mon, 12 Aug 2019 17:13:37 +0100 Subject: [PATCH 01/11] wip --- proposals/xxxx-existing-3pid-allowed.md | 108 ++++++++++++++++++++++++ 1 file changed, 108 insertions(+) create mode 100644 proposals/xxxx-existing-3pid-allowed.md diff --git a/proposals/xxxx-existing-3pid-allowed.md b/proposals/xxxx-existing-3pid-allowed.md new file mode 100644 index 00000000..f3daa533 --- /dev/null +++ b/proposals/xxxx-existing-3pid-allowed.md @@ -0,0 +1,108 @@ +# 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 --- + +## 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. + +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. + + +## 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. + + +## 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. + + +## 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. + + +## 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. From ed4d805d2f087ba242969d3b561e7c5e2cb234e5 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 13 Aug 2019 11:11:22 +0100 Subject: [PATCH 02/11] flesh out --- proposals/xxxx-existing-3pid-allowed.md | 140 +++++++++--------------- 1 file changed, 54 insertions(+), 86 deletions(-) diff --git a/proposals/xxxx-existing-3pid-allowed.md b/proposals/xxxx-existing-3pid-allowed.md index f3daa533..c10eec27 100644 --- a/proposals/xxxx-existing-3pid-allowed.md +++ b/proposals/xxxx-existing-3pid-allowed.md @@ -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. +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). -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. +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. -This would allow users to bind their 3PIDs to different servers, even if the -homeserver has already been made aware of it. +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. ---- TODO, below --- +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.* +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. -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 -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. From 6ed0ae36badb5e978c6a8898d8bb058d1aa17263 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 13 Aug 2019 11:12:04 +0100 Subject: [PATCH 03/11] rename msc # --- ...xxxx-existing-3pid-allowed.md => 2229-rebind-existing-3pid.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename proposals/{xxxx-existing-3pid-allowed.md => 2229-rebind-existing-3pid.md} (100%) diff --git a/proposals/xxxx-existing-3pid-allowed.md b/proposals/2229-rebind-existing-3pid.md similarity index 100% rename from proposals/xxxx-existing-3pid-allowed.md rename to proposals/2229-rebind-existing-3pid.md From be77b5823c50808dd4545804fd66caaa29052460 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 13 Aug 2019 11:24:37 +0100 Subject: [PATCH 04/11] fix up --- proposals/2229-rebind-existing-3pid.md | 48 ++++++++++++++++---------- 1 file changed, 29 insertions(+), 19 deletions(-) diff --git a/proposals/2229-rebind-existing-3pid.md b/proposals/2229-rebind-existing-3pid.md index c10eec27..ce2547e2 100644 --- a/proposals/2229-rebind-existing-3pid.md +++ b/proposals/2229-rebind-existing-3pid.md @@ -1,20 +1,25 @@ # Allowing 3PID Owners to Rebind +``` 3PID noun - A third-party identifier such as an email address or phone number, that + + 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). + Matrix to find you, typically with the help of an identity server. + +Identity server + noun + + A queryable server that holds mappings between 3PIDs and Matrix IDs. +``` 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 +attempting to make the concept of an identity server clearer to the user, as +well as allowing a user to interact with multiple identity servers while +logged in. In facilitating this, Matrix clients should be able to allow +logged-in users the ability to pick an identity server, see what 3PIDs they +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 @@ -23,14 +28,14 @@ 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 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). -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. +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. ## Proposal @@ -38,13 +43,14 @@ 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. +endpoints by extending the definition of what homeservers should check before +rejecting a bind. 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. +so, then they should be able to bind it again and again if they so choose. -In doing so, it would allow users to bind their 3PIDs to multiple identity +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. ## Tradeoffs @@ -63,6 +69,10 @@ 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. +Homeservers will need to keep track of each identity server that an address +has been bound with, and upon user account deactivation, should attempt to +unbind all of them. + ## Security considerations None. From f313b49c2652f3ad13cab6d51098db5e5f4a83b3 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 13 Aug 2019 11:40:34 +0100 Subject: [PATCH 05/11] Add bind def. --- proposals/2229-rebind-existing-3pid.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/proposals/2229-rebind-existing-3pid.md b/proposals/2229-rebind-existing-3pid.md index ce2547e2..11b2e370 100644 --- a/proposals/2229-rebind-existing-3pid.md +++ b/proposals/2229-rebind-existing-3pid.md @@ -12,6 +12,12 @@ Identity server noun A queryable server that holds mappings between 3PIDs and Matrix IDs. + +Bind + verb + + Create a mapping between a 3PID and a Matrix ID. Useful for people to + find a user based on their existing third-party contact information. ``` As part of the on-going privacy work, Matrix client applications are From cb1e3b8373d04d2b2e9ca659d2517299027335af Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 13 Aug 2019 13:29:35 +0100 Subject: [PATCH 06/11] 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. From 5b1ea4ffcb9db8e721c630d3740d6103fee6de15 Mon Sep 17 00:00:00 2001 From: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> Date: Tue, 13 Aug 2019 17:13:48 +0100 Subject: [PATCH 07/11] Update proposals/2229-rebind-existing-3pid.md Co-Authored-By: J. Ryan Stinnett --- proposals/2229-rebind-existing-3pid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2229-rebind-existing-3pid.md b/proposals/2229-rebind-existing-3pid.md index ce658121..dd89ecc3 100644 --- a/proposals/2229-rebind-existing-3pid.md +++ b/proposals/2229-rebind-existing-3pid.md @@ -43,7 +43,7 @@ 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 +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 From 01fc54faaeb353f5b0084d9f0d4ddb1e28fe60ae Mon Sep 17 00:00:00 2001 From: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> Date: Tue, 13 Aug 2019 17:15:48 +0100 Subject: [PATCH 08/11] Update proposals/2229-rebind-existing-3pid.md Co-Authored-By: Travis Ralston --- proposals/2229-rebind-existing-3pid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2229-rebind-existing-3pid.md b/proposals/2229-rebind-existing-3pid.md index dd89ecc3..276e45c5 100644 --- a/proposals/2229-rebind-existing-3pid.md +++ b/proposals/2229-rebind-existing-3pid.md @@ -61,7 +61,7 @@ This proposal calls for allowing 3PID owners to rebind their 3PIDs using the endpoints by extending the definition of what homeservers should check before rejecting a bind. -Homeservers should reject the binding of a 3PID if it already been bound, +Homeservers should reject the binding of a 3PID if it has 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. From 2547cc443c9b3de68fee289139f95884a645c005 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 13 Aug 2019 17:17:06 +0100 Subject: [PATCH 09/11] backticks --- proposals/2229-rebind-existing-3pid.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/proposals/2229-rebind-existing-3pid.md b/proposals/2229-rebind-existing-3pid.md index ce658121..9854d7d9 100644 --- a/proposals/2229-rebind-existing-3pid.md +++ b/proposals/2229-rebind-existing-3pid.md @@ -55,9 +55,10 @@ request as this address has already been bound. ## Proposal 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) +[`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. From 7758e0701cb4535af50586fb0b8c31608ce03c03 Mon Sep 17 00:00:00 2001 From: Andrew Morgan Date: Tue, 13 Aug 2019 18:22:06 +0100 Subject: [PATCH 10/11] Remove homeserver warning --- proposals/2229-rebind-existing-3pid.md | 4 ---- 1 file changed, 4 deletions(-) diff --git a/proposals/2229-rebind-existing-3pid.md b/proposals/2229-rebind-existing-3pid.md index 6cd1d155..bd765a5e 100644 --- a/proposals/2229-rebind-existing-3pid.md +++ b/proposals/2229-rebind-existing-3pid.md @@ -86,10 +86,6 @@ 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. -Homeservers will need to keep track of each identity server that an address -has been bound with, and upon user account deactivation, should attempt to -unbind all of them. - ## Security considerations None. From 4059661c29b15c6bc04cdebcdb6c5deb477910ac Mon Sep 17 00:00:00 2001 From: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com> Date: Wed, 14 Aug 2019 11:38:53 +0100 Subject: [PATCH 11/11] Update proposals/2229-rebind-existing-3pid.md Co-Authored-By: Kitsune Ral --- proposals/2229-rebind-existing-3pid.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/2229-rebind-existing-3pid.md b/proposals/2229-rebind-existing-3pid.md index bd765a5e..83883c78 100644 --- a/proposals/2229-rebind-existing-3pid.md +++ b/proposals/2229-rebind-existing-3pid.md @@ -28,7 +28,7 @@ logged-in users the ability to pick an identity server, see what 3PIDs they 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 +When implementing this functionality, a technicality in the spec was found 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