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: [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

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)


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

Powered by eList eXpress LLC