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