Filip/matrix-spec
1
0
Fork 0
mirror of https://github.com/matrix-org/matrix-spec synced 2026-03-05 03:04:11 +01:00
Code Issues Actions 1 Packages Projects Releases Wiki Activity

Apply suggestions from code review

Browse source
This commit is contained in:
Richard van der Hoff 2025-06-11 09:38:35 +01:00 committed by GitHub
parent c46a813ad2
commit 8dea69ffd8
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 2 additions and 2 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
content/client-server-api/_index.md
View file

@ -1525,7 +1525,7 @@ This specification defines the following scope tokens:
| Scope | Purpose | | Scope | Purpose |
|---------------------------|---------------------------------------------| |---------------------------|---------------------------------------------|
| `urn:matrix:client:api:*` | Grants full access to the Client-Server API | | `urn:matrix:client:api:*` | Grants full access to the Client-Server API. |
{{% boxes/note %}} {{% boxes/note %}}
This token matches the behavior of the legacy authentication API. Future MSCs This token matches the behavior of the legacy authentication API. Future MSCs
@ -1537,7 +1537,7 @@ could introduce more fine-grained scope tokens like
| Scope | Purpose | | Scope | Purpose |
|----------------------------------------|----------------------------------------------------------------------------------------------| |----------------------------------------|----------------------------------------------------------------------------------------------|
| `urn:matrix:client:device:<device_id>` | Allocates the given `device_id` and associates it to the generated access and refresh tokens | | `urn:matrix:client:device:<device_id>` | Allocates the given `device_id` and associates it to the generated access and refresh tokens. |
Contrary to the legacy login and registration APIs where the homeserver is Contrary to the legacy login and registration APIs where the homeserver is
typically the one generating a `device_id` and providing it to the client, with typically the one generating a `device_id` and providing it to the client, with