Pedro Melo wrote: > Why not say: > > * "encrypted" channel: a casual sniffer will not be able to see the > the messages, but it is susceptible to MITM attacks; > * "trusted" channel: a encrypted channel in which the certificates > presented where verified by some method (SRP, SAS, CA signature, GPG > Web-of-trust, other).
Sounds ok to me >>> - We need a delegation system, that separates "user identity" from >>> "resource" or "client" identity, so that a user can delegate the >>> right to connect to an account to devices, like set-top-boxes or >>> cell phones. For this a server-based management of this delegation >>> and revocation is needed >> >> If you mean the "Hosted solutions" thread than I agree. If not, please >> explain. > > I also don't understand this. Are you talking OAuth-style stuff, > where I can give some third party a token that its valid for him to > connect as me? IMHO OAuth is kind of stupid. I have to trust a server I do not know. No, the point is that I can upload a certificate to my XMPP server and the owner of that certificate (a bot, a client I do not trust) can log in using SASL-EXTERNAL as me without having the password. > Yes, what do we need from the server? In a perfect world I would hope > not to have to go through the server apart from the Jingle > negotiation? Ok, and IBB-Jingle fallback. In that case we need a SOCKS5 proxy or a TURN server. I prefer the TURN server but we lack ice-tcp support to use it. I also need the server to help me find a TURN server I can use if I need one. So after setup you do not need the XMPP server anymore if you have a direct connection and you only need a TURN server if not. If you have some firewall problems or no TURN server you need the XMPP server for IBB. Dirk -- How can something be 'new and improved'? If it's new what was it improving on?
