[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xacml] Re: env attributes
Attempt to elaborate: if we are to have a build-in standard time attribute it should be on PDP, otherwise it is hard to use it in a policy (if having a policy based on the time of decision is what you want). If you do not want to have a policy based on the time of decision, then we should probably let the implementation to decide when, where and how the relevant time is computed and placed into the context. If we see too many problems with "build-in" clock, I would agree to drop it altogether, although I think that some reference decision time clock is a useful feature (not only for decision, but also for such sanity checks, like not granting access three years in the future, or in the last century..).. Daniel; -----Original Message----- From: Seth Proctor [mailto:seth.proctor@sun.com] Sent: Wednesday, October 23, 2002 1:13 PM To: Daniel Engovatov Cc: 'Polar Humenn'; Anne Anderson - Sun Microsystems; XACML Subject: Re: [xacml] Re: env attributes On Wed, Oct 23, 2002 at 01:01:30PM -0700, Daniel Engovatov wrote: > Disagree. For time based policy having the time passed in is not always > safe. > If it is needed - it is easy to do, just add an attribute, but if you are > going to have a build in time it has to be server side for auditing and > safety. Could you elaborate here? I agree that a "built in time" would need to be in the PDP, but I think Polar was suggesting that this feature get removed, in which case there is no need for the PDP to resolve this data, so it's just another attribute and doesn't require any special auditing or safety at the PDP. seth
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC