diff --git a/inbox/burner.xml b/inbox/burner.xml
index de235a8b..66ac6ac3 100644
--- a/inbox/burner.xml
+++ b/inbox/burner.xml
@@ -8,8 +8,7 @@
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. + 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 anonymous to third parties but is (optionally) locally + authenticated.
+ 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. +
@@ -147,13 +157,18 @@
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-256 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. + 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.
@@ -161,12 +176,8 @@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. + 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 @@ -177,6 +188,11 @@ 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;.
@@ -197,7 +213,7 @@TODO.
The author wishes to thank Philipp Hancke for his feedback.
+