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: Questions and notes on the JSON Interface specification



All,

The comments on the xacml-dev list about the JSON profile raise a question about the
XACML double data-type in the core specification.

On Thu, Jan 9, 2014, David Brossard <david.brossard@axiomatics.com> wrote:
> On Fri, Jan 3, 2014 at 6:23 PM, GRIFFIN, GLENN (GLENN) <glenngriffin@research.att.com> wrote:
>>   - 3.4.4 says we MUST "handle" the special values NaN, INF, -INF, 0 and -0.  Several points here:
>>
>>                    - Should these _javascript_-only values be in this inter-system specification that can be implemented in any language on either server or client?
>>
>>                                    Should this section say instead: "These values must never be included in a Request or Response."?
>>
>>                    - It is not stated how the server is supposed to "handle" NaN, INF and -INF values received in a Request.
>>
>>                                    The text says that those values are passed as quoted strings like this:
>>
>>                                                    "DataType" : "integer",
>>
>>                                                    "Value" : "NaN"
>>
>>                                    We need to know what the server is supposed to do when it receives this string in a Request.
>>
>>                                    (As a point of reference, Java does not have an equivalent to "NaN", "INF", or "-INF".)
>>
>>                    - Is the server ever supposed to generate these values in a Response object?  Under what circumstances would that occur?
>>
>>                    - Likewise, what is a non-_javascript_ client (e.g. a PAP built using Java or C++) to do if it receives these values in a Response?
>
> Very good point: should we exclude these values from the specification and say that only valid numerical values are accepted? A XACML server would likely not accept such a request anyway and return an error (e.g. HTTP 500)
> This must still be handled by the server implementation elegantly anyway because nothing prevents a user from crafting a "malicious" XACML request with an attribute of type integer and value "forty-two". The parsing of the request would fail.

Glenn is incorrect in referring to the special values as "_javascript_-only".
In fact, they come from the XML Schema double data-type, which XACML adopts
as the representation for the XACML double data-type. However, the XACML
core specification is quiet about whether the XACML double data-type supports
these special values. The XACML functions that operate on double values can
produce a special value if one of the arguments is a special value, but the
one case I can think of where normal arguments can produce a special value
result (i.e., divide by zero) is explicitly defined to generate "Indeterminate"
instead. Thus it would seem that the only way a PDP can produce a special
value is if the input (an XACML attribute value) contains a special value.

Is there a use case for double special values in XACML attributes ? Do others
expect special values to be supported by XACML implementations ? Are there other
XACML implementations that support double special values ? I say "other"
because the ViewDS implementation supports them, in XML and JSON.

Regards,
Steven


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