On 7 April 2014 10:04, Philipp Hancke <fi...@goodadvice.pages.de> wrote:
> The alternative is we just say "Components are privately-authenticated S2S >> connections", and invoke BiDi and SASL auth and make it happen. This is >> functionally equivalent, but differs in that components are no longer >> special in any way (aside from near-mandatory support for XEP-0288), >> aren't >> backwards compatible with the older protocol, which becomes obsolete. That >> appeals to my sense of purity, and is likely significantly more secure in >> a >> number of ways. (At the very least, the security profile would be better >> understood). >> > > Well, I think the primary differences are that > a) components will appear in disco#items > I think that's orthogonal, actually - you could list ancilliary services hosted on "full" S2S via disco#items as well. For example, a site might choose to host their FT proxy or media relay on entirely different hosting to their IM services. So I suspect that while components are *often* listed, they're not always. Besides which, my proposal isn't that components wouldn't need provisioning of their own - it's just a protocol change, not a deployment one. > b) a server won't attempt to connect to a component > > That's not strictly true either, but again, I think you'd provision components nonetheless - this is purely unifying the protocol. They'd need to be provisioned, possibly given a password, and so on. There's an implication here that a component *could* be connected to, as well, but you'd obviously need to manually specify the endpoint in the server's configuration. However, by "moving on" from XEP-0114, we'd be able to reduce the attack surface - it'd be no different to C2S/S2S from a security standpoint (though possibly with additional considerations given "trusted" components and allowed spoofing, etc). Dave.
