Skip to content

Commit ebb7d20

Browse files
sandhosetulir
andauthored
MSC4190: Device management for application services (#4190)
Co-authored-by: Tulir Asokan <[email protected]>
1 parent 2b15b10 commit ebb7d20

File tree

1 file changed

+124
-0
lines changed

1 file changed

+124
-0
lines changed
Lines changed: 124 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,124 @@
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

Comments
 (0)