[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] [Model] Composition Use Case
anne's [test] case, and those that have preceded it have raised those points that i think are relevant to the example that i through out on the list some time ago. so instead of adding another log to the fire i have just jotted down a couple of comments. /* 1. Ability to describe Matching Rules for attributes (for example, does "A@EnergyInfoAdmin.doe.gov" match "*.doe.gov"). */ this is really the key requirement in my example: pattern matching. the only difference here from what i tossed out was that my 'case' used this against payload (content) as well has requester information. since i believe that payload is just another field i think that the generalized requirement for pattern matching meets the requirement. as pointed out earlier by a couple of people, i believe that regular expressions should be used as the basis for patterning. /* 2. Ability to apply multiple policies, possibly from different sources, to a single resource. */ i think thst this has been designated or assumed in just about all of our discussions (at least by me :o) /* 3. Ability to use arbitrary attributes, such as clearance level, in policy statements. These may be defined by the Policy Issuer. There must be a way for the PDP to obtain the definition and matching rule semantics associated with the attribute. */ i believe that this requirement ultimately speaks to the point that [i think] tim m. brought up and that is the need for discrete policy namespace assignment. since my number one goal is interoperabilty, the word 'arbitrary' scares me and i think that resolving this issue will end up being *the* key aspect of our architecture. /* a. What if, instead of "FALSE", a sub-policy can return "DenyAccess", and this means that a result of "DenyAccess" must be returned from the top-level policy? */ this is a very interesting requirement and one that i don't think that we have touched on directly (having missed the last two policy concalls, i could be wrong): non boolean policy resolution. i look forward to seeing this one on a whiteboard! :o) b
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC