3.1 KiB
MSC2263: Give homeservers the ability to handle their own 3PID registrations/password resets
In order to better protect the privacy of 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 intentions 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 intentions to be removed
in a future specification version on /register. The flags have no effect if no id_server
is being used.
As per MSC2140, 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.
In order to allow client implementations to determine if the homeserver they are developed
against supports id_server being optional, an unstable feature flag of m.require_identity_server
is to be added to /versions. When the flag is false 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.