RE: [xacml] Re: Questions and notes on the JSON Interface specification

[Hal Lockhart <hal.lockhart@oracle.com>]

Interesting question.

1. NaN, -INF, +INF and -0 are definitely NOT Javascript specific. They are defined in IEEE 754.

2. For double, XACML core cites XML Schema Second Edition (2004). (http://www.w3.org/TR/xmlschema-2/#double) XACML core also cites IEEE 754-1985. IEEE 754-1985 defines NaN, -INF, +INF, +0 and -0. Schema Second edition differs from IEEE 754-185 in that it defines all NaNs to be the same and -0 and +0 to be the same. 

3. The current XML Schema is XML Schema Definition Language (XSD) 1.1. It cites IEEE 754-2008. Further schema now says that +0 = -0, but they are not identical. It also says that NaNs are not equal to each other. This aligns it with IEEE 754 (new and old).

I have not studied exactly where core depends on Schema and where it depends on IEE 754. But I have reached the following conclusions.

A. XACML PDPs should have been able to handle these values all along. 

B. There is potential ambiguity as to the precise behavior required by XACML when using these values. (I sincerely hope nobody's policies depend on whether NaN = NaN.)

C. We should update the references to Schema and IEEE 754 while checking for changes which may impact XACML.

Hal

> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@viewds.com]
> Sent: Thursday, February 06, 2014 4:53 PM
> To: xacml@lists.oasis-open.org
> Cc: david.brossard@axiomatics.com; glenngriffin@research.att.com
> Subject: [xacml] 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
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>