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.
