[Standards] Veto on "Privileged Entity"

Kurt Zeilenga kurt.zeilenga at isode.com
Tue Dec 16 18:24:23 UTC 2014


> On Dec 16, 2014, at 10:02 AM, Goffi <goffi at goffi.org> wrote:
> 
> 
> I'm curious to see some other opinions on this subject.

While I have not formed a particular opinion with regards to the ProtoXEP worthiness to become a XEP or not as I simply have not read it, I am generally of the opinion that publication of XEPs as Experimental should only rarely be blocked by the council.

I think hope that the community might do something “better” is a poor reason to block an ProtoXEP.   I would prefer council members only block ProtoXEPs where it is at least council consensus that publication will actively harm a currently active standardization effort in a manner which cannot be mitigated (such as asking for additional text at the top of the XEP that offering an alternative to the XEPs of the active standardizations efforts).

I would rather the hope for something “better” be exercised by either working with the authors of the ProtoXEP to make it “better” or, if that doesn’t work, propose an alternative.

Blocking of XEPs tend to lead to folks simply going elsewhere for their publication needs.

— Kurt

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