Proposed XMPP Extension: SASL2 Terms of Service Acceptance Task
The XMPP Extensions Editor has received a proposal for a new XEP. Title: SASL2 Terms of Service Acceptance Task Abstract: This specification defines a SASL2 task, per the extensibility mechanism of XEP-0388, that lets a server require a user to accept the current terms of service before authentication completes. URL: https://xmpp.org/extensions/inbox/sasl2-tos.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.
Is this only intended for closed deployments? Otherwise I don't see how this could be enabled on servers with unknown clients, and I think the failure modes for unsupported clients are extra bad as they'd likely see some confusing auth error? Does the <text> address this in practice if SASL2 without this is implemented? What if client doesn't support SASL2? At minimum a section for server operators would be good. Alternatives I might suggest: 1. if unsupported by the client go ahead and "finish authentication" then send them a normal message with instructions on how to accept the new ToS? Exact instructions undefined but could be a link to a web form or clients that support this. 2. why tie to SASL at all? why not just block sending until they agree? which could be via messages or data forms or whatever, and then you don't even need client support, or for that matter even a XEP I guess... (though advice/concerns would still be good to document somewhere) Lastly I'm a bit concerned there could be serious security/safety implications here, mitigated some if there was a way to give advance warning (hi you must agree before date X to keep using you have Y days left) but still not gone. eg a kid is away from home and gets in a bad accident and suddenly can't call for help because this locks them out. (can you tell my kids are nearing driving age? send help). At minimum another note for server operators to consider. On September 29, 2026 5:51:51 AM EDT, Daniel Gultsch <daniel@gultsch.de> wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: SASL2 Terms of Service Acceptance Task Abstract: This specification defines a SASL2 task, per the extensibility mechanism of XEP-0388, that lets a server require a user to accept the current terms of service before authentication completes.
URL: https://xmpp.org/extensions/inbox/sasl2-tos.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. _______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
Hi Travis, Thanks for the thorough feedback. As the text is currently before the Council, I'd like to keep it stable for that review. I'm not planning to apply changes to it now, but I'm noting the points below to be addressed in a revision if and when the document is accepted. I wouldn't frame it as "closed deployments only," but you're right that enabling this on a server with an unknown client population has a not to be underestimated cost: clients that don't implement the task, or don't implement SASL2 at all, can't complete authentication. I don't think every XEP needs to suit every deployment, but the specification should explicitly say this, and help operators weigh it. A "Deployment Considerations" section seems like the right place. That can cover lockout of non-supporting clients, giving advance notice before enforcement, and the safety impact of losing access, which your example illustrates. On failure modes: the mandatory <text/> is meant to cover SASL2 clients that don't know this task, though whether it's displayed is up to the client. One improvement I'd like to consider is having the server repeat the explanation in the <failure/> that follows an abort, since that's the text clients most commonly show. As there aren't many XEPs that define SASL2 tasks yet, I think there's some need for us to experiment with what works best in this respect. For non-SASL2 clients, the Security Considerations already require the server not to offer a bypass path. The resulting lockout could be stated more explicitly. As for the alternatives: for some, the point of this task can precisely be that there's no way around it. When the requirement stems from legal obligations, a mechanism that lets non-supporting clients through on softer terms may not satisfy things. That's why I'd rather not build such a fallback into this specification. Operators who prefer a softer approach can of course use post-login measures like the ones you describe, either instead of this task or alongside it (for example, to give advance notice before enforcement starts). Documenting those approaches could be valuable (and prior art exists, but doesn't seem to have advanced since 2018: "Terms of Services" - https://xmpp.org/extensions/inbox/tos.html ). I would see that as belonging in a separate XEP, rather than in the one under consideration now. Kind regards, Guus On Tue, Sep 29, 2026 at 2:37 PM Travis Burtrum <travis@burtrum.org> wrote:
Is this only intended for closed deployments? Otherwise I don't see how this could be enabled on servers with unknown clients, and I think the failure modes for unsupported clients are extra bad as they'd likely see some confusing auth error? Does the <text> address this in practice if SASL2 without this is implemented? What if client doesn't support SASL2? At minimum a section for server operators would be good.
Alternatives I might suggest: 1. if unsupported by the client go ahead and "finish authentication" then send them a normal message with instructions on how to accept the new ToS? Exact instructions undefined but could be a link to a web form or clients that support this. 2. why tie to SASL at all? why not just block sending until they agree? which could be via messages or data forms or whatever, and then you don't even need client support, or for that matter even a XEP I guess... (though advice/concerns would still be good to document somewhere)
Lastly I'm a bit concerned there could be serious security/safety implications here, mitigated some if there was a way to give advance warning (hi you must agree before date X to keep using you have Y days left) but still not gone. eg a kid is away from home and gets in a bad accident and suddenly can't call for help because this locks them out. (can you tell my kids are nearing driving age? send help). At minimum another note for server operators to consider.
On September 29, 2026 5:51:51 AM EDT, Daniel Gultsch <daniel@gultsch.de> wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: SASL2 Terms of Service Acceptance Task Abstract: This specification defines a SASL2 task, per the extensibility mechanism of XEP-0388, that lets a server require a user to accept the current terms of service before authentication completes.
URL: https://xmpp.org/extensions/inbox/sasl2-tos.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. ------------------------------ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Tue, 29 Sept 2026 at 13:37, Travis Burtrum <travis@burtrum.org> wrote:
Is this only intended for closed deployments? Otherwise I don't see how this could be enabled on servers with unknown clients, and I think the failure modes for unsupported clients are extra bad as they'd likely see some confusing auth error? Does the <text> address this in practice if SASL2 without this is implemented? What if client doesn't support SASL2? At minimum a section for server operators would be good.
I think SASL2 has a general problem here, which is that I never included a way to indicate what tasks were supported, and also if any tasks are proposed by the server the client MUST pick one. The sensible options we have are to signal the client supports a task in the <authenticate/>, or else to ... actually not sure there's many other sensible options, since I'm willing to bet most clients will simply choke if they see a <continue/> at this point.
Alternatives I might suggest: 1. if unsupported by the client go ahead and "finish authentication" then send them a normal message with instructions on how to accept the new ToS? Exact instructions undefined but could be a link to a web form or clients that support this.
Seems reasonable.
2. why tie to SASL at all? why not just block sending until they agree? which could be via messages or data forms or whatever, and then you don't even need client support, or for that matter even a XEP I guess... (though advice/concerns would still be good to document somewhere)
Tying it to SASL is interesting, because the user and operator's agreement on the terms is being treated as authorization to continue the session - which in the legal sense of authorization it absolutely is.
Lastly I'm a bit concerned there could be serious security/safety implications here, mitigated some if there was a way to give advance warning (hi you must agree before date X to keep using you have Y days left) but still not gone. eg a kid is away from home and gets in a bad accident and suddenly can't call for help because this locks them out. (can you tell my kids are nearing driving age? send help). At minimum another note for server operators to consider.
Including a deadline, and a "defer" option seems sensible.
On September 29, 2026 5:51:51 AM EDT, Daniel Gultsch <daniel@gultsch.de> wrote:
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: SASL2 Terms of Service Acceptance Task Abstract: This specification defines a SASL2 task, per the extensibility mechanism of XEP-0388, that lets a server require a user to accept the current terms of service before authentication completes.
URL: https://xmpp.org/extensions/inbox/sasl2-tos.html
The Council will decide in the next two weeks whether to accept this proposal as an official XEP. ________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
participants (4)
-
Daniel Gultsch -
Dave Cridland -
Guus der Kinderen -
Travis Burtrum