MSC4350: Permitting encryption impersonation for appservices #4350
Conversation
Signed-off-by: Tulir Asokan <[email protected]>
tulir
added
e2e
proposal
There was a problem hiding this comment.
Implementation requirements:
- Bridge or other appservice making use of impersonation
- Client that validates impersonation requirements
- Server that exposes
signaturesproperly
| The `algorithms` and `keys` fields are still present and required, but MUST be | ||
| empty when an impersonator is defined. Because there are no keys, `signatures` |
There was a problem hiding this comment.
What does this mean? Both fields need to be set to an empty list?
If so, I think it would be better to say it like that explicitly. And second, why require them to be defined but be an empty list?
There was a problem hiding this comment.
The fields are currently required, so the main reason is to avoid changing that. They could totally be removed too if that's preferred, I was mostly thinking about what would cause the least unexpected behavior in old clients.
|
|
||
| The device owned by the ghost user (or real Matrix user in case of double | ||
| puppeting) with the `impersonator` field will be referred to as the | ||
| "impersonatable" device, while the bridge bot's device is the "impersonator" |
There was a problem hiding this comment.
Given that the "impersonatable device" has no keys, in what way is it a device being impersonated? Rather, I believe "impersonatable device" is a bit of a misnomer; it is simply a way for a user to specify a foreign device that is allowed to impersonate them. It is the user being impersonated, not any specific device of theirs.
There was a problem hiding this comment.
Yeah need to figure out some better terms. The impersonator is the bridge bot's device which is obvious enough, but I'm not sure what to call the device entry that points at the impersonator without it being confusable with the impersonator itself.
Rendered