<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 17 December 2014 at 13:24, Kurt Zeilenga <span dir="ltr"><<a href="mailto:kurt.zeilenga@isode.com" target="_blank">kurt.zeilenga@isode.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><br><div><blockquote type="cite"><div>On Dec 17, 2014, at 3:52 AM, Dave Cridland <<a href="mailto:dave@cridland.net" target="_blank">dave@cridland.net</a>> wrote:</div><br><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 17 December 2014 at 05:15, Kurt Zeilenga <span dir="ltr"><<a href="mailto:kurt.zeilenga@isode.com" target="_blank">kurt.zeilenga@isode.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br></blockquote><div><br></div></div></div></div></div></blockquote><div><br></div></div></span><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><span class=""><div>We'd also probably not be having this discussion, which is beginning to become quite useful.</div></span></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div></div></div></blockquote><div><br></div><div>It's the only tool I have to prevent this becoming a XEP prior to the discussion.<br></div><div><br></div><div>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.</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div></div></div><div><span class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>No, you asked specifically what the authors could do; I gave an answer to that.</div></div></div></div></blockquote><div><br></div></span>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.</div><div><br></div><div>It seems you are holding this ProtoXEP hostage for a general discussion and possibly more (“a better system”?).</div><div><br></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>So the protocol applies to a 4-tuple of (Subject,Object,Namespace,IqType) - Subject and Object are explicitly jids.</div><div><br></div><div>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.<br></div><div><br></div><div>So, as an important point: The specification is DUPLICATING EXISTING FEATURES, and making them WORSE.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So what we have is something masquerading as an access control mechanism that's really a protocol-level IQ filter.</div><div><br></div><div>Let me repeat this, because it's important:</div><div><br></div><div>Allowing MAM access to SEARCH also grants MAM access to CONFIGURE, because the access if defined by what <iq/> stanzas to FILTER.</div><div><br></div><div>Now, how to fix this?</div><div><br></div><div>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 <a href="mailto:kurt.zeilenga@isode.com">kurt.zeilenga@isode.com</a>", or "The GeoLoc PEP node on <a href="mailto:dwd@dave.cridland.net">dwd@dave.cridland.net</a>").</div><div><br></div><div>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.</div><div><br></div><div>Honestly? I don't think a "better system" is much of a stretch.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>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?</div></div></blockquote><div><br></div><div>All good questions.</div><div><br></div><div>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.</div><div><br></div><div>In particular, external access to read rosters is the only requirement here, unless I've misunderstood something badly.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>So, with that in mind, what if the discussion stalls?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>It'd be simpler if the protocol was just limited to the immediate requirement.</div><div><br></div><div>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.</div><div><br></div><div>So with that in mind:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">At some point you simply change your vote?</div></blockquote><div><br></div><div>No, that's not happening.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">  Or do you change what you ask the authors for?</div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">  Or do you really going to hold out until the authors to recast their document in the ABAC model and terminology?</div></blockquote><div><br></div><div>*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.<br></div><div><br></div><div>Dave.</div></div></div></div>