[Standards] Veto on "Privileged Entity"

Goffi goffi at goffi.org
Tue Dec 16 18:02:28 UTC 2014

Hi Dave,

even if I understand your point of view, I have the feeling to see the famous 
XKCD strip: let's do a new standard which cover everyones use cases 
(situation: 15 competing standards) !

The XACML protocol is more than 150 pages, I can't see any XEP adapting this 
to XMPP coming before years, and even if we see that one day, I don't think 
anybody will implement that (for the record: we are proposing XEPs to have an 
external implementation of PubSub because to my knowledge none of the server 
has a complete implementation, so we can't bring a decent microbloging system 
to XMPP; if XEP-0060 is not fully implemented, what about a potentially larger 
XEP ?).

The Privileged Entity protoXEP is quite simple and do the job, it can be 
implemented in a couple of hours in most servers, and it solve several issues. 
In addition if some day we actually see an XACML implementation with XMPP, we 
can still obsolete the Privileged Entity.

So I think putting a veto on this is really severe, and will delay 
microbloging implementations in XMPP for years. We are curently several 
projects stucked with current state of PubSub and PEP implementations, and 
having an external PEP service is an option generic and available quickly.

I'm curious to see some other opinions on this subject.


Le mardi 16 décembre 2014, 16:12:00 Dave Cridland a écrit :
> Folks,
> At the last Council meeting, I entered a position of -1 concerning
> Privileged Entity:
> http://xmpp.org/extensions/inbox/privilege-component.html
> In order to explain my position better, it's worth examining how
> authorization systems currently model the world. I'm going to use XACML
> terms here, although in practise these are industry terms of art in most
> cases.
> In any access decision, there are a number of "subjects" - at least one,
> the "Access Subject", and possibly others (an "Authorizing Subject",
> perhaps). The decision is whether or not to allow the "Access Subject" to
> perform an "Action" on a "Resource".
> The decision is required, and enforced, by a Policy Enforcement Point, or
> PEP. The PEP gathers information, and sends it to a Policy Decision Point,
> or PDP. The PDP returns a decision. There are also Policy Information
> Points, which act as information gatherers - typically these might be
> querying LDAP directories or SQL databases.
> For our purposes, the XMPP server is mostly considered here as acting as a
> PEP.
> A key issue is that the PDP can be (and often is) external to the PEP, and
> centralized. There are standards for this (such as XACML) which allow both
> policies to be expressed and also define PEP->PDP wire protocols. Most
> modern standards are now focussed on Attribute Based Access Control, which
> are particularly fine-grained.
> Currently we have three explicit, and one implicit, authorization
> mechanisms in XMPP:
> 1) The Affiliations of MUC and PubSub. This is a Role Based Access Control
> mechanism with fixed roles.
> 2) The Security Information Object mechanism of XEP-0258, used for
> protective marking schemes. This is, again, a Role Based Access Control
> mechanism of sorts, with definable Roles. Interestingly, this has a
> configurable policy.
> 3) MUC Hats, which is a fairly straightforward Role Based Access Control
> system using user-defined Roles. Nobody, so far as I know, implements this,
> but it was defined on the perceived need of finer-grained access control to
> chatrooms.
> 4) The implicit permissioning of Rosters and vCards, wherein the owner has
> access and nobody else.
> All of these are fairly inflexible, do not integrate with external PDPs,
> and are all RBAC.
> The ProtoXEP in question was aiming at defining another, new, RBAC system
> which also would have a fixed role, fixed policy.
> Although the outcome is desirable - that is, replacing (4) above with a
> more flexible system - I'm concerned that this is patching a specific
> problem rather than addressing the broader view of where the state of the
> art in access control is.
> Instead, I think we should take a step back and try to cast our
> authorization model in the form the current ABAC standards can work with;
> ideally getting us to a point where enterprise PDPs could be used if needed
> to provide centralized policy control.
> In particular, this means clearly defining the resources involved, the
> actions available - both generic actions and in some cases specialist ones
> - and then look at how we can generically authorize subjects.
> The result of this might be "woah, this is way too difficult", but I'd
> rather say that after exploring the are properly - (3) above has done much
> of this work already for MUC, so clearly there is *some* interest.
> Dave.

More information about the Standards mailing list