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: RE: Policies with No Subject

Title: RE: Policies with No Subject
Colleagues - I strongly support Hal's view.
(His third paragraph does contain an implicit definition of the term "privilege" which conflicts with my use of the term.  But, that is not material to this discussion.)
I envisage XACML 1.0 defining informative "bindings" for some common policy distribution mechanisms (the Web, ODBC, LDAP) that explain how to locate and retrieve the XACML policy statement for a specified resource/action combination.  So, the schema of this mechanism will probably be based on the structure of resources and their actions.  The policy statement will be executed by an XACML virtual machine, the operation of which is defined in the one normative XACML meta-policy.  The virtual machine must obtain just the parameter values indicated in the policy statement.  These may include attributes of the subject, but they don't have to.
If a parameter is not included in the policy statement, then it does not have to be considered in the policy evaluation.
All the best.  Tim.

Tim Moses
Tel: 613.270.3183

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Thursday, September 20, 2001 11:15 AM
To: 'Ken Yagen'; xacml@lists.oasis-open.org
Subject: RE: Policies with No Subject

I am working on a paper that will describe my ideas more fully, but briefly here is the argument.
Policy evaluation has two phases. 1. identifying the policies that apply to particular request 2. execute the policy evaluation algorithm
There is a somewhat arbitrary choice of which inputs to apply to each phase. However, since resources are distributed and control is federated it makes sense to organize them by the resources they apply to, so that they can be located physically close to the resources and their administrators. This suggests that resource and closely related items such as action must always be specified, so it is possible to determine which policies apply.
Privilege is something I consider to be completely synthetic and may not necessarily even be present in a policy model at all. For example, the AssureAccess policy model does not currently contain the notion. We map to resources and actions. Privilege, as it is typically used, is actually a target aggregator, in the same way group is a subject aggregator. A priviledge is a shorthand name for some collection of resources and methods that are considered to be similar from an access control perspective.
-----Original Message-----
From: Ken Yagen [mailto:kyagen@crosslogix.com]
Sent: Wednesday, September 19, 2001 7:54 PM
To: xacml@lists.oasis-open.org
Subject: RE: Policies with No Subject

I was not at the F2F and did not hear the discussion, but I wouldn't think it to be too unreasonable to consider subject differently than location, time, and other policy variables. Along the same lines you could frame arguments that privilege and resource are not necessary. You can have a user or role that have access to all resources or can perform any kind of transaction with a particular resource. I think it is pretty well accepted that there are a lot (but not all) policies that refer to a subject and that makes it important enough to be considered as a required part of the policy language.

Ken Yagen
Director, Software Development
CrossLogix, Inc

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Wednesday, September 19, 2001 2:26 PM
To: xacml@lists.oasis-open.org
Subject: Policies with No Subject

At the F2F I asserted that a policy could contain zero or more subjects. The
use of a policy with zero subjects was questioned. My answer was that if the
policy did not consider any information about a subject, there was no need
for a subject in the policy. For example, if the policy says the resource
can be accessed between 24:00 and 6:00, there is no need to specify a

At the meeting several people agreed that in a case like this, there would
still be a subject. There would be some kind of indicator that it applied to
all subjects, such as "*" or "ALL". I conceded this possibility at the time
and the discussion turned to other topics.

I now believe that this is illogical. I assume that policies can take as
inputs items such as the date and time, network location, method of
authentication and so on. Therefore, if a policy that does not consider
subject information must contain "all subjects" then logically a policy that
does not consider time must contain "all times", a policy that does not
consider location must contain "all locations" and so on.

This would obviously cause every policy to become encrusted with useless
junk. I think it is clearly much simpler to put into each policy just the
items that need to be evaluated and leave out the others. The point is that
I consider subject to be just one type of input that may or may not be used
for policy decisions.


To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

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

Powered by eList eXpress LLC