[Standards] Veto on "Privileged Entity"
goffi at goffi.org
Wed Dec 17 16:14:15 UTC 2014
On 17/12/2014 15:53, Dave Cridland wrote:
> It's the only tool I have to prevent this becoming a XEP prior to the
The XEPs was submitted months ago (first mention on standard@ in may !),
we could have this discussion before.
> What we have, currently, is a proposal for a XEP which describes a
> authorization model operating solely on <iq/> stanzas, and applying
> rights based on identities, on the granularity of namespace and IQ type.
That's not true, it also operate on <message/> and <presence/> which
were mandatory to have notifications in an external PEP component, look
at section 6, « special permissions ». It is indeed based on identities.
> So, as an important point: The specification is DUPLICATING EXISTING
> FEATURES, and making them WORSE.
Can you be more explicit ? Which features exactly are duplicated ? How
could I build an external PEP service with current XEPs ?
> Now, how to fix this?
> Honestly? I don't think a "better system" is much of a stretch.
OK, that's more constructive. But how to have fine grained attribute in
a generic way, when everything is really on a per-XEP basis.
> The actual driving requirement of this protoXEP is, as I understand it,
> to make possible external components supporting PEP, because the servers
> don't implement the parts of PubSub-onna-jid needed for Microblogging.
> So instead, the authors have proposed that servers implement an entirely
> new access control system.
The driving requirement is indeed to have an external PEP component, but
not only: we want to decentralize things which are currently the private
garden of servers, including PEP or accessing roster, stocking data -
which is actually a matter of PEP implemention -, etc.
> In particular, external access to read rosters is the only requirement
> here, unless I've misunderstood something badly.
No it's not the only one. It need to send messages and access presence
(for notifications). The roster access is actually to have experimental
feature (the equivalent of google +'s circles or Diaspora's aspects).
> Personally, it's not clear this needs actual protocol, so much as
> component configuration, but assuming we consider the client-mode case -
> which I suspect is pretty scary at the best of times - then a much
> simpler, finely-scoped, protocol is all that's needed.
What if the client wants to manage its own PEP service ? Or have a local
gateway which manage its roster ?
> But taking the specification at face value, it's defining a generalized
> access control system for XMPP, and one that appears to be ignoring all
> the state of the art and possibly as a result seems dangerous, broken,
> or both.
experimental status is here to try implementation and discover what is
really dangerous or broken. If you say that it "seems dangerous, broken,
or both" but you're not actually pointing the actual security issue,
that's a bit light for an argumentation.
> I would be unhappy about it if it were simply restricted in scope; so if
> this document were re-presented with a restriction to just rosters (and
> other things which fit the model) I wouldn't automatically assume it was
> safe, but that's probably a sensible next step if nobody wants to fix
> the general case, and yet there's something more than read-access to
> rosters required.
That would make no sens to restrict the XEP, its purpose is to be
generic, and restrictions have to be applied by server administrator, as
specified in section 11
> My actual preferred solution to the immediate problem of microblogging
> in PEP remains for servers to implement the extra bits in their PEP
> services, though; this being why I've asked Goffi specifically about
> what's missing.
That's not an option for us: even if one server implements what we need,
we need a generic option which works everywhere. In addition we are
doing experimentations and we have/need a quick development cycle, which
is incompatible which being blocked by servers' development cycles.
We already have an external PubSub component which satisfy our need or
is going to to it (we are currently implementing RSM and MAM on it), we
can concentrate our development efforts on our immediate needs.
> If there's no appetite to solve the general case properly, I'd ask the
> authors whether they really need a protocol here, and if so, to just
> define the one they need.
I think we have already proved that we are involved in fixing the more
cleanly as possible our problems. We have been to Berlin summit to talk
about that, we have submitted 3 XEPs lastly (the XEP-0351 by Binary, and
my 2 protoXEPs), we have developed our own PubSub component, etc. So yes
there is definitely appetite to solve problems.
The issue here is what is feasible, quickly if possible, and what is
not. Implementing a 150+ pages protocol and adapting it to XMPP is not
feasible in my opinion, adapting a XEPs and fixing it according to
pertinent technical critics is something we have to do for sure.
But remember we have also tons of work beside this, I try to fix the
protoXEPs according to feedback and to reply to messages, I'm open to
criticism, but if we don't want to stay in proprietary hack or dirty
options, we need to have something doable in a reasonable amount of time
with our man power.
> *This* document, with *this* scope - if a document wants to define an
> access control and authorization system for the whole of XMPP, it'd
> really better define some kind of a workable model, or at the very least
> there'd better be some inclination within the community to do so.
So do you suggest to throw the current protoXEP ?
More information about the Standards