From c7b4b0c7819887c1cfa1e5cd896069fb872545d5 Mon Sep 17 00:00:00 2001 From: Quentin Gliech Date: Thu, 12 Sep 2024 13:34:32 +0200 Subject: [PATCH 01/14] Device management for application services --- proposals/4190-as-device-management.md | 48 ++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 proposals/4190-as-device-management.md diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md new file mode 100644 index 00000000000..22a0ddfa1e6 --- /dev/null +++ b/proposals/4190-as-device-management.md @@ -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`** + +This endpoint no longer generates a new access token, 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 `mscxxx_device_management` 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 From 4761dfc4a51e4e81e31bf374c1d62a9ab5661a27 Mon Sep 17 00:00:00 2001 From: Quentin Gliech Date: Thu, 12 Sep 2024 13:37:21 +0200 Subject: [PATCH 02/14] Update the MSC number --- proposals/4190-as-device-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index 22a0ddfa1e6..ef927968e4d 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -42,7 +42,7 @@ 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 `mscxxx_device_management` flag to `true` in their registration file. +Until this MSC is stable, application services must opt-in to the new behavior by setting the `msc4190_device_management` 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 From 791fbfacf4a07233664d97ed865a9c2e50012eb3 Mon Sep 17 00:00:00 2001 From: Quentin Gliech Date: Thu, 12 Sep 2024 14:02:14 +0200 Subject: [PATCH 03/14] Rename the unstable registration flag --- proposals/4190-as-device-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index ef927968e4d..de2214fba55 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -42,7 +42,7 @@ 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 `msc4190_device_management` flag to `true` in their registration file. +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 From 96ec9ba062a1af641dc866eff806d29255f6e43b Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 5 Apr 2025 16:39:57 +0300 Subject: [PATCH 04/14] Wrap lines --- proposals/4190-as-device-management.md | 40 ++++++++++++++++++-------- 1 file changed, 28 insertions(+), 12 deletions(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index de2214fba55..a75f14eb3dc 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -1,26 +1,39 @@ # 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. +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. +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. +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. +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`. +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. +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 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. +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}`** @@ -32,17 +45,20 @@ This endpoint no longer requires User-Interactive Authentication for application ### **`POST /_matrix/client/v3/register`** -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, 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}`. +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. +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 From cffcff9ce51b93dd707ff03d877a57706ce36fef Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 5 Apr 2025 16:52:10 +0300 Subject: [PATCH 05/14] Add words to cover checklist and /register breaking change --- proposals/4190-as-device-management.md | 28 ++++++++++++++++++++++++-- 1 file changed, 26 insertions(+), 2 deletions(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index a75f14eb3dc..e3b5b147472 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -26,6 +26,9 @@ 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 @@ -35,6 +38,10 @@ 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. @@ -45,8 +52,21 @@ This endpoint no longer requires User-Interactive Authentication for application ### **`POST /_matrix/client/v3/register`** -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. + +## 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. + +## 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 @@ -55,6 +75,10 @@ specification, like `GET|PUT|DELETE /_matrix/client/v3/appservices/{appId}/devic 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. + ## Unstable prefix Until this MSC is stable, application services must opt-in to the new behavior From ff0c786190a31feb96fef97ae3a80e7485a6d749 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sat, 5 Apr 2025 21:58:25 +0300 Subject: [PATCH 06/14] Return an error in /register --- proposals/4190-as-device-management.md | 17 +++++++++++------ 1 file changed, 11 insertions(+), 6 deletions(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index e3b5b147472..639fcf56cea 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -52,15 +52,20 @@ This endpoint no longer requires User-Interactive Authentication for application ### **`POST /_matrix/client/v3/register`** -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. +Application services will no longer receive access tokens or device IDs and +MUST call the endpoint with `inhibit_login=true`. Calls without the parameter, +or with a different value than `true`, will return HTTP 400 with a new +`M_APPSERVICE_LOGIN_UNSUPPORTED` error code. ## 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. +The change to `/v3/register` is technically backwards-incompatible, but it will +break when switching to next-gen auth in any case, so a new endpoint version +would not be useful. + +The endpoint could just stop returning access tokens to avoid breaking existing +appservices that don't read that field, but an explicit error was chosen to +avoid silent breakage of appservices that do depend on the field. ## Security considerations From ed1ec8071a2c78b47319c94a817634612a6ba025 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Wed, 25 Jun 2025 14:53:18 +0200 Subject: [PATCH 07/14] Clarify why /register is changing --- proposals/4190-as-device-management.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index 639fcf56cea..e8fe2e73c4b 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -52,10 +52,15 @@ This endpoint no longer requires User-Interactive Authentication for application ### **`POST /_matrix/client/v3/register`** -Application services will no longer receive access tokens or device IDs and -MUST call the endpoint with `inhibit_login=true`. Calls without the parameter, -or with a different value than `true`, will return HTTP 400 with a new -`M_APPSERVICE_LOGIN_UNSUPPORTED` error code. +Currently, the default behavior for `/register` is to create a new device and +access token (i.e. login) in addition to creating the user. Similar to `/login`, +creating an access token would no longer be possible with [MSC3861]. However, +creating users via the endpoint is still required, so unlike `/login`, `/register` +will not be removed entirely. + +Therefore, application services MUST call the endpoint with `inhibit_login=true`. +Calls without the parameter, or with a different value than `true`, will return +HTTP 400 with a new `M_APPSERVICE_LOGIN_UNSUPPORTED` error code. ## Potential issues From e66f4d2bd86ac4da99b7ecd0cf5ad25270abb7cd Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Tue, 8 Jul 2025 11:21:16 +0300 Subject: [PATCH 08/14] Declare MSC3202 dependency --- proposals/4190-as-device-management.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index e8fe2e73c4b..1be5e8d2f51 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -87,7 +87,8 @@ 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. +In order to use the devices created using this MSC, appservices need to be able +to use device IDs as a part of identity assertion, as defined by [MSC3202]. ## Unstable prefix From 2be916107ed383251212e7e7c8e8098414eb9435 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Tue, 12 Aug 2025 10:17:48 +0300 Subject: [PATCH 09/14] Point to new MSC for device ID masquerading --- proposals/4190-as-device-management.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index 1be5e8d2f51..06b5a6abe1a 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -88,12 +88,12 @@ This would have the advantage of not changing the behavior of existing endpoints ## Dependencies In order to use the devices created using this MSC, appservices need to be able -to use device IDs as a part of identity assertion, as defined by [MSC3202]. +to use device IDs as a part of identity assertion, as defined by [MSC4326]. ## 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 +[MSC4326]: https://github.com/matrix-org/matrix-spec-proposals/pull/4326 [MSC3861]: https://github.com/matrix-org/matrix-spec-proposals/pull/3861 From 6692db9ab3d9e0654b215ee8c50947ec85e6caa0 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 21 Sep 2025 14:52:49 +0300 Subject: [PATCH 10/14] Reword as OAuth is in the spec, require registration flag after this MSC is accepted --- proposals/4190-as-device-management.md | 45 ++++++++++++++++++-------- 1 file changed, 31 insertions(+), 14 deletions(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index 06b5a6abe1a..b66d98db195 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -1,9 +1,8 @@ # 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. +[MSC4326] gives appservices 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 @@ -13,8 +12,8 @@ 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. +Furthermore, the `/login` endpoint is longer available for application services +to use on servers that have switched to OAuth2 ([MSC3861]). This MSC proposes a dedicated API endpoint for application services to create and delete devices for users, addressing the existing gap to enable encrypted @@ -29,6 +28,11 @@ create and delete devices for their users without relying on the `/login` and As all changes here only apply to application services, guest access is not relevant. +To opt into this new behavior, the appservice registration has a new +`device_management: true` flag. However, if the homeserver has switched to +OAuth2, it MUST treat all appservices as having the flag enabled, as the old +login methods will not work in any case. + ### **`PUT /_matrix/client/v3/devices/{deviceId}`** This endpoint is updated to allow the creation of a new device for a user, if @@ -50,17 +54,24 @@ This endpoint no longer requires User-Interactive Authentication for application This endpoint no longer requires User-Interactive Authentication for application services. +### **`POST /_matrix/client/v3/login`** + +Logins with the `m.login.application_service` type will return HTTP 400 with a +new `M_APPSERVICE_LOGIN_UNSUPPORTED` error code if the appservice has opted into +this MSC. + ### **`POST /_matrix/client/v3/register`** Currently, the default behavior for `/register` is to create a new device and access token (i.e. login) in addition to creating the user. Similar to `/login`, -creating an access token would no longer be possible with [MSC3861]. However, -creating users via the endpoint is still required, so unlike `/login`, `/register` -will not be removed entirely. +creating an access token is no longer possible on servers that have switched to +OAuth2. However, creating users via the endpoint is still required, so unlike +`/login`, `/register` will not be removed entirely. -Therefore, application services MUST call the endpoint with `inhibit_login=true`. -Calls without the parameter, or with a different value than `true`, will return -HTTP 400 with a new `M_APPSERVICE_LOGIN_UNSUPPORTED` error code. +Therefore, application services that have opted into this MSC MUST call the +endpoint with `inhibit_login=true`. Calls without the parameter, or with a +different value than `true`, will return HTTP 400 with the +`M_APPSERVICE_LOGIN_UNSUPPORTED` error code. ## Potential issues @@ -72,6 +83,9 @@ The endpoint could just stop returning access tokens to avoid breaking existing appservices that don't read that field, but an explicit error was chosen to avoid silent breakage of appservices that do depend on the field. +The opt-in registration flag allows all old appservices to keep working until +a server switches to OAuth2 entirely. + ## Security considerations This MSC lets application services delete devices without the usual @@ -92,8 +106,11 @@ to use device IDs as a part of identity assertion, as defined by [MSC4326]. ## 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. +Until this MSC is stable, the opt-in flag in the registration file is +`io.element.msc4190` instead of `device_management`. + +Also, `IO.ELEMENT.MSC4190.M_APPSERVICE_LOGIN_UNSUPPORTED` should be used as the +error code instead of `M_APPSERVICE_LOGIN_UNSUPPORTED`. [MSC4326]: https://github.com/matrix-org/matrix-spec-proposals/pull/4326 [MSC3861]: https://github.com/matrix-org/matrix-spec-proposals/pull/3861 From f9bac035ca1893ee2ec82f95bbc489764601bbf9 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 21 Sep 2025 14:53:04 +0300 Subject: [PATCH 11/14] Remove UIA requirement for cross-signing reset --- proposals/4190-as-device-management.md | 18 +++++++++++++++--- 1 file changed, 15 insertions(+), 3 deletions(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index b66d98db195..b5cf8cf640e 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -54,6 +54,18 @@ This endpoint no longer requires User-Interactive Authentication for application This endpoint no longer requires User-Interactive Authentication for application services. +### **`POST /_matrix/client/v3/keys/device_signing/upload`** + +This endpoint no longer requires User-Interactive Authentication for application services, +even if cross-signing keys already exist. + +This is not technically a part of device management, but appservices will need +to be able to verify themselves including generating cross-signing keys for +[MSC4153] and replacing cross-signing keys is necessary in some cases (e.g. if +the appservice recovery key is misplaced). + +[MSC4153]: https://github.com/matrix-org/matrix-spec-proposals/pull/4153 + ### **`POST /_matrix/client/v3/login`** Logins with the `m.login.application_service` type will return HTTP 400 with a @@ -88,9 +100,9 @@ a server switches to OAuth2 entirely. ## 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. +This MSC lets application services delete devices and replace cross-signing keys +without the usual re-authentication requirement. It is considered an acceptable +risk, as application services have to be registered by the server admin. ## Alternatives From e917c450f317d69e9a2aad60415821f31d2c6df6 Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Sun, 21 Sep 2025 15:01:04 +0300 Subject: [PATCH 12/14] Link to existing specs --- proposals/4190-as-device-management.md | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index b5cf8cf640e..533d917cc1c 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -33,7 +33,7 @@ To opt into this new behavior, the appservice registration has a new OAuth2, it MUST treat all appservices as having the flag enabled, as the old login methods will not work in any case. -### **`PUT /_matrix/client/v3/devices/{deviceId}`** +### [**`PUT /_matrix/client/v3/devices/{deviceId}`**](https://spec.matrix.org/v1.16/client-server-api/#put_matrixclientv3devicesdeviceid) 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 @@ -46,15 +46,15 @@ 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}`** +### [**`DELETE /_matrix/client/v3/devices/{deviceId}`**](https://spec.matrix.org/v1.16/client-server-api/#delete_matrixclientv3devicesdeviceid) This endpoint no longer requires User-Interactive Authentication for application services. -### **`POST /_matrix/client/v3/delete_devices`** +### [**`POST /_matrix/client/v3/delete_devices`**](https://spec.matrix.org/v1.16/client-server-api/#post_matrixclientv3delete_devices) This endpoint no longer requires User-Interactive Authentication for application services. -### **`POST /_matrix/client/v3/keys/device_signing/upload`** +### [**`POST /_matrix/client/v3/keys/device_signing/upload`**](https://spec.matrix.org/v1.16/client-server-api/#post_matrixclientv3keysdevice_signingupload) This endpoint no longer requires User-Interactive Authentication for application services, even if cross-signing keys already exist. @@ -66,13 +66,15 @@ the appservice recovery key is misplaced). [MSC4153]: https://github.com/matrix-org/matrix-spec-proposals/pull/4153 -### **`POST /_matrix/client/v3/login`** +### [**`POST /_matrix/client/v3/login`**](https://spec.matrix.org/v1.16/client-server-api/#post_matrixclientv3login) -Logins with the `m.login.application_service` type will return HTTP 400 with a +Logins with the [`m.login.application_service` type] will return HTTP 400 with a new `M_APPSERVICE_LOGIN_UNSUPPORTED` error code if the appservice has opted into this MSC. -### **`POST /_matrix/client/v3/register`** +[`m.login.application_service` type]: https://spec.matrix.org/v1.16/client-server-api/#appservice-login + +### [**`POST /_matrix/client/v3/register`**](https://spec.matrix.org/v1.16/client-server-api/#post_matrixclientv3register) Currently, the default behavior for `/register` is to create a new device and access token (i.e. login) in addition to creating the user. Similar to `/login`, From 0f58c035520ba3eec6ee1bb4029234eb4a5b67bd Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Tue, 7 Oct 2025 19:03:21 +0300 Subject: [PATCH 13/14] Fix typo Co-authored-by: Andrew Ferrazzutti --- proposals/4190-as-device-management.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index 533d917cc1c..af2eab3ca91 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -12,7 +12,7 @@ their users. Consequently, such application services leave many unused but active access tokens for those users. -Furthermore, the `/login` endpoint is longer available for application services +Furthermore, the `/login` endpoint is no longer available for application services to use on servers that have switched to OAuth2 ([MSC3861]). This MSC proposes a dedicated API endpoint for application services to create From ab1060479fafef597384fee8fa3c1bff2f5031bf Mon Sep 17 00:00:00 2001 From: Tulir Asokan Date: Wed, 8 Oct 2025 14:49:21 +0300 Subject: [PATCH 14/14] Remove opt-in --- proposals/4190-as-device-management.md | 26 ++++++++++---------------- 1 file changed, 10 insertions(+), 16 deletions(-) diff --git a/proposals/4190-as-device-management.md b/proposals/4190-as-device-management.md index af2eab3ca91..282599ddb5e 100644 --- a/proposals/4190-as-device-management.md +++ b/proposals/4190-as-device-management.md @@ -28,11 +28,6 @@ create and delete devices for their users without relying on the `/login` and As all changes here only apply to application services, guest access is not relevant. -To opt into this new behavior, the appservice registration has a new -`device_management: true` flag. However, if the homeserver has switched to -OAuth2, it MUST treat all appservices as having the flag enabled, as the old -login methods will not work in any case. - ### [**`PUT /_matrix/client/v3/devices/{deviceId}`**](https://spec.matrix.org/v1.16/client-server-api/#put_matrixclientv3devicesdeviceid) This endpoint is updated to allow the creation of a new device for a user, if @@ -69,8 +64,8 @@ the appservice recovery key is misplaced). ### [**`POST /_matrix/client/v3/login`**](https://spec.matrix.org/v1.16/client-server-api/#post_matrixclientv3login) Logins with the [`m.login.application_service` type] will return HTTP 400 with a -new `M_APPSERVICE_LOGIN_UNSUPPORTED` error code if the appservice has opted into -this MSC. +new `M_APPSERVICE_LOGIN_UNSUPPORTED` error code if the homeserver has switched +to OAuth2. [`m.login.application_service` type]: https://spec.matrix.org/v1.16/client-server-api/#appservice-login @@ -82,9 +77,9 @@ creating an access token is no longer possible on servers that have switched to OAuth2. However, creating users via the endpoint is still required, so unlike `/login`, `/register` will not be removed entirely. -Therefore, application services that have opted into this MSC MUST call the -endpoint with `inhibit_login=true`. Calls without the parameter, or with a -different value than `true`, will return HTTP 400 with the +Therefore, application services on homeservers that have switched to OAuth2 +MUST call the endpoint with `"inhibit_login": true`. Calls without the parameter, +or with a different value than `true`, will return HTTP 400 with the `M_APPSERVICE_LOGIN_UNSUPPORTED` error code. ## Potential issues @@ -97,8 +92,10 @@ The endpoint could just stop returning access tokens to avoid breaking existing appservices that don't read that field, but an explicit error was chosen to avoid silent breakage of appservices that do depend on the field. -The opt-in registration flag allows all old appservices to keep working until -a server switches to OAuth2 entirely. +The breaking changes to `/login` and `/register` only apply to homeservers which +have switched to OAuth2. Homeservers MAY have implementation-specific methods of +opting into the breaking changes before switching to OAuth2 entirely to test +compatibility. ## Security considerations @@ -120,10 +117,7 @@ to use device IDs as a part of identity assertion, as defined by [MSC4326]. ## Unstable prefix -Until this MSC is stable, the opt-in flag in the registration file is -`io.element.msc4190` instead of `device_management`. - -Also, `IO.ELEMENT.MSC4190.M_APPSERVICE_LOGIN_UNSUPPORTED` should be used as the +`IO.ELEMENT.MSC4190.M_APPSERVICE_LOGIN_UNSUPPORTED` should be used as the error code instead of `M_APPSERVICE_LOGIN_UNSUPPORTED`. [MSC4326]: https://github.com/matrix-org/matrix-spec-proposals/pull/4326