On Fri, Oct 28, 2016 at 1:51 PM, Philipp Hancke <fi...@goodadvice.pages.de> wrote: > It was not clear to me what the shared secret is used for here
I originally had a different mechanism drafted out for this that used a shared secret. Turns out I had several things left over in the document from when I removed the other mechanism; there is no shared secret anymore. Will remove the reference; thanks! > Since the user part of the JID is exposed to other clients how are replay > attacks prevented? That's a good thing for the security considerations; the idea was that the burner JID could only be used by the owner of the real JID that created it. Servers should verify that the burner JID is only used from within a session that is autenticated as the user that created the burner JID. > Security considerations: > - should those JIDs be traceable to the account that created them for the > operator? I think that is desirable, also to limit the number of such jids. Agreed. Burner JIDs should keep you anonymous from third parties (other servers, MUC participants, etc.), but not from your server operator. For anonymity from the server operator as well, use SASL ANONYMOUS. > It makes them pseudonyms at most though which is ok for the use-cases that > this XEP wants to address. Full anonymity... is a hard claim. Agreed; realistically they're just temporary alias' for your JID. > Registrar considerations: > An authorization service that provides ephemeral "burner" identities. > I would remove "burner" here. Wilco. Thanks! —Sam -- Sam Whited pub 4096R/54083AE104EA7AD3 _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
