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.

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 that support issuing burner JIDs MUST advertise the fact in responses to &xep0030; "disco#info" requests by returning an identity of "authz/ephemeral":

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 MAY 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 it is RECOMMENDED that the tls-unique channel binding value be used as defined by &rfc5929; §3. Note that unless the master-secret fix from &rfc7627; has been implemented 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;.

TODO.

The author wishes to thank Philipp Hancke for his feedback.