[Standards] Proposed XMPP Extension: Internet of Things - Discovery
dave at cridland.net
Mon Apr 7 09:22:24 UTC 2014
On 7 April 2014 10:04, Philipp Hancke <fippo at 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),
>> backwards compatible with the older protocol, which becomes obsolete. That
>> appeals to my sense of purity, and is likely significantly more secure in
>> number of ways. (At the very least, the security profile would be better
> 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
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).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards