[Standards] Veto on "Privileged Entity"

Dave Cridland dave at cridland.net
Wed Dec 17 17:06:10 UTC 2014


On 17 December 2014 at 16:14, Goffi <goffi at goffi.org> wrote:
>
> 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.
>
>
OK, I entirely forgot about that. And in fairness, I think Section 6 is
reasonable; I think Sections 4 and 5 are the problem.


>
>  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 ?
>
>
This document is not about building an external PEP service; this document
- or at least sections 4/5 of it - is about access control.

In this case, as I wrote, every PEP node already has an access-model, and
applying a different access model based service-wide around the iq type is
clearly both duplicating the access control of PEP, and making it worse,
and failing to interact properly.


>  Now, how to fix this?
>> [SNIP]
>>
>> 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.
>
>
Well, that's sort of the problem - the protocols are already defined on a
per-extension basis, and you've applied a generic solution across the top.
The two just don't fit.


>  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.
>
>
I really think it's worth addressing just the immediate requirements to
begin with.


>
>  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).
>
>
Like the roster access-model already in PubSub? (I'm pretty sure M-Link
does this already for PEP nodes).


>
>  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 ?
>
>
A client *can* manage its own PEP service, can't it? This protocol would be
enabling it to manage someone else's, surely? Moreover, if you want to run
your own PEP service as a client, you only need the other protoXEP, not
this one.


>
>  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 pointed out the problem with MAM, for example. I have no idea what else
is there, but there are problems with PEP as above (and Pubsub and MUC in
the same way), and MAM. I wondered about Search, and anything involving
ad-hoc is clearly a bit weird.


>
>  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
>
>
You're asking server administrators to understand the protocol-level issues?

But anyway, the problems basically all derive from this being generic.


>
>  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.
>
>
You know you could just write a server? You needn't bother with S2S; you
can just run yours as a component into another one. PEP/Pubsub-onna-jid is
*way* harder to do than the rest of C2S, and I suspect it's actually easier
than doing all this proxying.


>
>  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 ?
>
>
Basically, unless you really want to do the ocean-boiling exercise of doing
this properly - and I really don't dispute that it's hard work - then why
not strip this down to just section 6 for now?

Roster access is just a matter of configuration, and the same - more or
less - with PEP; so that would get you the critical features much sooner.

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141217/4165d66a/attachment.html>


More information about the Standards mailing list