[Standards] Proposed XMPP Extension: Privileged Components

Dave Cridland dave at cridland.net
Thu May 15 20:24:42 UTC 2014


On 15 May 2014 21:02, Goffi <goffi at goffi.org> wrote:

> Hi,
>
> thanks for your feedback
>
> Le 2014-05-15 10:15, Dave Cridland a écrit :
>
>> I suspect Section 4.1 is entirely unnecessary - a component either
>> needs admin rights or doesnt, and this would be provisioned within the
>> server.
>>
>
>
> A component may need to know if it has privileges granted, e.g. to offer
> different features (a PubSub service may enable or disable roster
> access-model if it is privileged or not).
>
> 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 don't
think we want a request.


>
>
>> Section 4.2 seems like a reasonable idea on the face of it. I wonder
>> if we couldnt reuse stanza forwarding here. I dont think this needs to
>>
>> be limited to components, and I think the general processing by the
>> server ought to be to send the stanza from target bare jid, relaying
>> responses back, something like:
>>
>> <iq to=user at example.com [2] from=user at example.com/resource [3]
>> type=set id=123>
>>
>>   <privilege><!-- or something -->
>>     <forwarded>
>>       <iq to=someone at example.net [4] type=get>
>>
>>          <foo/>
>>       </iq>
>>     </forwarded>
>>    </privilege>
>> </iq>
>>
>
>
> Indeed that's 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' to 'juliet at example.com' type='get'
> id='roster1'>
>         <query xmlns='jabber:iq:roster'/>
> </iq>
>
>
That's the best way to access particular resources as the component,
certainly. If you want to send stanzas as the bare jid, though, it won't
work.


>
> I'm not sure to understand well you example, can you be more explicit
> about which one it the component, which one the client, which one the
> target ? Maybe a concrete use case would help here.
>
>
In my examples, there's no component - a user's client is, here, wanting to
send stanzas from the bare jid, in effect. A component might wish to send
stanzas from other bare jids. As you say above, there's no need to do this
to access, for example, the user's roster, but accessing, say a remote
pubsub service as the user needs some kind of relaying.


>
>  Section 5, I worry over - I dont think components which arent
>>
>> explicitly provisioned in the server are really going to work. That
>> said, expanding the stanza relaying thing from Section 4.2 across to
>> all clients probably works for most use cases.
>>
>
>
> Actualy that's a new step in decentralisation, and that's better for
> security: A client can choose to host its own gateway or pubsub service,
> sometimes it's the only way to do. For example the spectrum skype gateway
> only works by wrapping skype client, which mean 50 mb memory on each
> connexion. That's not acceptable for a production server with thousand of
> accounts, but in this case a client can host the component himself. I think
> component unliked to the server are needed.
>
>
Right, but how does the component authenticate, how does the server know to
route stanzas to it, who sets up the DNS, etc?

I wouldn't let arbitrary domains be hosted unwittingly on my server,
certainly.

We can, though, have clients act as Skype gateways - that's entirely fine.


>
>  The bit I was expecting to see, and didnt, was a protocol for trapping
>>
>> and/or intercepting specific namespaces. I think a small amount of
>> expansion of Section 4.2 should do the trick, something like:
>>
>> <iq to=user at example.com [15] from=user at example.com/resource [16]
>> type=set id=789>
>>   <privilege>
>>     <handle stanzas=* namespace=.../>
>>   </privilege>
>> </iq>
>>
>
>
> That's already planned in a separate XEP that I need to write, « namespace
> delegation ». The feature is not in privileged component because you may
> want to delegate a namespace (e.g. vcard-temp) without giving privileged
> access, it's an other thing.
>

OK.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20140515/ee199ab4/attachment.html>


More information about the Standards mailing list