In many XMPP applications it is desirable to be able to act anonymously to prevent leaking personally identifiable information (PII) to a third party. Traditionally this is accomplished using SASL authentication and the ANONYMOUS mechanism as detailed in &xep0175;, however, the ANONYMOUS mechanism is in reality an authorization mechanism and does not provide authentication of users.

This specification solves these problems by decoupling anonymous identity management from authentication (auth) and authorization (authz). This allows logged in users (authenticated or anonymous at the server operators disgression) to request a new temporary identifier, a "burner" JID, which may be used by its owner to construct a new session with the server that is authorized to communicate anonymously with third parties and is (optionally) locally authenticated.

Burner JID

A temporary JID that is not valid for the purpose of authentication but which may be authorized by an existing pre-authenticated session.

Ephemeral identity

The identity of a user on the server comprising a burner JID and any other associated data.

Authentication identity

The users normal identity and JID which they use to authenticate with the server and create new XMPP sessions.

• As a user concerned about spam I want to join a public chat room anonymously to prevent JID harvesting.
• As the author of a social website I want to allow users to create ephemeral identities which can be used to contact them even if they have not granted access to their personal information.
• As a server operator I want to allow users to act anonymously, but also want a way to rate limit the creation of ephemeral identities associated with a given authentication identity.

Services that support issuing burner JIDs MUST advertise the fact in responses to &xep0030; "disco#info" requests by returning an identity of "authz/ephemeral".

The user requests an ephemeral identity from the server or another XMPP service by sending an IQ containing an "identity" payload qualified by the urn:xmpp:burner:0 namespace.

If the service wishes to issue an ephemeral identity to the user it replies with a new burner JID:

The burner JID MUST be a bare JID. Burner JIDs are not valid for the purpose of authentication, but may be authorized to perform actions. To use the burner JID the client then attempts to establish a new session with the server using the account that requested the burner JID as the authentication identity and the burner JID as the authorization identity as defined in &rfc4422; §2. If the server does not support SASL, or does not support any SASL mechanisms that support authorization identities, burner JIDs cannot be used.

Services MAY choose to support listing burner JIDs by responding to "disco#items" requests on the "urn:xmpp:burner:0" node. Such services must advertise a feature of "urn:xmpp:burner:0" in response to disco#info requests.

This implies that services may choose to only support listing burner JIDs or requesting burner JIDs by advertising the feature or the identity, respectively. Most services will likely wish to advertise both.

The result of a disco#items request is a list of "item" elements with a "jid" attribute containing the burner JID. Burner JIDs that expire MAY include an "expires" attribute containing a timestamp in the UTC timezone conforming to the datetime profile specified in &xep0082;. Note that the lack of an "expires" attribute does not indicate that the JID never expires, just that the expiry date is unknown. Burner JIDs are ephemeral and services MAY remove them at any time.

It may be impractical to store verification information for every burner JID issued by the system. To this end servers that implement this specification MAY choose to encode information into the localpart of issued burner JIDs which can be verified when a user attempts to authorize a new session to use the burner JID. If an implementation chooses to do this it is RECOMMENDED that an &nistfips198-1; be used. This HMAC MAY include the JID of the associated authentication identity, an expiration or issued time for the burner JID, session information, TLS channel binding data, or any other information the server wishes to verify. The format of this key or its input values is left as an implementation decision.

As with persistent JIDs, the client MUST NOT assign any meaning to the localpart or resourcepart of a burner JID.

To prevent burner JIDs from being abused for spamming, implementations SHOULD rate limit all burner JIDs in use by an authn identity as a single unit. However, be advised that this may provide a third party that can monitor traffic patterns with the ability to determine what burner JIDs belong to the same user. To prevent a burner JIDs authn identity from being discovered the same way, burner JIDs SHOULD NOT share a rate limit with their authn identity.

If TLS channel binding information is encoded in the local part of the burner JID and the TLS version in use is 1.3 or greater, it is RECOMMENDED that the tls-exporter channel binding value defined in &cbtls13; be used. For versions of TLS less than 1.3, tls-unique SHOULD be used as defined by &rfc5929; §3. Note that unless the master-secret fix from &rfc7627; has been implemented tls-unique channel binding information does not include enough context to successfully verify the binding when resuming a TLS session.

Implementations that choose to encode information in the localpart of burner JIDs should take care when choosing a hash function. For current recommendations see &xep0300;.

This docment requires no interaction with the &IANA;.

An XML Schema will be added before this document reaches the status of "draft".

The author wishes to thank Philipp Hancke for his feedback.