Operators of XMPP services are sometimes required, for legal or policy reasons, to obtain a user's explicit acceptance of a terms-of-service document before letting that user access the service, and to be able to demonstrate that the currently-applicable version of that document was the one accepted.
Today this is typically handled outside of the XMPP authentication exchange itself, for example through an out-of-band web flow, or by nagging the user post-login with no guarantee they ever comply. Neither gives the server a reliable way to withhold a session from an account that has not accepted the current terms.
Extensible SASL Profile (XEP-0388)XEP-0388: Extensible SASL Profile <https://xmpp.org/extensions/xep-0388.html>. defines a generic mechanism, the SASL2 "task" flow, by which a server can insert one or more additional steps between the completion of a SASL exchange and the completion of the SASL2 negotiation, using the <continue/>, <next/> and <task-data/> elements it defines. Nothing that marks a session as authenticated may occur until every such task has completed. This specification defines one concrete task, built on that mechanism, for the purpose of requiring acceptance of a versioned terms-of-service document.
This document defines only the task itself: its namespace, its elements, and the rules governing when it applies and how its outcome is determined. How a task is offered, selected, and driven to completion or failure in general is defined by Extensible SASL Profile (XEP-0388)XEP-0388: Extensible SASL Profile <https://xmpp.org/extensions/xep-0388.html>..
A server MUST be able to prevent an account from completing authentication until the current version of its terms of service has been accepted by that account.
A server SHOULD be able to determine, per account, whether the currently-applicable version has already been accepted, so that a user who has already accepted is not asked again.
A server MUST provide a human-readable explanation of why authentication has not yet completed, so that a client that does not implement this specific task, but does implement SASL2 authentication, can still inform its user rather than simply reporting a failed login.
This specification defines the urn:xmpp:tos:0 namespace, used to qualify the elements defined below, and one SASL2 task, identified in <task/> and <next/> elements by the token TOS-ACCEPT.
Once the SASL exchange has succeeded, the server determines whether this task applies to the authenticating account, per the following rules (see also Business Rules):
There is no account against which an anonymous authentication's acceptance can be reliably recorded. A server that requires this task for anonymous authentication MUST therefore offer it on every anonymous authentication attempt, rather than only the first.
The task does not apply if it has already completed earlier in this same negotiation. This matters because eligibility is re-evaluated after every task completes, not just once, so a task that already ran is not offered again merely because a later round is reached.
Otherwise, the task applies if the account has not accepted the version that is currently applicable. Acceptance of a prior version does not count: what is tracked is acceptance of a specific version, not a bare yes/no flag.
When the task applies, the server offers it as it would any SASL2 task, in a <continue/> element. It MUST include human-readable <text/> explaining why authentication has not yet completed.
TOS-ACCEPTThe terms of service have changed and must be accepted before you can sign in.
]]>
]]>
On selection, the server sends the current terms in a <task-data/> element, carrying a <terms/> element. Its content is the URL at which the terms can be read, and its version attribute identifies the version being offered for acceptance.
https://example.org/terms
]]>
The client responds with a <task-data/> element of its own. To accept, it includes an <accept/> element whose version attribute repeats the version it was offered.
]]>
A peer that does not wish to accept, or that does not implement this task at all, has no way to decline while continuing the negotiation: per Extensible SASL Profile (XEP-0388)XEP-0388: Extensible SASL Profile <https://xmpp.org/extensions/xep-0388.html>., it can only abort, which fails the entire SASL2 negotiation and leaves the session unauthenticated.
]]>
On receiving the client's response, the server determines the outcome per the following rules:
If the response contains no <accept/> element, the server MUST fail the SASL2 negotiation with a <not-authorized/> condition.
If the response contains an <accept/> element whose version attribute does not match the version that was offered in this round, the server MUST fail the SASL2 negotiation with a <malformed-request/> condition (rejecting, for example, a value cached from an earlier attempt).
Otherwise, the task completes for this negotiation. The server SHOULD persist the acceptance against the account, so that it is not asked again on a future connection. If the account is authenticating anonymously, or the acceptance cannot be persisted (for example due to a transient failure of the server's own backing store), no durable record results; the task still completes, but the server SHOULD offer it again on the account's next authentication attempt, since there is nothing on record to rely on next time.
Once every eligible task, including this one, has completed, the SASL2 negotiation concludes as usual with <success/>.
A server MUST NOT complete SASL2 authentication for an account for which this task applies (see Determining Applicability) unless the task has completed successfully during the same negotiation.
A server MUST offer this task on every anonymous authentication attempt for which it applies (see Determining Applicability), since acceptance cannot be reliably recorded against an account that does not exist.
A server SHOULD treat "currently accepted version" as a per-account fact rather than a per-session one: once durably recorded, the same account is not asked again on a later connection unless the applicable version changes or no durable record was actually made (see Outcome).
A server MAY treat acceptance obtained through a channel other than this task (for example a support interaction or a signed agreement) as satisfying acceptance of a version, provided it is recorded per-account in the same way. This task exists to enforce acceptance for accounts that have not already accepted through such a channel, not to be the sole route by which acceptance can be recorded.
A server SHOULD treat the version identifiers it issues as opaque and SHOULD compare them for exact equality, both when checking whether a previously-recorded acceptance is still current and when validating a peer's <accept/> against the version it was offered in the same round.
This task is a policy and record-keeping mechanism, not an authentication factor. It MUST NOT be treated as contributing to the strength of the authentication that preceded it, and does not protect against an attacker who already holds valid credentials: by the time this task runs, the SASL exchange has already succeeded.
This task, like any SASL2 task, is only evaluated as part of a SASL2 negotiation. If a server also offers an authentication path that bypasses SASL2 entirely, for example the legacy SASL profile of RFC 6120, an account can authenticate through that path without this, or any other, SASL2 task ever being evaluated. A server that needs to guarantee acceptance before granting access MUST NOT offer such a path to accounts this task applies to, or MUST enforce the same requirement by some other means there. This limitation applies equally to any mandatory SASL2 task, not just this one.
A server that cannot durably persist an acceptance, for example due to a transient failure of its own backing store, MAY still let the negotiation continue rather than fail it outright (see Outcome): the peer did explicitly accept during this negotiation, which is what the task exists to establish. Since no durable record exists in that case, the server SHOULD offer the task again on the account's next authentication attempt, so that a persistence failure results in the user being asked again rather than the requirement being silently and permanently bypassed.
Because completion of this task changes an account's compliance record, a server SHOULD only offer, and only accept a response to, this task over a channel that satisfies its usual requirements for authenticated sessions, per whatever channel-binding or TLS policy already governs the SASL2 negotiation in which it is offered; this specification does not introduce a separate requirement.
The terms URL communicated in the <terms/> element is typically dereferenced by a human outside of the XMPP session (for example by opening it in a browser). Server operators should serve it over a secure and integrity-protected transport, but validating that is outside the scope of this specification.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA).
This specification defines the following XML namespace, which the XMPP Registrar shall add to its registry of protocol namespaces (XMPP Registrar Function (XEP-0053)XEP-0053: XMPP Registrar Function <https://xmpp.org/extensions/xep-0053.html>.):
urn:xmpp:tos:0
This specification also defines the SASL2 task token TOS-ACCEPT. Extensible SASL Profile (XEP-0388)XEP-0388: Extensible SASL Profile <https://xmpp.org/extensions/xep-0388.html>. defines no central registry of task tokens; as with the UPGR-* tokens defined by SASL Upgrade Tasks (XEP-0480)XEP-0480: SASL Upgrade Tasks <https://xmpp.org/extensions/xep-0480.html>., uniqueness is expected to follow from the token being sufficiently distinctive, checked against existing task-defining specifications during the XSF's normal review process.
The protocol documented by this schema is defined in
XEP-xxxx: http://www.xmpp.org/extensions/xep-xxxx.html
Identifies the current terms of service. Sent by the server, as the
content of a element, after this task has been selected.
Sent by the client, as the content of a element, to accept
the identified version of the terms of service.
]]>