Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MSC3983: Sending One-Time Key (OTK) claims to appservices #3983

Open
wants to merge 13 commits into
base: main
Choose a base branch
from
+184 −0
Open

MSC3983: Sending One-Time Key (OTK) claims to appservices #3983

Changes from 1 commit
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
f82e463
Sending One-Time Key (OTK) claims to appservices
turt2live Mar 23, 2023
90006ad
Fix typos
turt2live Mar 23, 2023
b128030
Actually fix typos?
turt2live Mar 23, 2023
0630814
Oops, auth is important
turt2live Mar 23, 2023
bbc79ab
Clarify that OTKs should only be used once still
turt2live Mar 23, 2023
91e6d02
Acknowledge performance hit
turt2live Mar 24, 2023
0b9f6d9
Mention e2be approach currently in use
turt2live Mar 24, 2023
8a1dd86
Mention encryption bridge usecase
turt2live Mar 24, 2023
5a4a6c6
Use the fallback key when missing *some* keys too
turt2live Mar 24, 2023
c770168
Mention MSC3984 for key queries
turt2live Mar 24, 2023
a95bf4f
Clarify that 405/M_UNRECOGNISED is a good idea
turt2live Mar 24, 2023
2177b93
Add a section about overriding fallback keys
turt2live Apr 19, 2023
052d480
Update 3983-sending-otk-claims-to-appservices.md
turt2live Apr 19, 2023
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 18 additions & 0 deletions proposals/3983-sending-otk-claims-to-appservices.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -103,6 +103,24 @@ to have a namespace covering the user: instead of guessing or going around to ea
user to be in an exclusive namespace. This guarantees that there's only one appservice responsible
for the user.

## Returning extra keys

**TODO**: This is probably best as its own MSC.

Independent of the appservice having `/keys/claim` proxied to it, it may be desireable for both the
fallback and one-time key to be returned. Servers should *always* include the fallback key alongside
the requested OTKs. When using this proposal's new endpoint, the server should use the fallback key
from the appservice's response rather than a previously stored fallback key, if present (if the
appservice doesn't respond with a fallback key then the server uses the stored fallback key instead,
if known).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this enough of a change that it need to be a v4 of the endpoint, perhaps? (Or a query parameter which defaults to the current behavior?)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it'd be fine, though open to thoughts. Currently clients appear to pick the "first" key returned, not validating if the extra data is useful to them. In theory this means we can include extra keys with no issues, though if there's a significant need to have it be a dedicated endpoint then let's do that.

We should probably only do this fallback stuff on an /unstable/org.matrix.msc3983 endpoint though, just in case.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

matrix-org/synapse#15462 implements this as a separate endpoint.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another piece of this I realized during implementation is if we need to also make a change on the federation side.

Comment on lines +112 to +115
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't define if the appservice should be queried for fallback keys if a OTK is in the database.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In lieu of MSC text: the appservice is supposed to be queried, similar to MSC3984 where the server uses what it knows if the appservice didn't provide it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually I suppose the text in the MSC is enough as is:

For users under an appservice's explicit namespace, if that user has no unused OTKs (excluding fallback keys) on the homeserver, the homeserver proxies the following APIs to the appservice using the new API described below:

This would not match what you just wrote though and would mean it is not possible for an appservice to only provide fallback keys. I'm not sure if that's a good thing or a bad thing though. 🤷

If we really do want that then I think we want to use different endpoints or something. Otherwise the appservice wouldn't know if we truly want to query for OTKs or only for fallback keys (it could end up returning OTKs which go unused?)


The server SHOULD NOT replace any uploaded fallback keys with ones returned by the appservice via
this proposal. The appservice MUST re-upload the fallback key if it wants to replace it, as it would
do upon first (known) use.

Clients can determine which of the keys returned is the fallback key by `fallback: true` on the returned
keys.

## Potential issues

As described, the appservice could be offline or in fact experience a worse uptime than the homeserver.
Expand Down