<p dir="ltr"><br>
On 16 Dec 2014 18:03, "Goffi" <<a href="mailto:goffi@goffi.org">goffi@goffi.org</a>> wrote:<br>
> even if I understand your point of view, I have the feeling to see the famous<br>
> XKCD strip: let's do a new standard which cover everyones use cases<br>
> (situation: 15 competing standards) !<br>
></p>
<p dir="ltr">That's actually what I'm trying to avoid; we currently have lots of fractional solutions, and no real standard.</p>
<p dir="ltr">> The XACML protocol is more than 150 pages, I can't see any XEP adapting this<br>
> to XMPP coming before years, and even if we see that one day, I don't think<br>
> anybody will implement that (for the record: we are proposing XEPs to have an<br>
> external implementation of PubSub because to my knowledge none of the server<br>
> has a complete implementation, so we can't bring a decent microbloging system<br>
> to XMPP; if XEP-0060 is not fully implemented, what about a potentially larger<br>
> XEP ?)</p>
<p dir="ltr">XACML is indeed huge, and there are several specifications involved. I'm not suggesting we make that mandatory, merely that we make that possible, by using a model that is compatible, and using the same terms of art used in the field.</p>
<p dir="ltr">At least, where possible.</p>
<p dir="ltr">> The Privileged Entity protoXEP is quite simple and do the job, it can be<br>
> implemented in a couple of hours in most servers, and it solve several issues.<br>
> In addition if some day we actually see an XACML implementation with XMPP, we<br>
> can still obsolete the Privileged Entity.<br>
></p>
<p dir="ltr">Yes, the question is whether we can find a mechanism which is both this simple, and also fits the model that other systems use already.</p>
<p dir="ltr">> So I think putting a veto on this is really severe, and will delay<br>
> microbloging implementations in XMPP for years. We are curently several<br>
> projects stucked with current state of PubSub and PEP implementations, and<br>
> having an external PEP service is an option generic and available quickly.<br>
></p>
<p dir="ltr">I'd be very interested in knowing what's missing here. I'm sure other server developers would be as well.</p>
<p dir="ltr">> I'm curious to see some other opinions on this subject.<br>
></p>
<p dir="ltr">As am I. A veto position need not be permanent, and I'm hoping we can find the beginning of a solution, and agree a path forward, instead of simply blocking progress.</p>
<p dir="ltr">> Cheers<br>
> Goffi<br>
><br>
> Le mardi 16 décembre 2014, 16:12:00 Dave Cridland a écrit :<br>
> > Folks,<br>
> ><br>
> > At the last Council meeting, I entered a position of -1 concerning<br>
> > Privileged Entity:<br>
> ><br>
> > <a href="http://xmpp.org/extensions/inbox/privilege-component.html">http://xmpp.org/extensions/inbox/privilege-component.html</a><br>
> ><br>
> > In order to explain my position better, it's worth examining how<br>
> > authorization systems currently model the world. I'm going to use XACML<br>
> > terms here, although in practise these are industry terms of art in most<br>
> > cases.<br>
> ><br>
> > In any access decision, there are a number of "subjects" - at least one,<br>
> > the "Access Subject", and possibly others (an "Authorizing Subject",<br>
> > perhaps). The decision is whether or not to allow the "Access Subject" to<br>
> > perform an "Action" on a "Resource".<br>
> ><br>
> > The decision is required, and enforced, by a Policy Enforcement Point, or<br>
> > PEP. The PEP gathers information, and sends it to a Policy Decision Point,<br>
> > or PDP. The PDP returns a decision. There are also Policy Information<br>
> > Points, which act as information gatherers - typically these might be<br>
> > querying LDAP directories or SQL databases.<br>
> ><br>
> > For our purposes, the XMPP server is mostly considered here as acting as a<br>
> > PEP.<br>
> ><br>
> > A key issue is that the PDP can be (and often is) external to the PEP, and<br>
> > centralized. There are standards for this (such as XACML) which allow both<br>
> > policies to be expressed and also define PEP->PDP wire protocols. Most<br>
> > modern standards are now focussed on Attribute Based Access Control, which<br>
> > are particularly fine-grained.<br>
> ><br>
> > Currently we have three explicit, and one implicit, authorization<br>
> > mechanisms in XMPP:<br>
> ><br>
> > 1) The Affiliations of MUC and PubSub. This is a Role Based Access Control<br>
> > mechanism with fixed roles.<br>
> ><br>
> > 2) The Security Information Object mechanism of XEP-0258, used for<br>
> > protective marking schemes. This is, again, a Role Based Access Control<br>
> > mechanism of sorts, with definable Roles. Interestingly, this has a<br>
> > configurable policy.<br>
> ><br>
> > 3) MUC Hats, which is a fairly straightforward Role Based Access Control<br>
> > system using user-defined Roles. Nobody, so far as I know, implements this,<br>
> > but it was defined on the perceived need of finer-grained access control to<br>
> > chatrooms.<br>
> ><br>
> > 4) The implicit permissioning of Rosters and vCards, wherein the owner has<br>
> > access and nobody else.<br>
> ><br>
> > All of these are fairly inflexible, do not integrate with external PDPs,<br>
> > and are all RBAC.<br>
> ><br>
> > The ProtoXEP in question was aiming at defining another, new, RBAC system<br>
> > which also would have a fixed role, fixed policy.<br>
> ><br>
> > Although the outcome is desirable - that is, replacing (4) above with a<br>
> > more flexible system - I'm concerned that this is patching a specific<br>
> > problem rather than addressing the broader view of where the state of the<br>
> > art in access control is.<br>
> ><br>
> > Instead, I think we should take a step back and try to cast our<br>
> > authorization model in the form the current ABAC standards can work with;<br>
> > ideally getting us to a point where enterprise PDPs could be used if needed<br>
> > to provide centralized policy control.<br>
> ><br>
> > In particular, this means clearly defining the resources involved, the<br>
> > actions available - both generic actions and in some cases specialist ones<br>
> > - and then look at how we can generically authorize subjects.<br>
> ><br>
> > The result of this might be "woah, this is way too difficult", but I'd<br>
> > rather say that after exploring the are properly - (3) above has done much<br>
> > of this work already for MUC, so clearly there is *some* interest.<br>
> ><br>
> > Dave.<br>
><br>
</p>