From e781b75847c0651336da60e17a99f0bbfdb606e5 Mon Sep 17 00:00:00 2001 From: Will Hunt Date: Mon, 3 May 2021 18:09:27 +0100 Subject: [PATCH] Mention that /register provides a token but it's not helpful --- proposals/2778-appservice-login.md | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/proposals/2778-appservice-login.md b/proposals/2778-appservice-login.md index 3f79d8c3..567f8411 100644 --- a/proposals/2778-appservice-login.md +++ b/proposals/2778-appservice-login.md @@ -81,6 +81,12 @@ A third option could be to create a new endpoint that simply creates a new devic Given the rest of the matrix eco-system does this with /login, and /login is already extensible with `type`, it would create more work for all parties involved for little benefit. +Finally, `POST /register` does already return a `device_id`, `access_token` for appservice users by default. However critically +this means that bridges will need to be designed to store the access_token and device_id from the point of creating the user, +so older bridges would be unable to get an access token for existing users as `POST /register` would fail. +It would difficult to log out these tokens if they got exposed additionally, as the AS would not be able to fetch a new access token. +Furthermore, the ability to generate access tokens for real users who registered elsewhere would not be possible with this mechanism. + ## Security considerations Appservices could use this new functionality to generate devices for any userId that are within it's namespace e.g. setting the