From 052d4800f29784571206da980a6b3855b31521c0 Mon Sep 17 00:00:00 2001 From: Travis Ralston Date: Wed, 19 Apr 2023 11:47:35 -0600 Subject: [PATCH] Update 3983-sending-otk-claims-to-appservices.md --- proposals/3983-sending-otk-claims-to-appservices.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/proposals/3983-sending-otk-claims-to-appservices.md b/proposals/3983-sending-otk-claims-to-appservices.md index 7265f029..79141873 100644 --- a/proposals/3983-sending-otk-claims-to-appservices.md +++ b/proposals/3983-sending-otk-claims-to-appservices.md @@ -107,7 +107,7 @@ for the user. **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 +Independent of the appservice having `/keys/claim` proxied to it, it may be desirable 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 @@ -121,6 +121,8 @@ do upon first (known) use. Clients can determine which of the keys returned is the fallback key by `fallback: true` on the returned keys. +Servers MUST NOT mark the fallback key as "used" unless no other OTKs are returned. + ## Potential issues As described, the appservice could be offline or in fact experience a worse uptime than the homeserver.