[Standards] Veto on "Privileged Entity"

Dave Cridland dave at cridland.net
Wed Dec 17 14:53:45 UTC 2014

On 17 December 2014 at 13:24, Kurt Zeilenga <kurt.zeilenga at isode.com> wrote:
> On Dec 17, 2014, at 3:52 AM, Dave Cridland <dave at cridland.net> wrote:
> On 17 December 2014 at 05:15, Kurt Zeilenga <kurt.zeilenga at isode.com>
> wrote:
>> While your OP implies that “we” (presumedly “the community”) should take
>> a step back and consider model and terminology issues, in your latest
>> comments, it seems more that you want the authors to adopt a this model and
>> terminology you originally wanted “we” to consider.
>> While I would not have issue if you. independent of consideration of this
>> ProtoXEP opened a discussion about how to model XMPP authorization services
>> and what terminology should be used, I think it inappropriate to put this
>> ProtoXEP on “hold” pending such discussions.  As you note in your OP, such
>> an effort might not pan out.
> We'd also probably not be having this discussion, which is beginning to
> become quite useful.
> Obviously in absence of some other instigation of this discussion, yes, we
> wouldn’t be having it.   Aside from my concerns of use of a veto to
> instigate this discussion, I must note that the stink of this discussion
> might well have been much different if had been instigated in a less
> combative way.   Any general discussion instigated by veto is going to be
> tainted by that veto.
It's the only tool I have to prevent this becoming a XEP prior to the

Any communication at all instigated by a rejection of any kind will often
by tainted by that light; but that's not a reason to avoid a veto. But
thanks for pointing out how disruptive to a conversation an antagonistic
communications style can be.

> No, you asked specifically what the authors could do; I gave an answer to
> that.
> Yes, I asked because you failed to provide the authors with any action
> they could take to remedy your objections with the ProtoXEP.
> Unfortunately the actions you suggest they take to cure your objections are
> far worse than the authors doing nothing, hoping that for whatever reason
> you change your vote.  Which shows, I think, demonstrates inappropriate
> your veto is.
> It seems you are holding this ProtoXEP hostage for a general discussion
> and possibly more (“a better system”?).
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.

So the protocol applies to a 4-tuple of (Subject,Object,Namespace,IqType) -
Subject and Object are explicitly jids.

It is unscoped as far as namespaces go, meaning that it can be applied to
Objects which have pre-existing access models; the specification includes
examples based around PEP, for example, which - being PubSub - already has
Affiliations on a per-node basis which control operations on a finer level.
I really think this is a bad idea, in part because it's unclear what would
take precedence.

So, as an important point: The specification is DUPLICATING EXISTING
FEATURES, and making them WORSE.

It is, quite clearly a general model for authorization; but it's a very odd
model. While it's probably reasonable to assume that a Subject is always
describable by a jid, a jid is not sufficient to describe an Object; the
spec hand-waves about a jid describing multiple Objects too. Arguably, an
Object is really described by a jid and a namespace here; this means that
the namespace portion of the rule serves a double purpose.

The method of denoting what would in other models be an Operation (or
Action) is by the 2-tuple of namespace and IQ type. This is problematic
because it is both insufficiently fine-grained for some cases, and bound to
the wire protocol rather than the Object itself. For example, to allow MAM
access would mean to allow both get and set IQs, but that also allows MAM
configuration as well as search.

So what we have is something masquerading as an access control mechanism
that's really a protocol-level IQ filter.

Let me repeat this, because it's important:

Allowing MAM access to SEARCH also grants MAM access to CONFIGURE, because
the access if defined by what <iq/> stanzas to FILTER.

Now, how to fix this?

It's possible that you'll agree that by defining Objects in terms of a set
of attributes (or tuple of identifiers if you prefer) we can express
specific Objects more accurately ("The PEP service on
kurt.zeilenga at isode.com", or "The GeoLoc PEP node on dwd at dave.cridland.net

Operations are more complex, because the extensions themselves currently do
not have a consistent model, but I think a taxonomy of operation
identifiers wouldn't be *that* hard. And of course, we've got Disco to
figure out if a service supports the new AC model, and we don't have to
write the whole vocabulary at once.

Honestly? I don't think a "better system" is much of a stretch.

So what happens now if say this general discussion stalls?   At some point
> you simply change your vote?  Or do you change what you ask the authors
> for?  Or do you really going to hold out until the authors to recast their
> document in the ABAC model and terminology?

All good questions.

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.

In particular, external access to read rosters is the only requirement
here, unless I've misunderstood something badly.

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.

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.

So, with that in mind, what if the discussion stalls?

Well, I'm not going to simply drop my objection. If there's no interest in
properly solving access control in XMPP - and I do assert that *is* a
problem, and needs a solution - then that doesn't mean this protoXEP is
going to suddenly become acceptable in my view.

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

I *think* the mechanism described is only definitely safe for vCard and
Roster. I don't think it's sufficiently specific for Private XML, and in
any case PEP should work for those cases.

It'd be simpler if the protocol was just limited to the immediate

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.

So with that in mind:

At some point you simply change your vote?

No, that's not happening.

>  Or do you change what you ask the authors for?

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.

>  Or do you really going to hold out until the authors to recast their
> document in the ABAC model and terminology?

*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.

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

More information about the Standards mailing list