[Standards] Veto on "Privileged Entity"

Dave Cridland dave at cridland.net
Tue Dec 16 23:33:02 UTC 2014

On 16 December 2014 at 22:05, Dave Cridland <dave at cridland.net> wrote:
> On 16 Dec 2014 21:21, "Kurt Zeilenga" <kurt.zeilenga at isode.com> wrote:
> > And can I draw the conclusion you think XACML is the “standard industry
> model and terms” specification that you want this work “recast” in?
> No, but it uses the same ABAC model as of NIST and others. None of these
> specifications are particularly approachable, but they're largely in
> agreement as regards terms and model.
In particular, the terms PDP, PEP, and Subject are all in common between
XACML's specifications and NIST SP 800-162:


NIST talk about Objects whereas XACML discuss Resources, NIST use Operation
where XACML uses Action. I'm not wed to one in particular, and certainly
not to XACML (which I think is pretty cumbersome for most, if not all,

But I think the model is consistent (though XACML expands it to include
multiple Subjects; for example when you're only allowed to view a document
if your boss has given you the OK - you're the Access SUbject, your boss is
another kind of Subject I forget the description of).

I'm happy to use (and refer to) the NIST terms to avoid any suggestion of
mandating XACML if that makes people happier.

> Using the same model would, of course, mean that one could hand
> authorization decisions to a standard XACML PDP, but wouldn't have to, and
> I doubt many would want to.
To give some kind of concrete example I think both Rosters and vCards are
Objects having a "Read" operation. I think that the vCard's "Publish"
operation is distinct to the Roster's "Subscription Modify". Maybe
"Publish" is actually just a nice generic "Write"; modifying a roster isn't.

Because of this protoXEP's existence, we need to have an "ACL Modify"
operation operating on any Object. And yes, even having an ACL as such is
just side-stepping a PDP and manually changing the policy, but let's assume
that in the case where you *have* an external PDP you don't grant the "ACL
Modify" to anyone, including the owner.

Now all we need to do is apply some kind of identifier to those and we're
basically done - "urn:xmpp:roster", say, or "urn:xmpp:auth:object:roster" -
then we just add in an auth request protocol.

As written, all objects have to be referenced as only a jid, and the
operations are defined as tuples of an XML namespace and an IQ type. This
satisfies the needs - probably - of Rosters and vCards, but it's contingent
on those being somewhat akin to read/write permissioning. By defining a
consistent model, it's trivial to extend to, say third-party MAM access. We
could rewrite Hats, or PEP/Pubsub/Buddycloud access into the same framework

On the face of it, this looks like almost a purely syntactic change from
the perspective of this particular ProtoXEP; the difference is that it's
based on a stable model, and the next author to come along gets to reuse
it; and I'm really not convinced that's the case at present.

And yes, if people *do* want to use external PDPs, then whether they're
using OpenAZ or XACML Contexts over SOAP, it'll be easy to do that, too.
Also easy is a standardized audit trail, and so on.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20141216/10e3310e/attachment.html>

More information about the Standards mailing list