MSC4254: Usage of RFC7009 Token Revocation for Matrix client logout #4254
Conversation
7780b3b to
bc25ec8
Compare
bc25ec8 to
ac1602f
Compare
|
MSCs proposed for Final Comment Period (FCP) should meet the requirements outlined in the checklist prior to being accepted into the spec. This checklist is a bit long, but aims to reduce the number of follow-on MSCs after a feature lands. SCT members: please check off things you check for, and raise a concern against FCP if the checklist is incomplete. If an item doesn't apply, prefer to check it rather than remove it. Unchecking items is encouraged where applicable. Checklist:
|
|
@mscbot fcp merge |
|
Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people: Once at least 75% of reviewers approve (and there are no outstanding concerns), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for information about what commands tagged team members can give me. |
Co-authored-by: Richard van der Hoff <[email protected]> Co-authored-by: Tonkku <[email protected]>
proposals/4254-oauth2-revocation.md
Outdated
| - `token_type_hint`: This parameter is OPTIONAL, and if present, MUST have a value of either `access_token` or `refresh_token`. The server MAY use this value to optimize the token lookup process | ||
| - `client_id`: The client identifier obtained during client registration. | ||
|
|
||
| If the `client_id` is not provided, or does not match the client associated with the token, the server SHOULD still revoke the token. The server MAY also warn the user that one of their sessions may be compromised in this scenario. |
There was a problem hiding this comment.
I'm not entirely following why a server would want to warn if one of the sessions is compromised if no client_id is provided. A sentence or two of rationale might help here.
There was a problem hiding this comment.
I've explained that better in cd239ce
| 2. Support single logout across multiple clients | ||
| 3. Give visual feedback to the user about the logout process | ||
|
|
||
| However, this approach requires a browser redirect which may not be desirable for all clients, especially mobile platforms. |
There was a problem hiding this comment.
I'm not following why a browser redirect would ever be a problem (especially on mobile)?
The main proposal made sense when i was reading it, but then on hitting this RP-Initiated Logout alternative, I thought "huh, but these advantages sound great - why aren't we doing this then?", given I don't understand the disadvantage.
There was a problem hiding this comment.
I think it's relatively unexpected from a user perspective to be bounced through the browser for logging out. This can be relatively transparent for web clients with a redirect, but for native clients, it means opening a browser window, switching context; and there is no defined way to get back to the client after the RP-initiated logout, so you end up outside the client at the end of the logout
There was a problem hiding this comment.
hm, okay. can you add the rationale to the MSC please? :)
Co-authored-by: Patrick Cloke <[email protected]>
|
🔔 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#2151 |
Rendered
Implemented in
matrix-authentication-service, Element X iOS and Android (through the matrix-rust-sdk) and Element WebPart of the following proposal:
In line with matrix-org/matrix-spec#1700, the following disclosure applies:
I am a Software Engineer at Element. This proposal was written and published as an Element employee.
SCT stuff:
checklist
FCP tickyboxes