<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 16 December 2014 at 22:05, Dave Cridland <span dir="ltr"><<a href="mailto:dave@cridland.net" target="_blank">dave@cridland.net</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"><span class=""><p dir="ltr">On 16 Dec 2014 21:21, "Kurt Zeilenga" <<a href="mailto:kurt.zeilenga@isode.com" target="_blank">kurt.zeilenga@isode.com</a>> wrote:<br>
> And can I draw the conclusion you think XACML is the “standard industry model and terms” specification that you want this work “recast” in?</p>
</span><p dir="ltr">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.</p></blockquote><div>In particular, the terms PDP, PEP, and Subject are all in common between XACML's specifications and NIST SP 800-162:<br></div><div><br></div><div><a href="http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf">http://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.sp.800-162.pdf</a><br></div><div><br></div><div>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, cases).</div><div><br></div><div>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).</div><div><br></div><div>I'm happy to use (and refer to) the NIST terms to avoid any suggestion of mandating XACML if that makes people happier.</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">
<p dir="ltr">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.</p></blockquote><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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 trivially.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Dave.</div></div></div></div>