Ability to mint access_tokens with restricted scope.

[ara4n]

There are many scenarios where it'd be useful to be able to give a client or AS or bot or widget or some other service limited access to your account:

• To limit access to other APIs (e.g. to forbid an untrusted client from being able to read account_data, or to read your 3PID bindings, or attempt E2EE etc).
• To hand access to a subset of rooms to a limited account (e.g. a read-only HUD)
• To allow a double-puppetted bridge to send messages as your real user, but only in bridged rooms

In the past this has got a bit derailed by the idea of replacing our auth system entirely by OAuth2: https://github.com/matrix-org/matrix-doc/issues/2615 - and meanwhile an MSC trying to do something very similar to this got abandoned: matrix-org/matrix-spec-proposals#531. So I'm reopening this as a high level issue for folks to upvote and coordinate via.

[eras]

Yes I would certainly like to see this!

A few thoughts I've had on this, although they don't completely match the bullet points you have listed as they are rather thought of mostly with bot accounts in mind:

1. There would be a relation from the managed sub-account and the (multiple) parent/controller accounts. It would be configurable if the sub-account can remove this relation.
2. There would be a set of commands the parent account can make happen in the sub-account. In particular, there could be a way to reset the password of a sub-account. This would allow easily e.g. managing a group of accounts (e.g. family, company, team) without any particular administrative bits in the system. Disabling account is of course also one of the commands
3. There would be a set of commands the sub-account can issue. This would be useful for e.g. bot accounts, for webchat accounts.
4. Inspired by what you wrote: you could attach to your account a set of commands another account can cause in your account. It would be like the same as previous points, but configured in reverse.

Set of commands could be an endpoint-oriented JSON pattern "firewall list" like: [{"PUT: "/r0/rooms/([^/]*)/send/m.room.message/.*", "permit": true}, {"GET": ".*", "permit": false}, {"PUT": ".*", "permit": false}] which would be very close to the protocol and would likely need the least amount of work both in clients and the servers to implement. Instead of regular expressions some other more structured way of expressing patterns could be used, which would likely be easier to manipulate programmatically. Similar approach could be used for filtering messages a bot can receive in a room and it would be easy-ish for clients to determine if a message should be sent a bot in an e2ee room (and thus only send appropriate keys to the bot only in those cases).

Obviously there's a big risk of scope creep here 🙄.

[turt2live]

fwiw https://github.com/turt2live/matrix-oauth exists as a very early proof of concept for this sort of thing, with intentions of expanding it out as a playground before a formal MSC.

[richvdh]

related matrix-org/synapse#5323

[kegsay]

Given I spent a decent amount of time on matrix-org/matrix-spec-proposals#531 and I'm no longer a pumpkin, I'd love to take this up again and implement it in Dendrite. This issue wasn't as important 5.5 years ago when I wrote that issue, but is definitely more important now as Matrix has a strong native community which has accounts which want to be protected.

[sandhose]

MSC laying out the path for this: matrix-org/matrix-spec-proposals#2967
This is part of a larger work aiming to replace Matrix authentication with OAuth 2.0

[KB1RD]

Yes I would certainly like to see this!

A few thoughts I've had on this, although they don't completely match the bullet points you have listed as they are rather thought of mostly with bot accounts in mind:

1. There would be a relation from the managed sub-account and the (multiple) parent/controller accounts. It would be configurable if the sub-account can remove this relation.

2. There would be a set of commands the parent account can make happen in the sub-account. In particular, there could be a way to reset the password of a sub-account. This would allow easily e.g. managing a group of accounts (e.g. family, company, team) without any particular administrative bits in the system. Disabling account is of course also one of the commands

3. There would be a set of commands the sub-account can issue. This would be useful for e.g. bot accounts, for webchat accounts.

4. Inspired by what you wrote: you could attach to your account a set of commands another account can cause in your account. It would be like the same as previous points, but configured in reverse.

Set of commands could be an endpoint-oriented JSON pattern "firewall list" like: [{"PUT: "/r0/rooms/([^/]*)/send/m.room.message/.*", "permit": true}, {"GET": ".*", "permit": false}, {"PUT": ".*", "permit": false}] which would be very close to the protocol and would likely need the least amount of work both in clients and the servers to implement. Instead of regular expressions some other more structured way of expressing patterns could be used, which would likely be easier to manipulate programmatically. Similar approach could be used for filtering messages a bot can receive in a room and it would be easy-ish for clients to determine if a message should be sent a bot in an e2ee room (and thus only send appropriate keys to the bot only in those cases).

Obviously there's a big risk of scope creep here roll_eyes.

I think there is a significant use case for accounts controlling parts of other accounts as you outline here. I have two concerns however with this:

• There should be a way to create temporary scoped access tokens. This could be used to give widgets temporary access to a user's account.
• While the firewall idea is an ideal way to specify capabilities for an account, when used in the widget scenario, it may be too complex to effectively convey to users what permissions are being granted, like the current push notification system.

[turt2live]

matrix-org/matrix-spec-proposals#2967 currently has the best chance of being approved, and if not it's a thing we want to do anyways. Let's triage this through the proposals process rather than as an idea, now that we have an MSC to link to.