3 ms·
One of the really cool things about Third Room is that it’s the first Matrix client to natively launch with OIDC for auth. This means you will be able to grant
by Arathorn 4y ago
One of the really cool things about Third Room is that it’s the first Matrix client to natively launch with OIDC for auth. This means you will be able to grant it access to specific auth scopes in future if you don’t want to give it access to your main account, and I think solve precisely the problem you’re talking about here.
Check out the OIDC section of https://matrix.org/blog/2022/08/15/the-matrix-summer-special-2022/ https://matrix.org/blog/2022/08/15/the-matrix-summer-special... for more details
- ryukafalz 4y agoThat's better than the current state of things, but I think still not as fine-grained as it should be, at least not without a lot of work and standardization. Among other things: - This requires that any time you want to be able to selectively grant a subset of your account's authority, it requires standardizing new scopes to do so if there aren't already some that are suitable - If I'm not mistaken, only the application is able to define which OIDC scopes are requested, and if the application requests more access than you'd like to give it, your options are limited - If I'm not mistaken, OIDC scopes can only be requested at authentication-time, so there's no way to grant additional access later on at runtime To be clear, none of this is specific to Matrix; most webapps seem to work this way! I just happen to be of the opinion that most webapps have way more access than they need. :)
- Arathorn 4y agoWe’re intending to spec very finely granular scopes. Eg “this client is allowed to read but not send these sort of events in this set of rooms, and shouldn’t be sent keys for other rooms”.