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