* Refresh tokens MSC
* MSC2918: minor changes
* MSC2918: access token expiration as milliseconds
* MSC2918: account registration API changes
* MSC2918: fix `expires_in_ms` example
* MSC2918: add precision about token revocation
* MSC2918: specify error codes for the refresh API
* MSC2918: clarify that the change also applies to ASes
* Apply suggestions from code review
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* MSC2918: clarify what problem this MSC solves
* MSC2918: minor formatting and rephrasing
* MSC2918: clarify ratelimiting, masquerading and authentication on refresh token API
* MSC2918: make expires_in_ms/refresh_token optional
* MSC2918: soft logout in refresh token API
* MSC2918: add detailed rationale
While not exhaustive, it outlines a few attack vectors this MSC tries to
mitigate.
* MSC2918: minor fix
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* MSC2918: clarifications on backward compatibility
* MSC2918: advertise support in the request body
* MSC2918: clarify on what happen when token expire
* MSC2918: remove redundant precision about token expiration and lifetime
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* MSC2918: minor clarification
* MSC2918: soft logout when using expired token
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Hubert Chathi <hubert@uhoreg.ca>
* Proposal for token authenticated registration
Signed-off-by: Callum Brown <callum@calcuode.com>
* Hard-wrap lines
Signed-off-by: Callum Brown <callum@calcuode.com>
* Link to released version of spec
Signed-off-by: Callum Brown <callum@calcuode.com>
* Fix unstable prefix wording
Signed-off-by: Callum Brown <callum@calcuode.com>
* Tokens should only be invalidated after registration
Signed-off-by: Callum Brown <callum@calcuode.com>
* Change auth type to m.login.registration_token
This is consistent with the other UIAA auth types, and does not suggest
that other `m.login.*` types cannot be used for registration.
Signed-off-by: Callum Brown <callum@calcuode.com>
* Add proposal for checking the validity of a token
Signed-off-by: Callum Brown <callum@calcuode.com>
* Fix validity checking endpoint
Signed-off-by: Callum Brown <callum@calcuode.com>
* Limit allowed characters and length of token
This allows tokens to be used easily in query parameters
Signed-off-by: Callum Brown <callum@calcuode.com>
* Give reason for limiting token length and chars
Signed-off-by: Callum Brown <callum@calcuode.com>
* Note all stages must be complete for registration
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
* Fix mistake in MSC number
Signed-off-by: Callum Brown <callum@calcuode.com>
* Validity checking should be rate limited
Signed-off-by: Callum Brown <callum@calcuode.com>
* Change v1 to r0
Signed-off-by: Callum Brown <callum@calcuode.com>
* Include `.` and `~` in allowed characters for registration tokens
For consistency with the unreserved URL characters in RFC3986
https://www.ietf.org/rfc/rfc3986.html#section-2.3
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Andrew Morgan <1342360+anoadragon453@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
* Clarify how redacted_because actually works for events
* changelog
* mention federation
* Fix wording
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
Co-authored-by: Richard van der Hoff <1389908+richvdh@users.noreply.github.com>
This tweaks the DAG to be simpler, with two linear event chains E4 -> E3
-> E2 -> E1 and E6 -> E5 -> E2 -> E1. The extremities of the DAG are now
the first and only point in the DAG where multiple event parents occur.
Since the point of the diagram is to demonstrate this very situation,
it's better didactically if there is only one such situation in the
diagram.
The Pagination section in the C-S API was, basically, full of rubbish. I think that anything of any value it contained was repeated either directly on the API definitions or in the text specific to syncing at https://spec.matrix.org/unstable/client-server-api/#syncing.
The conventions I've added to the Appendices are based on the discussions in #1898. They are there because I don't want to have to go through it all again next time we add a paginated API.
Fixes: #1898Fixes: #2268
