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] request's attribute assertion lifetime?



It very much looks like an element of a new data-type "type-range".
One may define operation on this datatype. (Such as "integer-in-range"
that takes an "integer" and "integer-range" parameters)

You can then define other operations on ranges, in particular allowing
non-continuous ranges, etc.

Quite solvable as an XACML extension, is not it?

Daniel.

-----Original Message-----
From: Anne Anderson [mailto:Anne.Anderson@Sun.COM] 
Sent: Monday, March 15, 2004 7:51 AM
To: Polar Humenn
Cc: XACML TC; Anne.Anderson@Sun.COM
Subject: Re: [xacml] request's attribute assertion lifetime?

WSPL also provides a way to tackle the problem of intervals.  Let
X be the attribute about which interval-type questions are
asked.  It might be a milepost on a road, a time of day, etc.
Assume the Resource Accessor's policy says "X >= 5 AND X <= 8".

1) If the Resource Protector's policy says "X >= 2 AND X <= 9",
   then the merged policy says "X=> 5 AND X <= 8", indicating
   that the Resource Accessor's entire range is acceptable.
2) If the Resource Protector's policy says "X >= 6 AND X <= 9",
   then the merged policy says "X >= 6 AND X <= 8", indicating
   that only part of the Resource Accessor's desired range is
   acceptable.
3) If the Resource Protector's policy says "X >= 1 AND X <= 4",
   then the merged policy is empty, indicating the Resource
   Accessor's desired range is completely unacceptable.

The Resource Accessor in the WSPL case doesn't get a simple
"Permit" or "Deny" answer, but perhaps this more complex result
is appropriate for the more complex concept of intervals.

Anne




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