From 1d6501b6ecae194e5b105c513bb412548f1d0ab6 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Thu, 29 Aug 2019 13:51:38 -0600 Subject: [PATCH] What if we allowed homeservers to deal with their own business? --- proposals/0000-id_server-now-optional.md | 57 ++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 proposals/0000-id_server-now-optional.md diff --git a/proposals/0000-id_server-now-optional.md b/proposals/0000-id_server-now-optional.md new file mode 100644 index 00000000..a066cf6b --- /dev/null +++ b/proposals/0000-id_server-now-optional.md @@ -0,0 +1,57 @@ +# Proposal to make the `id_server` parameter on client-server APIs optional + +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](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. + +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.