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] Concrete Proposal of ConditionReference (#7)



I don't want to re-open this discussion, but just for the record...

> This "current-time" attribute name is still burning us. The RequestContext
> is "notional", but the information in it is not. All information must be
> there. The Request must contain the "current-time" attribute (if used).
> 
> The PDP has no concept of "current" time. I've said this time and time
> again. :)
> 
> You must supply the current-time in the RequestContext.  It is valid to
> ask if Alice has access to a resource at any time, whether or not that
> time is said to be "current" in reality.
> 
> A PDP that supplies a value for the current time attribute is not correct.
> It is the XACML Request Handler that will supply that attribute.
> Therefore, in your scenario, your two requests would actually be
> different.

The specification clearly states in 10.2.5

   If values for [current date/time] are not present in the decision
   request then their values must be supplied by the PDP. So, unlike
   most other attributes, their semantics are not transparent to the
   PDP.

I don't think it gets any clearer than that. A PDP that supplies these 
values is not only correct, it's a requirement.

Do I think this is "burning us"? No. I do think, however, that since 
these attributes are special-cases, it's ok to call them out. That's why 
I suggested that we make those constrained over an evaluation (which I 
think was picked up for 2.0).

>>There is no such requirement in XACML. The RequestContext is amorphous,
>>and therefore gives you no guarentees about anything remaining constant.
> 
> If there isn't, it should be. I don't have the spec in front of me, but I
> believe we mandated that a long time ago. At least I know I did.

No. There is no such requirement, and I don't agree that there should 
be. I do agree that there's value in a ValueRef stype statement that 
lets you explicitly constrain values over the course of an evaluation, 
but that's a separate issue.

> Time information is like any other information in the request. There is no
> notion of values changing throughout the coarse of an evaluation.
> Implemenations that do so, may play that card in some hopes for
> efficiency, as Daniel may have taken advantage of. However, those that do,
> and do so in a way that yields different results for the same request are
> in violation. Any "clarifications" to that effect of specific attributes
> are redundant, and could lead to implications that for all other
> attributes it is not the case unless specified.

Let's be clear here. Implementations that allow referenced values to 
change over the course of an evaluation are _not_ in violation of the 
1.0 or 1.1 specification. It is perfectly legal, and indeed expected, 
that the same Request may yield different Responses. There is nothing in 
the specification that says otherwise. I have re-read the specification 
several times in the last week, and I cannot find any language that says 
otherwise (other than the explicit statement about functions, which I 
mentioned in my earlier mail). Therefore, clarifications for the new 
def/ref mechanism are very useful.


seth



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