Initial Version
When clients (or initiating servers) connect, thanks to &xep0388; there is now a single waited-for round-trip after the connection itself is established, before the exchange of stanzas can occur. This is because after sending the stream open, the initiator cannot know the features (and thus what SASL2 etc options are supported) until it has received them, and until it does receive them, therefore cannot know what the optimal features and suboptions are to negotiate.
Although specifications such as &xep0484; suggest that pipelining is feasible, clients which do so risk "missing out" on improved security and other features.
This protocol, herein "IAP", therefore allows a server to provide a token which is tied to what features are available, which the client then uses to indicate the basis of its authentication attempt. If this does not match, the authentication attempt is rejected without prejudice, and can be retried with the currently available features.
Note that the protocol is explicitly possible for both C2S and S2S.
If a server supports IAP, this is indicated by a stream feature, consisting of an element of config-version, qualified by the namespace urn:xmpp:iap:0. This has two attributes, first, a optional scheme, which has the value (if present) of "opaque". Second, a mandatory value, for which the value is as defined below.
When an initiator wishes to pipeline the <authenticate> with the stream open, it first caches the known config version, and sends this in a similar <config-version>, with the same optional scheme and value attributes as used by the responding entity, as a child of the <authenticate>.
The responder then attempts to match this value against its own current value before proceeding - the precise meaning of match depends on the scheme, though a simple string comparison MUST always be a match.
If a responder sees such an element and it does not match the current value, the responder rejects the <authenticate> with a <failure> "without prejudice", meaning that the attempted authentication is not counted as a "failed login", the account is not penalised or locked out, etc.
The failure SHOULD be of type <aborted>, and carry an application-specific error of <config-version-mismatch>, qualified by the 'urn:xmpp:iap:0' namespace.
Otherwise, the SASL2 authentication proceeds as per normal.
Config versions have schemes, which denote how the server calculates the version. The only defined scheme in this specification (so far) is "opaque", and all token schemes are compatible with "opaque".
The "opaque" scheme is a token which the client MUST NOT (and cannot) derive any meaning from.
While the server is in principle free to include any structured data such that it can "match" a token even if the current configuration differs, typically it would be expected that additional SASL mechanisms, SASL2 subfeatures, etc would be cause to reject the token (as the client might have wished to negotiate these instead or as well). Therefore such "smart" matching is both out of scope for this specification and moreover - until more implementation experience is gained - NOT RECOMMENDED
An exact match (ie, identical tokens by "i;octet") with the currently advertised value MUST be treated as a match.
One example of a conformant mechanism for generating the value would be to generate a hash or HMAC of the rendered features, absent the <config-version>. Note that the initiating entity MUST NOT assume this mechanism is in use, nor attempt to calculate any such hash itself.
Here is the flow from XEP-0484 (FAST), as a single example including the full stream and with annotations to indicate packets and round-trips.
Servers which attempt interpretation of matching non-identical tokens can cause clients to miss opportunities to improve their security, or gain new features (which might include security features). So again, this remains NOT RECOMMENDED.
There is a temptation to stuff the entirety of the initial pipelined send into TLS 0-RTT early-data; that is also NOT RECOMMENDED because it may allow for replay attacks. However, where explicit protection is in place for replay (such as FAST) this is acceptable.
This document requires no interaction with &IANA;.