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?



If you take the approach that all attributes have validity intervals, then
they may have many validity intervals. Hmmm, how about the Cantor set?

Furthermore, which "valid" and "invalid" attributes do you include in the
Request? How old? How new? How long?

For instance, the Request Handler would have to have some special concept
of time, and for what the PDP access decision is expeciting of
access-time, so it can supply the right valid (or currently yet to be
valid), attributes to supply.

Where do you draw the line?

-Polar

On Mon, 15 Mar 2004, Frank Siebenlist wrote:

> Ann just beat me to it ... while trying to make the equivalent point about
> WSPL's capabilities, I checked my email one more time ... it must have something
> to do with those great minds and such ;-)
>
> The use case that I've brought up a number of times on different occasions is
> that scheduler application that is running scenarios of service invocation
> requests where it tries to match-up different resource availabilities. For these
> scenarios, the authorization decision query is not about a single point in time,
> but for a time interval: "Is the requester allowed to make use of the resource
> from T1 till T2?".
>
> Furthermore, as I tried to argue before, decisions for a single time T are not
> very useful in practice and we rely on unspoken, implicit time-intervals for
> which we assume the validity of that decision.
> This simplification works well if the time interval between decision and
> enforcement are "small" (seconds-minutes) compared to the validity times
> associated with the assertions used (days-months-years).
>
> In our grid applications, we already work with identity/attribute/authorization
> assertions that have lifetimes of hours. This will most certainly overlap with
> the time intervals used for the scenario testing.
>
> The other advantage is of course caching of authorization decision results. If
> we have a good way to reason about the time validity of results as they relate
> to the associated time validity of the assertions these results are based on,
> then we might be able to reuse those decisions without having to go through a
> potentially expensive reevaluation.
>
> -Frank.
>
>
> Anne Anderson wrote:
>
> > 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
> >
> > On 15 March, Polar Humenn writes: Re: [xacml] request's attribute assertion lifetime?
> >  > From: Polar Humenn <polar@syr.edu>
> >  > To: Frank Siebenlist <franks@mcs.anl.gov>
> >  > Cc: Daniel Engovatov <dengovatov@bea.com>, XACML TC <xacml@lists.oasis-open.org>
> >  > Subject: Re: [xacml] request's attribute assertion lifetime?
> >  > Date: Mon, 15 Mar 2004 10:28:44 -0500 (EST)
> >  >
> >  >
> >  > Greetings,
> >  >
> >  > Spring Break is over, I am back :)
> >  >
> >  > On Wed, 10 Mar 2004, Frank Siebenlist wrote:
> >  >
> >  > > [snip]
> >  >
> >  > > Time is different than any other attribute as it moves in predictable ways. This
> >  > > is not a philosophical observation but is truly used.
> >  >
> >  > True, which is exactly why we shouldn't go diving into throwing XML
> >  > attributes around to solve a complicated problem without major study.
> >  >
> >  > XACML presently defines access control on attributes assumed to be valid,
> >  > whether that validity is based on time, issuer, signatures, which is all
> >  > up to the Request Handler. Admittedly, we do not have a specification for
> >  > the Request Handler (of which I think Daniel would like).
> >  >
> >  > I can forsee, however, some form of XACML to handle the problem of
> >  > intervals, but if needed, as an extension, and only after significant
> >  > research in the area. Please keep in mind that intervals not only apply to
> >  > time. For instance, "Is Alice allowed on section of road R between points
> >  > A and B?"
> >  >
> >  > We may tackle this problem by forming a specific committee to study the
> >  > issue for Intervals Based XACML or some such thingy. There is a lot of
> >  > research in temporal logics and such that may be helpful. However, I would
> >  > like to see a significant interest in the subject and commitment to study
> >  > before we attempt to solve one small use case, which can be solved by
> >  > formulating attributes in the way that Daniel described.
> >  >
> >  > Cheers,
> >  > -Polar
> >  >
> >  > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
> >  >
> >
>
> --
> Frank Siebenlist               franks@mcs.anl.gov
> The Globus Alliance - Argonne National Laboratory
>


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