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] another small time/date issue

Won't the initial Request go to a single PDP?  And that PDP might
invoke others to evaluate sub-policies?

If that is the case, then the initial PDP could add its concept of
"current-time/date/dateTime" to the Request context that it sends
to any other PDP for subordinate evaluation.


"Daniel Engovatov" <dengovatov@bea.com> wrote:
>Date: Tue, 12 Aug 2003 13:06:31 -0700
>>We already require these values be provided, so there's no
>>complication in keeping them constant, and this certainly isn't out of
>>scope of XACML since it defines how a standard attribute should be
>>handled during policy evaluation. This has nothing to do with
>>location or accuracy.
>But what if the evaluation is distributed?  It should be possible.
>Also, it may be a problem to keep them constant - PDP may not have the
>caching of data, and PIP may not be aware of the duration of the
>evaluation session.
>I do not think we should specify the architecture of PIP and for data
>paths provided from the virtual context - things like caching, sessions
>etc. are too specific to a particular implementation.
>Yes, that means that a time-based policy is not 100% portable, but
>nothing that rely on an external information source is 100% portable.
>For 100% portability this attribute has to be specified in the request,
>and is such a case we already state (do we ?) that it will be constant
>for the duration of the evaluation, and no further clarifications are
>>If you refer to current-time twice in a policy where the value is being
>>supplied by the PDP, one implementation might return two slightly
>>different values while another might return the same value twice. This
>>is not likely to be a huge problem, but it does represent different
>>behavior across different applications, and it can be addressed without
>>too much difficulty.
>That's what I am not sure about.  Why XACML should address the value of
>time?  If it is the accuracy that you are worried about - then we have
>to specify the expected accuracy.
>>I'm not sure what adjusting clocks has to do with this...
>If your PDPs are on different machines, they may have different clocks.
>I think we should not be in the business of synchronizing them.
>You may leave a Technical Committee at any time by visiting

Anne H. Anderson       Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
Burlington, MA         781-442-0928

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