-
Notifications
You must be signed in to change notification settings - Fork 399
MSC4190: Device management for application services #4190
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.
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
base: main
Are you sure you want to change the base?
Changes from 5 commits
c7b4b0c
4761dfc
791fbfa
96ec9ba
cffcff9
ff0c786
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,88 @@ | ||
# MSC4190: Device management for application services | ||
|
||
[MSC3202] allows application services to handle and send encrypted events. | ||
One part of [MSC3202] is the ability to masquerade devices using the `device_id` | ||
query parameter on C-S API requests, which eliminates the need to maintain | ||
individual access tokens for each application service user. | ||
|
||
However, application services don't have an endpoint to create devices for their | ||
users, which means that, in practice, encrypted application services still use | ||
`/login` with the `m.login.application_service` login type to create devices for | ||
their users. | ||
|
||
Consequently, such application services leave many unused but active access | ||
tokens for those users. | ||
|
||
Furthermore, if [MSC3861] were adopted, the `/login` endpoint would no longer be | ||
available for application services to use. | ||
|
||
This MSC proposes a dedicated API endpoint for application services to create | ||
and delete devices for users, addressing the existing gap to enable encrypted | ||
application services without `/login`. | ||
|
||
## Proposal | ||
|
||
This MSC proposes to extend existing endpoints to allow application services to | ||
create and delete devices for their users without relying on the `/login` and | ||
`/logout` mechanisms. | ||
|
||
As all changes here only apply to application services, guest access is not | ||
relevant. | ||
|
||
### **`PUT /_matrix/client/v3/devices/{deviceId}`** | ||
|
||
This endpoint is updated to allow the creation of a new device for a user, if | ||
the device ID does not exist. This behavior is only available to application | ||
services. | ||
|
||
This endpoint will use the 201 status code to indicate that a new device was | ||
created, in addition to the existing 200 status code for existing devices. | ||
|
||
The endpoint is rate limited. Servers may want to use login rate limits for | ||
device creation, although in most cases application services will disable all | ||
rate limits anyway. | ||
|
||
### **`DELETE /_matrix/client/v3/devices/{deviceId}`** | ||
|
||
This endpoint no longer requires User-Interactive Authentication for application services. | ||
|
||
### **`POST /_matrix/client/v3/delete_devices`** | ||
|
||
This endpoint no longer requires User-Interactive Authentication for application services. | ||
|
||
### **`POST /_matrix/client/v3/register`** | ||
tulir marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
This endpoint no longer generates a new access token for application services, | ||
as if `inhibit_login` was set to `true` in the request by default. | ||
|
||
## Potential issues | ||
|
||
The change to `/v3/register` is technically backwards-incompatible. However, | ||
most application services likely ignore the returned access token, and next-gen | ||
auth will break the token generation anyway. It's better to stop returning a | ||
token than break the endpoint entirely by returning an error. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. An error would be preferred, as appservices which rely on the token will subtly break rather than a clear an obvious signal. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Updated to return an error with a new There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @turt2live are you happy to remove your concern on this now? |
||
|
||
## Security considerations | ||
|
||
This MSC lets application services delete devices without the usual | ||
re-authentication requirement. It is considered an acceptable risk, as | ||
application services have to be registered by the server admin. | ||
|
||
## Alternatives | ||
|
||
A new set of endpoints dedicated to application services could be added to the | ||
specification, like `GET|PUT|DELETE /_matrix/client/v3/appservices/{appId}/devices/{deviceId}`. | ||
|
||
This would have the advantage of not changing the behavior of existing endpoints. | ||
|
||
## Dependencies | ||
|
||
None. While this MSC is meant for next-gen auth, it can be used independently. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I just realized that this actually depends on MSC3202 for the device masquerading bits. Creating devices isn't very useful if you don't get a token and don't have any other way to use the device... 3202 might benefit from being split up so OTK count/device list/etc signaling is in one MSC and device masquerading is in another There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Splitting off the masquerading seems like a good idea to me. |
||
|
||
## Unstable prefix | ||
|
||
Until this MSC is stable, application services must opt-in to the new behavior | ||
by setting the `io.element.msc4190` flag to `true` in their registration file. | ||
|
||
[MSC3202]: https://github.com/matrix-org/matrix-spec-proposals/pull/3202 | ||
[MSC3861]: https://github.com/matrix-org/matrix-spec-proposals/pull/3861 |
Uh oh!
There was an error while loading. Please reload this page.