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, ANONYMOUS auth provides no mechanism for changing identities (requesting a new JID) without creating a new session, and server operators may not wish to allow anonymous authentication to prevent abuse.

This specification solves these problems by decoupling anonymous identity management from authentication. This allows logged in users (anonymous or otherwise at the server operators disgression) to request a new temporary identifier, a "burner" JID, which may be used by its owner in any context where they would normally use their persistent primary JID.

• A server or service is able to issue a unique ephemeral identity to a user that supplies the server or service with a public key.
• A user is able to generate any number of burner JIDs from using their private key which can be verified against their ephemeral identity on the server.

Burner JID

A temporary JID that is not valid for the purpose of authentication but which may be used in place of the authentication identity in a pre-authenticated session.

Ephemeral identity

The identity of a user on the server comprising a shared secret and any associated burner JIDs or other stored information about the user.

Authentication identity

The users normal identity and JID which they use to autenticate 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.

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:

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

It may be impractical to store verification information for every burner JID issued by the system. To this end it is RECOMMENDED that the localpart of a burner JID be an HMAC-SHA-2 which includes the users JID or another unique identifier, an expiration or issued time for the burner JID if appropriate, TLS channel binding information, session information, or any other data 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 a given authentication identity as a single unit.

When a users session ends it is RECOMMENDED that any ephemeral identities associated with their session be purged.

If TLS channel binding information is encoded in the burner JID it is RECOMMENDED that the tls-unique channel binding value be used as defined by &rfc5929; §3. However, for resumed sessions the JIDs SHOULD be considered invalid unless the master-secret fix from &rfc7627; has been implemented because otherwise resumption does not include enough context to successfully verify the binding.

This docment requires no interaction with the &IANA;.

TODO.