Thanks Steven for this great feedback! I will make the necessary corrections.
Re. the Subject, I willingly did not make it an array. The point is that Subject, Resource,... are for simple requests. For everything else, there's the "normal" way. Do you think that's the best way out or would you rather see array of Subject?
By the way, using Subject, Resource... brings us back to the XACML 2.0 notation :-)
On Thu, Dec 6, 2012 at 5:11 PM, Steven Legg <> wrote:
One more. The example in section 3.5 uses "value" instead of "Value".
Regards,
Steven
On 7/12/2012 10:56 AM, Steven Legg wrote:
Hi David,
Here are some issues I have noted in implementing the Working Draft 08
JSON profile (xacml-json-http-v1.0-wd08.doc).
Section 3.4.1 - The shorthand type codes for data-types use inconsistent
letter case for the first letter. We have "String", "Boolean", "Integer"
"Double", "Time" and "Date" with a leading uppercase letter, but all the
rest, e.g., "dateTime" and "anyURI", use a leading lowercase letter. I
think they should all have a leading lowercase letter for consistency
with the XACML data-type URI.
Section 3.4.3 - The special numeric values NaN, INF and -INF need to be
represented as JSON strings, i.e., "NaN", "INF" and "-INF". The data-type
would have to be explicit when an XACML attribute value has one of these
values. The special value -0 is okay as a JSON number. Since 4.2.5 expects
the array of values to all be the same JSON construct (all string or all
number), an attribute with double values would have to be represented as
two separate attributes if it contains some regular values and some
special numeric values. It would be easier if 4.2.5 allowed an array of
string and/or number for the double data-type.
Section 4.2.2.1 - RequestDefaults should be quoted and followed by a colon.
Section 4.2.3.1 & 4.2.3.2 - The JSON representation allows only a single
object for each of Subject, Action, Resource and Environment. An XACML
request may have more than one Subject, Action, Resource or Environment,
making them arrays rather than single objects. If there are multiple
subjects, etc., then an implementation can always put them in the
"Attributes" array, so I'm not fussed if you leave this the way it is.
I'm just making the point in case it's something you hadn't considered.
Section 4.2.5 - "Array of Boolean" should be added as a possible Type
for the Value property.
Section 4.2.5.1 - There should be a comma at the end of the line for "Id".
Section 4.2.5 - This section says that Datatype defaults to string if
omitted, but section 3.4.1 says the data-type can be omitted when it
can be inferred from the value. I assume 4.2.5 is wrong and Datatype
is to be inferred from the value(s) when it is omitted. For most of the
XACML data-types the data-type can be inferred from the first value.
However, the double data-type is the odd one out because an integer
number is also a double value. Scanning an array of number to see if
any number is a floating point number before deciding on the data-type
would be inconvenient. Deciding on the data-type by looking at only the
first value is easier. It needs to be stated which way the data-type is
inferred so that JSON encoders know when they need to explicitly output
Datatype for values of the XACML double data-type.
On the last TC call I agreed to write up some text for a JSON encoding
of values of the xpathExpression data-type. I will make this a separate
email.
Regards,
Steven
--
David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
http://www.linkedin.com/companies/536082
http://www.axiomatics.com
http://twitter.com/axiomatics
