XMPP components are used for long through &xep0114;, but are quite limited: they have a restricted access to other entities data, similar to what a client can do. This is sufficient for components like gateways, but very limiting for more complex components like a PubSub service. The goal of this XEP is to allow a component or any entity to have a "privileged" status, and access an other entity data with the same privileges than the entity itself, that means send and receive IQ stanzas on its behalf.

Privileged entity have numerous advantages, including:

• a step forward in decentralization: it is possible for an entity to do tasks which were before reserved to server itself. For example, a privileged pubsub component can offer access model based on publisher's roster
• better integration of components: a gateway can add items to an entity roster itself
• possibility to overpass a server limitation
• quick development cycle: developers can implement the components they need without waiting for a new server release
• server agnostic

A privileged entity can be used in two modes:

• admin mode, where it is installed by the server administrator
• client mode, where it can be installed by any user

In admin mode, the privileged entity MAY be able to emit IQ stanzas in the same way as any entity, including managing roster or accessing persistent storage.

In client mode, a privileged entity MUST have an explicit autorization for any IQ namespace he wants to use. Client SHOULD be able to check and revoke granted permissions, and if it's not possible, permissions MUST be revoked after a disconnection.

• Privileged entity — the entity which has or wants a privileged status.
• Managed entity — the entity that the privileged entity wants to manage.

If a server or an entity supports the entity privilege protocol, it MUST report that fact by including a service discovery feature of "urn:xmpp:privilege:0" in response to a &xep0030; information request:

1. Server MAY keep permission granted to an entity by a client from one session to an other, but if it do so, it MUST provide a way to client to check already granted permission, and revoke them (possibly using &xep0050;).
2. If a client can't check or revoke permission (e.g. it doesn't support &xep0050;), the server MUST NOT keep granted permission from one session to an other, and permission will be asked on each new session.
3. If permissions are changed during a session, server MUST notify privileged entity of the new permissions, like in permission request use case

As admin mode is far more easy to implement than client mode, a server MAY choose to only implement the former

1. Privileged entity nearly have the same possibility as the server itself, admin permission should be granted carefuly, only if you absolutely trust the entity.
2. A server MAY choose to filter allowed namespaces, to avoid giving dangerous permissions. In this case, it MUST always set the allowed type of filtered namespaces to none
3. In case of filtering, a whitelist system is more secure and SHOULD be prefered to a blacklist (idealy, configuration would allow no filtering, whitelist filtering and blacklist filtering)

This document requires no interaction with &IANA;.

Thanks to Sergey Dobrov, Dave Cridland and Steven Lloyd Watkin for their feedbacks.