Re: [xacml] request's attribute assertion lifetime?

[Frank Siebenlist <franks@mcs.anl.gov>]

It just intrigues me why we have this InstantIssue element of the attribute 
defined? What was the use case for that?

-Frank.


Frank Siebenlist wrote:

> I understand all the arguments, except that if you want to run scenarios 
> where you want to test the access control decision in some point in the 
> future by playing with the environment's notion of time, you're unable 
> to note the possible expiration of the attribute assertions...
> 
> Furthermore, if we move to a model where we will accept individual 
> authorization assertions as policy statements, and with these assertion 
> is a validity interval associated, then we won't be able to store them 
> in the database but will be forced to revalidate them before we feed 
> them to the PDP/PAP every single time we use them.
> 
> It will also allow you to associate a upper-bound to the validity time 
> interval of a decision.
> 
> Maybe we should make the checking of time validity a mandatory thing in 
> the xacml engine, meaning that we optionally associate validity 
> intervals with attribute and policy statements, and if they are present, 
> they will always be checked with the evaluation time. So, no need to 
> write any policy rule tests for time validity as it will be done for you 
> automatically and always.
> 
> -Frank.
> 
> 
> Polar Humenn wrote:
> 
>> On Thu, 4 Mar 2004, Frank Siebenlist wrote:
>>
>>
>>> I just came accross the fact that the request's attribute element has an
>>> optional InstantIssue element to indicate the date and time at which the
>>> attribute was issued, but you can't seem to specify a duration 
>>> validity interval.
>>>
>>> Any reason for that?
>>
>>
>>
>> All values attributed to resources, subjects, and actions pertinent to
>> the Access Decision Request should be validated for the request. (Another
>> reason why the PDP shouldn't supply the "current-time", a serious fault,
>> IMHO). The XACML Policy does not do validation. The PDP performs access
>> decisions based on valid information.
>>
>> The reason for this approach, is that we did not want XACML to become a
>> validation engine.  The business of checking signatures, validity times,
>> handling cryptographic computational complexity, is all out of scope, and
>> that is easily divided and pawned off on some other entity, so XACML will
>> have to complicate is job with those matters.
>>
>> As far as Time goes, I never liked IssueInstant being in the
>> ReqeustContext. Furthermore, you can't search on it using a
>> AttributeDesignator, so it's existence is really moot, except, I guess,
>> for the XPath folks.
>>
>> Cheers,
>> -Polar
>>
>>
>>
>>> Regards, Frank.
>>>
>>> -- 
>>> Frank Siebenlist               franks@mcs.anl.gov
>>> The Globus Alliance - Argonne National Laboratory
>>>
>>> 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