OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xacml] What I learned from yesterday's telecon


Title: What I learned from yesterday's telecon

Colleagues - I learned a couple of things from our telecon yesterday ...

1. A policy is the complete combination of rules governing access for a particular authorization decision request.  A policy will often be too complicated for a human to work with it, in toto, directly.

2. A rule is the largest fragment of policy that a human can work with directly.  Yes, the definitions are circular and, in the case of "rule", vague.  Of course, there is no objective way of telling whether a fragment of policy is too big for a human to work with directly or not, but existing work suggests that a triple, containing a definition for resource, action and subject, fits the definition.

3. A rule will often mimic the administrative GUI in which policy is written and analyzed.
4. A rule is an artifact entirely internal to the administrative system.
5. A policy is an artifact visible external to the administrative system.
6. In many cases, policies will actually turn out to be a set of rules combined in some relatively simple way, according to one of a few common meta-policies.

One camp argues that rules should be reflected in the syntax of the language.  Another camp says, the syntax of the language should be perfectly general.  Then it will be possible, but not necessary, that a policy be constructed from sets of triples combined in some simple, prescribed, way.  But, it will be up to implementations of policy-writing software to determine what the form of a policy will actually be.  Both arguments have some appeal.

In the first case, it may be practical for developers to write and read policies directly in the language.  This, at least will help with debugging the tools that others will use to manipulate instances of the language.  However, I wouldn't expect a policy administrator to work directly with XACML instances.  On the other hand, can we really be confident that limiting policies to be simple combinations of triples will be sufficiently general for all our uses?

Personally, I like the idea that a general logical combination of predicates or references to other policy instances would be a valid XACML instance.  Implementations can always build their policies in the form of triples combined by simple logical formulae, if they wish, and these would be valid XACML.  But, the language wouldn't limit us to this approach.  Naturally, administrative GUIs would hide the details of XACML instances from administrators; quite possibly presenting it in the form of "rule triples".  But, PDPs would be built to process arbitrarily-complicated combinations of predicates.  The general predicate type could be extended to provide sub-types for resource predicates, subject predicates, etc..

In informative material, we can provide guidance to implementers on how to produce a policy based on rule triples with "grant", "deny" and "only_if" effects.

It would certainly be possible to specify a syntax for a rule, as well.  But, this doesn't serve any interoperability goal.

Thoughts?  All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC