-
Notifications
You must be signed in to change notification settings - Fork 379
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #2033 from matrix-org/travis/msc/whoami-device
MSC2033: Adding a device_id to /account/whoami
- Loading branch information
Showing
1 changed file
with
30 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,30 @@ | ||
# Proposal to include device IDs in `/account/whoami` | ||
|
||
There are some use cases (namely using | ||
[Pantalaimon with bots](https://github.com/matrix-org/pantalaimon/issues/14)) | ||
which could benefit from knowing the `device_id` associated with a token. | ||
|
||
|
||
## Proposal | ||
|
||
The `/account/whoami` endpoint receives an additional response field for the `device_id` | ||
associated with the access token. The field is optional because appservice users may not | ||
have a real device associated with them. Non-appservice users should always have a device | ||
associated with them. | ||
|
||
Access tokens are already associated with at most 1 device, and devices are associated with | ||
exactly 1 access token. Because of this, we do not need to worry about multiple devices | ||
causing problems. For more information, see | ||
https://matrix.org/docs/spec/client_server/r0.4.0.html#relationship-between-access-tokens-and-devices | ||
|
||
*Note*: Pantalaimon would likely require a `device_id` be returned and error requests | ||
otherwise. This should be considered expected behaviour by Pantalaimon in the MSC author's | ||
opinion. | ||
|
||
|
||
## Tradeoffs | ||
|
||
We could introduce a `/device/whoami` endpoint, however that is a less superior option. Most | ||
calls to `/device/whoami` would additionally need to call `/account/whoami` to determine the | ||
user ID of the account. We had might as well bundle the two pieces of information into the | ||
same request. |