MSC2230: Store Identity Server in Account Data #2230
Conversation
There was a problem hiding this comment.
generally looks good to me. I have concerns with using MUST all over the place given this isn't declared as a module: if it were declared as a module, the MUSTs can stay because it would be under the context of "clients which support identity servers stored in account data MUST respect the rules of the module".
Also, proposals are meant to be somewhat less formal than the spec. Including keywords like MUST and SHOULD can sometimes lead to nitpicks like this. Lowercasing all the keywords or altering the language can help communicate intent without getting stuck on bikesheds.
Use fewer formal MUST etc in proposal Co-Authored-By: Travis Ralston <[email protected]>
|
Given that I don't think this MSC is going to change too drastically at this point: @mscbot fcp merge |
|
Team member @anoadragon453 has proposed to merge this. The next step is review by the rest of the tagged people: Concerns:
Once a majority of reviewers approve (and none object), 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 info about what commands tagged team members can give me. |
mscbot
added
proposed-final-comment-period
| ## Proposal | ||
|
|
||
| The base URL of the Identity Server is to be stored in user account data. It | ||
| shall be stored in the same format as in a .well-known file under the key, |
There was a problem hiding this comment.
can you give an example of what this will look like?
There was a problem hiding this comment.
{
"type": "m.identity_server",
"content": {
"base_url": "https://vector.im"
}
}
if I understand the docs correctly, I think.
|
|
||
| ## Security considerations | ||
|
|
||
| An attacker would be able to force all a user clients to use a given ID Server |
There was a problem hiding this comment.
it also puts control of the IS to be used in the hands of the HS admin (or a MITM etc).
There was a problem hiding this comment.
This could be solved by signing m.identity_server account data using the user's master cross-signing key. (Once we get that through MSC...)
| Users will no longer be able to have different clients configured with | ||
| different ID Servers. | ||
|
|
||
| ## Security considerations |
There was a problem hiding this comment.
do clients need to be a bit wary of things they read from the URL to check that they are valid URLs and aren't localhost and that sort of thing?
mscbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
Co-Authored-By: Richard van der Hoff <[email protected]>
|
@mscbot concern The migration process for this needs to be changed |
mscbot
added
proposed-final-comment-period
|
@mscbot resolve The migration process for this needs to be changed |
mscbot
added
final-comment-period
|
🔔 This is now entering its final comment period, as per the review above. 🔔 |
mscbot
added
finished-final-comment-period
and removed
final-comment-period
|
The final comment period, with a disposition to merge, as per the review above, is now complete. |
|
Implementation: matrix-org/matrix-react-sdk#3320 |
turt2live
added
spec-pr-missing
|
Spec PR: #2281 |
turt2live
added
spec-pr-in-review
turt2live
added
merged
|
merged 🎉 |
Rendered