|
| 1 | +# MSC4190: Device management for application services |
| 2 | + |
| 3 | +[MSC4326] gives appservices the ability to masquerade devices using the |
| 4 | +`device_id` query parameter on C-S API requests, which eliminates the need to |
| 5 | +maintain individual access tokens for each application service user. |
| 6 | + |
| 7 | +However, application services don't have an endpoint to create devices for their |
| 8 | +users, which means that, in practice, encrypted application services still use |
| 9 | +`/login` with the `m.login.application_service` login type to create devices for |
| 10 | +their users. |
| 11 | + |
| 12 | +Consequently, such application services leave many unused but active access |
| 13 | +tokens for those users. |
| 14 | + |
| 15 | +Furthermore, the `/login` endpoint is no longer available for application services |
| 16 | +to use on servers that have switched to OAuth2 ([MSC3861]). |
| 17 | + |
| 18 | +This MSC proposes a dedicated API endpoint for application services to create |
| 19 | +and delete devices for users, addressing the existing gap to enable encrypted |
| 20 | +application services without `/login`. |
| 21 | + |
| 22 | +## Proposal |
| 23 | + |
| 24 | +This MSC proposes to extend existing endpoints to allow application services to |
| 25 | +create and delete devices for their users without relying on the `/login` and |
| 26 | +`/logout` mechanisms. |
| 27 | + |
| 28 | +As all changes here only apply to application services, guest access is not |
| 29 | +relevant. |
| 30 | + |
| 31 | +### [**`PUT /_matrix/client/v3/devices/{deviceId}`**](https://spec.matrix.org/v1.16/client-server-api/#put_matrixclientv3devicesdeviceid) |
| 32 | + |
| 33 | +This endpoint is updated to allow the creation of a new device for a user, if |
| 34 | +the device ID does not exist. This behavior is only available to application |
| 35 | +services. |
| 36 | + |
| 37 | +This endpoint will use the 201 status code to indicate that a new device was |
| 38 | +created, in addition to the existing 200 status code for existing devices. |
| 39 | + |
| 40 | +The endpoint is rate limited. Servers may want to use login rate limits for |
| 41 | +device creation, although in most cases application services will disable all |
| 42 | +rate limits anyway. |
| 43 | + |
| 44 | +### [**`DELETE /_matrix/client/v3/devices/{deviceId}`**](https://spec.matrix.org/v1.16/client-server-api/#delete_matrixclientv3devicesdeviceid) |
| 45 | + |
| 46 | +This endpoint no longer requires User-Interactive Authentication for application services. |
| 47 | + |
| 48 | +### [**`POST /_matrix/client/v3/delete_devices`**](https://spec.matrix.org/v1.16/client-server-api/#post_matrixclientv3delete_devices) |
| 49 | + |
| 50 | +This endpoint no longer requires User-Interactive Authentication for application services. |
| 51 | + |
| 52 | +### [**`POST /_matrix/client/v3/keys/device_signing/upload`**](https://spec.matrix.org/v1.16/client-server-api/#post_matrixclientv3keysdevice_signingupload) |
| 53 | + |
| 54 | +This endpoint no longer requires User-Interactive Authentication for application services, |
| 55 | +even if cross-signing keys already exist. |
| 56 | + |
| 57 | +This is not technically a part of device management, but appservices will need |
| 58 | +to be able to verify themselves including generating cross-signing keys for |
| 59 | +[MSC4153] and replacing cross-signing keys is necessary in some cases (e.g. if |
| 60 | +the appservice recovery key is misplaced). |
| 61 | + |
| 62 | +[MSC4153]: https://github.com/matrix-org/matrix-spec-proposals/pull/4153 |
| 63 | + |
| 64 | +### [**`POST /_matrix/client/v3/login`**](https://spec.matrix.org/v1.16/client-server-api/#post_matrixclientv3login) |
| 65 | + |
| 66 | +Logins with the [`m.login.application_service` type] will return HTTP 400 with a |
| 67 | +new `M_APPSERVICE_LOGIN_UNSUPPORTED` error code if the homeserver has switched |
| 68 | +to OAuth2. |
| 69 | + |
| 70 | +[`m.login.application_service` type]: https://spec.matrix.org/v1.16/client-server-api/#appservice-login |
| 71 | + |
| 72 | +### [**`POST /_matrix/client/v3/register`**](https://spec.matrix.org/v1.16/client-server-api/#post_matrixclientv3register) |
| 73 | + |
| 74 | +Currently, the default behavior for `/register` is to create a new device and |
| 75 | +access token (i.e. login) in addition to creating the user. Similar to `/login`, |
| 76 | +creating an access token is no longer possible on servers that have switched to |
| 77 | +OAuth2. However, creating users via the endpoint is still required, so unlike |
| 78 | +`/login`, `/register` will not be removed entirely. |
| 79 | + |
| 80 | +Therefore, application services on homeservers that have switched to OAuth2 |
| 81 | +MUST call the endpoint with `"inhibit_login": true`. Calls without the parameter, |
| 82 | +or with a different value than `true`, will return HTTP 400 with the |
| 83 | +`M_APPSERVICE_LOGIN_UNSUPPORTED` error code. |
| 84 | + |
| 85 | +## Potential issues |
| 86 | + |
| 87 | +The change to `/v3/register` is technically backwards-incompatible, but it will |
| 88 | +break when switching to next-gen auth in any case, so a new endpoint version |
| 89 | +would not be useful. |
| 90 | + |
| 91 | +The endpoint could just stop returning access tokens to avoid breaking existing |
| 92 | +appservices that don't read that field, but an explicit error was chosen to |
| 93 | +avoid silent breakage of appservices that do depend on the field. |
| 94 | + |
| 95 | +The breaking changes to `/login` and `/register` only apply to homeservers which |
| 96 | +have switched to OAuth2. Homeservers MAY have implementation-specific methods of |
| 97 | +opting into the breaking changes before switching to OAuth2 entirely to test |
| 98 | +compatibility. |
| 99 | + |
| 100 | +## Security considerations |
| 101 | + |
| 102 | +This MSC lets application services delete devices and replace cross-signing keys |
| 103 | +without the usual re-authentication requirement. It is considered an acceptable |
| 104 | +risk, as application services have to be registered by the server admin. |
| 105 | + |
| 106 | +## Alternatives |
| 107 | + |
| 108 | +A new set of endpoints dedicated to application services could be added to the |
| 109 | +specification, like `GET|PUT|DELETE /_matrix/client/v3/appservices/{appId}/devices/{deviceId}`. |
| 110 | + |
| 111 | +This would have the advantage of not changing the behavior of existing endpoints. |
| 112 | + |
| 113 | +## Dependencies |
| 114 | + |
| 115 | +In order to use the devices created using this MSC, appservices need to be able |
| 116 | +to use device IDs as a part of identity assertion, as defined by [MSC4326]. |
| 117 | + |
| 118 | +## Unstable prefix |
| 119 | + |
| 120 | +`IO.ELEMENT.MSC4190.M_APPSERVICE_LOGIN_UNSUPPORTED` should be used as the |
| 121 | +error code instead of `M_APPSERVICE_LOGIN_UNSUPPORTED`. |
| 122 | + |
| 123 | +[MSC4326]: https://github.com/matrix-org/matrix-spec-proposals/pull/4326 |
| 124 | +[MSC3861]: https://github.com/matrix-org/matrix-spec-proposals/pull/3861 |
0 commit comments