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] | [List Home]

Subject: Re: [xacml] RE: [xacml-comment] Public Comment

Polar Humenn wrote:

> Of what purpose would this serve in the standard?

> It might serve as a product instruction manual which is a single 
> monolithic PDP saying that there is one policy which is the root of that 
> PDP, which is either a PolicySet or Policy.

> If you are pulling out relavant policies out of an LDAP server (only for 
> example), then where is this "root"?

the composition of the PDP is irrelevant.

"i" don't pull down anything. a PDP--be it one machine or a million--is 
distilled to a context. since, by definition, a PDP is queiriable there 
is something that externally represents that context. it therefore seems 
reasonable that the entity representing that context may also be asked 
about its Guiding Principles.

this is of value in my mind because i believe that one of the potentials 
for XACML is to provide the basis for auditing security systems. the 
ability to determine the version support/employed is of value here.

i also believe that as we explore delegation/distribution that the 
ability for a PEP to "shop" for compatible PDPs may also be of use.

finally, if you look at the obligations proposal on the wiki you will 
see that we have introduced the concept of hierarchical decision making 
to distill obligations into an unambiguous decision, even though the 
number of obligations possible is unbounded. this requires the context 
to apply an obligation hierarchy. i don't believe that this can be 
addressed in a policyset as it stands today.

i am sure that there are other examples that can be of use in this model.

i agree that this information is not applicable in the clean room model 
of policy language. however, since we all pretty much agree that XACML 
(XML) is not a real-time operational language i suggest that we need to 
focus on those aspects that will allow it to improve interoperability. 
one of the ways to do this is to create a mechanism that allows 
disparate machinery to determine what it is dealing with.


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