MSC4029: [WIP] Fixing X-Matrix request authentication#4029
MSC4029: [WIP] Fixing X-Matrix request authentication#4029
X-Matrix request authentication#4029Conversation
turt2live
added
proposal
| @@ -0,0 +1,137 @@ | |||
| # MSC4029: Fixing `X-Matrix` request authentication | |||
| @@ -0,0 +1,137 @@ | |||
| # MSC4029: Fixing `X-Matrix` request authentication | |||
There was a problem hiding this comment.
Probably not something that will be encountered with any sensible server, but it is possible to have multiple Authorization headers with the same scheme if different realms are used:
Note that a response can have multiple challenges with the same auth-scheme but with different realms.
So perhaps there could be a note stating that servers should only use the first X-Matrix header they encounter?
There was a problem hiding this comment.
Hmm no, the RFC says this is the case for a response, so how exactly would multiple X-Matrix keys be available in a request while still following the RFC?
| endpoint to fetch that server's keys. | ||
|
|
||
| Servers SHOULD NOT [query keys through another server](https://spec.matrix.org/v1.9/server-server-api/#querying-keys-through-another-server) | ||
| when validating a request signature. Instead, the server's local cache and direct requests to the |
There was a problem hiding this comment.
By server's local cache, I assume this would mean cache of the keys obtained directly from the server which the request is from, and not cached keys obtained via POST /_matrix/key/v2/query and/or GET /_matrix/key/v2/query/{serverName} of another server, right?
There was a problem hiding this comment.
However that cache was built, realistically.
There was a problem hiding this comment.
It would be nice if this was made explicit, since interpretations of the text here can vary.
2 participants
Rendered
Issues relating to this problem space are:
Related issues, while we're in the area: