Skip to content
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.

Sign up for GitHub

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

MSC4190: Device management for application services #4190

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

MSC4190: Device management for application services #4190

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
c7b4b0c
Device management for application services
sandhose Sep 12, 2024
4761dfc
Update the MSC number
sandhose Sep 12, 2024
791fbfa
Rename the unstable registration flag
sandhose Sep 12, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions proposals/4190-as-device-management.md
View file
Open in desktop
Copy link
Member

@turt2live turt2live Sep 12, 2024 •
edited by tulir
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Implementation requirements:

Edit: @anoadragon453 and @tulir have updated the above.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Appservice implementation: mautrix/go#288

Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
# 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.

### **`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.

### **`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`**
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should bump this to /v4 here as this is technically a backwards-incompatible change. Curious on your thoughts of whether that would be too impractical.

While the unstable io.element.msc4190 flag guards application services for now, it will disappear once this MSC is accepted.


This endpoint no longer generates a new access token, as if `inhibit_login` was set to `true` in the request by default.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This endpoint no longer generates a new access token, as if `inhibit_login` was set to `true` in the request by default.
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.


## 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.

## 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