Conversation
erkinalp
left a comment
There was a problem hiding this comment.
Don't use the word sudo as we do not have a concept of superusers or substitute users in Matrix.
|
Related: matrix-org/matrix-spec#725 |
proposals/2967-api-scopes.md
Outdated
|
|
||
| #### Device ID handling | ||
|
|
||
| Presently a device ID is typically generated by the homeserver and is associated with a specific access token. In OAuth 2.0 there is no such thing as a session and so a mapping cannot be handled using the same mechanism. |
There was a problem hiding this comment.
Is this still true after refresh tokens (MSC2918)? I thought we did a bunch of work in Synapse related to this recently, but maybe I'm confusing different types of tokens.
There was a problem hiding this comment.
Technically yes, in practice no as MSC2918-style refresh tokens are almost not adopted by anyone. Is it worth clarifying here?
|
|
||
| This MSC proposes that the Matrix client is responsible for generating/allocating a device ID. | ||
| A client can create a new device ID by generating a random string and asking for its associated scope on login. | ||
| A client can adopt and rehydrate an existing device ID by asking for its associated scope on login. |
There was a problem hiding this comment.
Talked out of band last Friday morning, and there sounds like there is a bunch of historical context here (that has since become mostly outdated). Conclusion was for @sandhose to comment with the background and a bit or a rationale, and then we can make a final call on whether we want device IDs to be generated on the client or server.
Something that I didn't realise is that the spec currently allows clients to generate device IDs when they log in (mostly for bots and the like).
|
|
||
| This MSC proposes that the Matrix client is responsible for generating/allocating a device ID. | ||
| A client can create a new device ID by generating a random string and asking for its associated scope on login. | ||
| A client can adopt and rehydrate an existing device ID by asking for its associated scope on login. |
There was a problem hiding this comment.
Is it possible for the homeserver to still generate a device ID if a urn:matrix:client:device:<device ID> scope is omitted? Or would that be odd behaviour in the OAuth 2.0 world?
Having the ability for the homeserver to generate the device ID does make very simple matrix clients even simpler (no need to randomly generate a string). But I don't feel strongly that this behaviour must remain; it's only a nice-to-have.
Similarly, I recognise that it's useful for the client to provide a device ID upon login (for device rehydration and other use cases). So I'm happy to see that's still supported.
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Co-authored-by: Patrick Cloke <clokep@users.noreply.github.com>
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
|
spec PR: matrix-org/matrix-spec#2149 |
Merged! 🎉 |
Rendered
urn:matrixnamespaceDependencies:
Implementations:
Homeservers
Homeservers:
urn:matrix:client:api:*urn:matrix:client:device:XXXXClients
Clients need to request scopes appropriately.
urn:matrix:client:api:*urn:matrix:client:device:XXXXurn:matrix:client:api:*urn:matrix:client:device:XXXXurn:matrix:client:api:*urn:matrix:client:device:XXXXurn:matrix:client:api:*urn:matrix:client:device:XXXXSCT stuff:
checklist
FCP tickyboxes