[Standards] Veto on "Privileged Entity"

Kurt Zeilenga kurt.zeilenga at isode.com
Wed Dec 17 05:15:43 UTC 2014


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.

But now your demand seems now that the authors recast their protoXEP to use the ABAC model and terminology when there hasn’t been the greater discussion and for which you think might actually be “way too difficult”.  This seems like a absurd request to make of the protoXEP authors.

As you put it, this is a “specification (that) describes a very specific solution to a very specific problem”.  Your goal is "a single model for access control”, aside from being simply unrealistic given that XMPP is a general messaging framework supporting a wide range of applications, should be viewed as completely beyond the scope of this ProtoXEP.  And even if you limit the scope of your goal to some particular application using XMPP such as say IM or MUC, you are going to have a hard time getting to a single model of access control, especially where the one you are promoting is one of the two access control (role and rule based) models explicitly specified for us.

You are asking the authors to re-cast their work away from a model they understand, which the community understands, and which has already been used in XMPP and arguably patterned after after existing use in XMPP, to a model which is likely alien to the authors, alien to many in this community, and for which there seems no use of ABAC for the authors to pattern their use after.  This seems unlikely to lead to an improvement in the quality of this ProtoXEP nor progress towards your goal.

I content that the XMPP standards community has not accepted the use of the ABAC model and/or its terminology as being appropriate for describing XMPP authorization services.  I content that the ABAC terms are not “industry terms of art” of access control in application level protocols, they are terms associated specifically with the ABAC model.  The ABAC model terms are not terms of art for the RoleBAC nor the RuleBAC models, two of the models explicitly used in XMPP currently.

While I have no problem with council members suggesting terminology changes to improve the readability of the particular ProtoXEPs before them, this does not seem to what is driving your demand to “recast” this ProtoXEP.   If it were, I would content that the ABAC terminology is obtuse and alien to many application protocol developers and to many in the XMPP community.  The ABAC terminology use, for instance at the IETF, is pretty much limited to AAA protocols.  It not commonly used in application protocol specs, including specs detailing complex authorization services.  if one was simply desiring to improve the readability of the ProtoXEP, I think we would be far better for the authors to simply be self-consisent as well as consistent with the specs they (directly and in some cases indirectly) reference.   I note that RFC 6120 references RFC 4949 for some of its security terminology and if one is keen on following established patterns, one set by RFC 6120 is probably a reasonable choice.

— Kurt




More information about the Standards mailing list