[Standards] Proposed XMPP Extension: Privileged Components

Goffi goffi at goffi.org
Thu May 15 20:02:14 UTC 2014


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.


>
> 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>


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.


> 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.


> 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.


Cheers
Goffi




More information about the Standards mailing list