[Standards] Proposed XMPP Extension: Privileged Components

Goffi goffi at goffi.org
Thu May 15 21:48:39 UTC 2014

Le 2014-05-15 22:24, Dave Cridland a écrit :
>> Furhtermore, Binary suggested to use permission even in admin mode
>> (without user confirmation in this case): a server may want to only
>> allow "jabber:iq:roster get" to a component. We can use this phase
>> to aknowledge the component of which permissions are granted.
> We could possibly use a "do I have permission to do X" query, but I
> dont think we want a request.

Ok, that's seem a good option

>> Indeed thats an option. Binary suggested that the <priviledge/>
>> wrapping is unnecessary: the top level <iq/> is enough, as we just
>> need the bare jid to know which client we want to access. The
>> example 4 would then simply be:
>> <iq from=pubsub.capulet.net [4] to juliet at example.com [5] type=get
>> id=roster1>
>>         <query xmlns=jabber:iq:roster/>
>> </iq>
> Thats the best way to access particular resources as the component,
> certainly. If you want to send stanzas as the bare jid, though, it
> wont work.

Well the main idea was to access particular resources, I had mainly a 
pubsub service in mind. And I think that's good enough for that and 

But if you wants to send arbitrary stanzas (well authorized stanzas) on 
the behalf the client jid, that's an other level, more complexe and 
probably more difficult to secure. An entity could manage entirely 
stanzas for an other one. I can understand the need, but it's also more 
complicated to implement, to read, to debug, to secure.

Maybe it would be more appropriate in an other XEP ?

I initialy put the <privilege/> wrapping to allow this kind of stanza 
control, but I now think it's a bit too much, and I don't have any good 
use case in mind to increase the complexity.

>> In my examples, theres no component - a users client is, here,
>> wanting to send stanzas from the bare jid, in effect. A component
>> might wish to send stanzas
> are jids. As you say above, theres no need to do this to access, for
> example, the users roster, but accessing, say a remote pubsub service
> as the user needs some kind of relaying.

yes I understand. Don't you think an other XEP would be more 
appropriate ?

>> Right, but how does the component authenticate, how does the server
>> know to route stanzas to it, who sets up the DNS, etc?

Right now we lack lot of things for external components indeed. But 
actualy usual clients can manage most of the cases.

More information about the Standards mailing list