%ents; ]>
Burner JIDs A mechanism by which users may request anonymous, ephemeral "burner" JIDs. &LEGALNOTICE; xxxx ProtoXEP Standards Track Standards Council XMPP Core RFC 4422 burner &sam; 0.0.1 2016-10-28 ssw

First draft.

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.

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:

hfgnINTSA-ciCLz6NhTtCD5Jr0k:1477672278884j@example.net ]]>

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 SHOULD rate limit all burner JIDs in use by an authentication identity as a single unit.

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.

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;.

Upon advancement of this proposal from experimental to draft status the ®ISTRAR; will include a category of "authz" in its registry at &DISCOCATEGORIES;. The registrar will also add a value of "ephemeral" to that category. The registry submission is as follows:

authz Services and nodes that provide authorization identities. ephemeral An authorization service that provides ephemeral identities. XEP-XXXX ]]>

Future submissions to the XMPP Registrar may register additional types.

This specification defines the following XML namespaces:

  • urn:xmpp:burner:0

Upon advancement of this proposal from experimental to draft status the registrar will include the foregoing namespaces in its registry at &NAMESPACES; as governed by &xep0053;.

&NSVER;

TODO.

The author wishes to thank Philipp Hancke for his feedback.