Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets #2263

Merged
merged 6 commits into from
Sep 4, 2019
Merged

MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets #2263

Changes from 5 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
1d6501b
What if we allowed homeservers to deal with their own business?
turt2live Aug 29, 2019
4e43024
Assign number
turt2live Aug 29, 2019
6d5e90b
Apply suggestions from code review
turt2live Aug 29, 2019
1a6eb9a
Update proposals/2263-homeserver-pw-resets.md
turt2live Aug 29, 2019
9f41ae5
let's try and fix the CI
turt2live Aug 30, 2019
b36fe24
Let's not doubly remove things
turt2live Aug 30, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 57 additions & 0 deletions proposals/2263-homeserver-pw-resets.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,57 @@
# MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets

In order to better protect the privacy of a user, Matrix is wanting to shift to
a model where identity servers have less control over the affairs of the homeserver.
Identity servers are currently used to reset the passwords of users on a given homeserver
as an identity verification technique, however there is no reason why the homeserver
itself can't handle the verification. This proposal allows for a homeserver to verify
the identity of users itself, without the use of an identity server.

## Proposal

The `id_server` parameter is to become optional on the following endpoints:

* `/_matrix/client/:version/account/3pid/:medium/requestToken`
* `/_matrix/client/:version/register/:medium/requestToken`
* `/_matrix/client/:version/account/password/:medium/requestToken`

The `id_server` parameter is additionally deprecated with intention of being removed
in a future specification release on the `/register/:medium` and `/account/password/:medium`
endpoints. Once appropriate adoption has been achieved, the specification can safely
remove the parameter as supported. The reason for this deprecation is to completely
remove the identity server's ability to be involved in password resets/registration.
Users wishing to bind their 3rd party identifiers can do so after registration, and
clients can automate this if they so desire.

Similarly, `bind_email` and `bind_msisdn` are deprecated with intention to be removed
turt2live marked this conversation as resolved.
Show resolved Hide resolved
in a future specification version on `/register`. The flags have no effect if no `id_server`
is being used.

As per [MSC2140](https://github.com/matrix-org/matrix-doc/pull/2140), an `id_access_token`
is required only if an `id_server` is supplied.

Although not specified as required in the specification currently, the `id_server`
as part of User-Interactive Authentication is also optional if this proposal is accepted.
When the client requests a token without an `id_server`, it should not specify an
`id_server` in UIA.

Homeservers can reuse HTTP 400 `M_SERVER_NOT_TRUSTED` as an error code on the `/requestToken`
endpoints listed above if they do not trust the identity server the user is supplying.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could see this being useful if someone tries to set "http://127.0.0.1" as their id_server.


In order to allow client implementations to determine if the homeserver they are developed
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be "... to determine if the homeserver they are using supports id_server being optional, ..." (or maybe "connected to") rather than "developed against"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not really, because the flag has an expected timeline for death. Once the MSC lands in the spec, the flag is irrelevant. It's only useful to those writing implementations which are likely to ship the feature in some capacity before the spec releases it.

against supports `id_server` being optional, an unstable feature flag of `m.require_identity_server`
anoadragon453 marked this conversation as resolved.
Show resolved Hide resolved
is to be added to `/versions`. When the flag is `true` or not present, clients must assume
that the homeserver requires an `id_server` (ie: it has not yet considered it optional).
If this proposal is accepted, clients are expected to use the supported specification versions
the homeserver advertises instead of the feature flag's presence.

## Tradeoffs

Homeservers may have to set up MSISDN/email support to their implementations. This is believed
to be of minimal risk compared to allowing the identity server to continue being involved
with password reset/registration.

## Security considerations

The identity server was previously involved with affairs only the homeserver cares about.
This is no longer the case.