MSC3008: Scoped access for widgets #3008
Conversation
turt2live
added
proposal-in-review
proposal
| technique. | ||
|
|
||
| The widget would be responsible for renewing the access token, and the client should never re-use access tokens | ||
| even if the scope is the same - the client should always mint a new token for each render. |
There was a problem hiding this comment.
IMHO, it should be stated here or in another MSC that these tokens should automatically expire, such as when the widget is closed. My concern is that even if the widget is closed, the token could be sent to a server, service worker, or another tab. This would be counter-intuitive for the user since, without their knowledge, their token would be in use even though they think the widget now has no way to access/modify their data. It might be worth
Yes, it is true that the widgets should be trusted by the user to access the data they are granted. That being said, I would still expect the widget to not have access to my data when it isn't open.
This issue may be best addressed in another MSC.
| The transfer and encoding of the access token via the query string is questionable, though it does allow | ||
| for quick transport of the information to the widget without relying on postmessage. It further simplifies | ||
| the widget's operation as it can always know which user is using the widget without needing an explicit | ||
| prompt. Alternatives for encoding, transport, etc are possible. |
There was a problem hiding this comment.
It is good to keep sensitive information out of URLs where possible because they get logged more often then we would like. This could be mitigated a number of ways:
- Use HTTP basic auth. This has the advantage that it is well understood by the protocol to be sensitive.
- Provide a one-time short-lived token in the URL which needs to be exchanged for the real token. This way one exchanged (or after a minute or two timeout) the token is inert.
- Provide the token via URL fragment. This way it isn't sent to the server by default and the widget can take care of handling it in a way that the widget author knows is safe. However some analytics, error reporting or debugging tools may end up logging the fragment.
- Pass the token via
postMessage...but that is sort of what this proposal is trying to avoid.
| { | ||
| "access_token": "2YotnFZFEjr1zCsicMWpAA", | ||
| "token_type": "Bearer", | ||
| "expires_in": 299, |
There was a problem hiding this comment.
I would suggest using an expiry timestamp instead. Since the widget will likely see this expiry a little while after the token is created, the widget will not know exactly when to refresh.
turt2live
added
the
needs-implementation
| } | ||
| ``` | ||
|
|
||
| The widget would receive a client-server URL via a `$matrix_hs_url` template parameter using the same encoding |
There was a problem hiding this comment.
Does this imply, that the widget only communicates with the home-server directly? Since a room based widget would probably (in lots of scenarios at least) query the same messages as the client has already loaded from the server it would be nice to have some standardized method to send a matrix-client-server request to the client and the client just forwards the events (if they conform to the permissions) to the widget. Basically the client would than mimic the matrix server to prohibit downloading messages twice.
| // authentication/authorization for widgets. | ||
| "auth": { | ||
| "scopes": [ | ||
| // Exact scopes TBD |
There was a problem hiding this comment.
I am thinking if the current filter API could be used as the format for scoping. From first sight the filter seems to cover a very similar way of selecting/categorizing events that are allowed to be received by the widgets. (In general a permission scope should be very similar to a filter. A structure to filter a subset of messages that are allowed to be read and send by the widget.)
Maybe there are obvious oversights that makes filter unsuitable. But It would minimize redundancy in the spec and probably would also allow to reuse some code. checking if an event conforms to the permission (filter) would already be implemented.
Rendered