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

Subject: Re: [xacml-dev] Questions and notes on the JSON Interface specification

Hi Glenn,

First of all, many thanks for a great job on the proofread and my apologies for letting so many mistakes slip through.

See my comments inline.

On Fri, Jan 3, 2014 at 6:23 PM, GRIFFIN, GLENN (GLENN) <glenngriffin@research.att.com> wrote:

The following questions are based on the following document:
Request / Response Interface based on JSON and HTTP for
XACML 3.0 Version 1.0
Working Draft 15
02 September 2013

Any answers to these questions would be appreciated.

- 3.4.2 This appears to contradict the DataType row in the table in section 4.2.4, which says that inference on a list of values cannot be done.

                Since both are normative text, please clarify what is expected:
                                - The receiver MUST infer the DataType for lists of values as per 3.4.2 (see next comment), OR

                                - The receiver MUST NOT infer the DataType for lists of values (as per section 4.2.4.)

Yes, you are right. Section 4.2.4 currently read:

In the case of an array of values, the DataType cannot be inferred from the values in the array and the DataType JSON property must be specified.

But it should read

In the case of an array of values, inference works as described in section 3.4.2.

- 3.4.2 If the DataType for a list of values must be inferred, what is the complete list of inferences that is required and that is optional?

                This section mentions one example but does not identify the complete set.
                The conditions under which inference is possible and/or required need to be specified.

                Also the words "may not be possible" and "for example" in normative text is confusing.

Inference is neither optional or required. The list of possible inferences and mapping from a _javascript_ datatype to a XACML datatype is specified in section 3.4.1. We could add a statement in 3.4.2 that says:

Inference for an array of values works according to the inference rules as set in 3.4.1. If a given datatype cannot be inferred and there is no datatype specified then the array of values will be considered as an array of #string.

If an array of values contains an integer and a double, then the inference will make the array an array of double.
Any other combination of values will make the inference fail

- 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.

- 4.2.2 For CategoryId the default value says:
                "None – the identifier used in the XML representation shall be used in its JSON representation except where shorthand notations have been defined."

                Are there shorthand notations defined for CategoryId?
                If so, where are they listed?
                If not, should the reference to shorthand notations be removed?

Good point again. I suggest we introduce a section 4.2.2.1 (the existing section 4.2.2.1 moves to 4.2.2.2) that defines a shorthand definition for standard XACML categories:

urn:oasis:names:tc:xacml:3.0:attribute-category:resource --> Resource
urn:oasis:names:tc:xacml:3.0:attribute-category:action --> Action
urn:oasis:names:tc:xacml:3.0:attribute-category:environment --> Environment
urn:oasis:names:tc:xacml:1.0:subject-category:access-subject --> Subject
urn:oasis:names:tc:xacml:1.0:subject-category:recipient-subject --> RecipientSubject
urn:oasis:names:tc:xacml:1.0:subject-category:intermediary-subject --> IntermediarySubject
urn:oasis:names:tc:xacml:1.0:subject-category:codebase --> Codebase
urn:oasis:names:tc:xacml:1.0:subject-category:requesting-machine --> RequestingMachine

Note that this is in line with the default object names for the 4 default categories, Resource, Action, Environment, and Subject.

- 4.2.4 The (normative) table definition says the Property name is "AttributeId" but all the examples use "Id".

For backward compatibility with systems that are implementing earlier versions of this spec, perhaps both should be allowed, but this is currently a discrepancy.

This is clearly a mistake. Early on in the spec, I wrote that we should try to keep the same object names to element names to avoid people having to learn yet another nomenclature. This means that AttributeId is a better name. But then it makes the JSON a little bigger for no good reason which in turn means that id is a better name. I suppose the name "id" was not used in the XML spec because id is a reserved attribute name.

If we do decide to keep "Id" as in the examples instead of "AttributeId" as in the table, we should make sure all objects that have used AttributeId (e.g. AttributeAssignment) are updated accordingly.

I checked my own implementation and I use "AttributeId".

- 4.2.4 says that Value can be of type "Number". Where is "Number" type defined? Does it include hexBinary and base64Binary?

Did this really mean "integer, double"?
Does the statement "Single instance or array of Data Types listed in 3.4.1" mean the same thing, or is something else intended?

Number is a reference to the _javascript_ number datatype as defined in http://www.w3schools.com/js/js_datatypes.asp. This table shows the _javascript_ datatypes. A _javascript_ number maps to either of an integer or a double in XACML.

Now that I read the spec again, I am not sure I like the statement Array of String and Number where the String values represent a numerical value. Either we have an array of string or we have an array of numerical values but not a mix. That would be too expensive to process. Is that what you meant with "single instance or array..."? I couldn't see that phrase in WD15.

- 4.2.4 Can the array of Attribute objects be empty? I.E:
"Attribute": []

Yes, that's allowed according to the XACML spec.

- 5.1 and 5.2 9 Attributes in the Response: What does "respects" mean in 5.2.9?

                Is this intended to mean "Identical to"? The class diagrams for the Request and Response are different:
                - Request calls the object "Category", Response calls it "Attributes" (plural) - Are they different?   If they represent the same data, shouldn't they be the same?

                - Request uses the field "CategoryId", Response calls it "Category". Should they be the same?

All very good points. I can only apologize for being sloppy. We decided early on that the name Attributes was confusing and that we should rename it to Category instead. We renamed it in the Request but not in the response. We should actually also rename it in the response. This is one place where we break away from the XACML term to introduce a JSON-specific term.

Essentially a request is an array of Attributes which in turn contains an array of Attribute. A response can contain the attributes sent in the request and therefore needs the same representation.

So, here, we should reword and say "identical to", decide on CategoryId or Category, and decide to call Attributes Category in the Response to be in line with the Request.

Minor points:
- 3.4.1 This spec is for inter-system communication where sender and receiver may be using different processing languages.

The normative description of the format should be written in terms of a standard, not in terms of a single language (e.g. _javascript_).

That's what the original XACML specification is for. The XACML specification is neutral. This is an adaptation to JSON (and therefore _javascript_).

Also, the description of the "Mapping/Inference Rule" is confusing because all of the data types except boolean, integer and double are received as JSON quoted strings,

That's true. The idea is to avoid having to specify a data type. In my experience, most of our customers use string anyway. If they don't then they can specify the datatype which will be encoded as JS strings of course.

and according to the first line in this table strings are inferred to be Strings. Perhaps the other data types should say something like "Received and processed as JSON string"?

True. Where would you add this statement?

- 3.4.3.1 The example shows an Attribute with a single object, not an array of objects. To avoid confusion it should be:

                "Attribute": [ {....

- Example in 4.2.3.3 is missing ending </Catalog> in both XML and Base64 versions.

- Many examples are missing objects, which can lead to confusion. For example 4.2.3.3 should be:
                { "Request" : {

                                "Subject":{
                                                "Content\" : \"<?xml version=\\\"1.0\\\"?><catalog> ....

                                }
                }
                }

Thanks,
Glenn

Regarding the examples, I had the ambition to regenerate examples from my code rather than write them by hand as was the case in this version.

Many many thanks for this thorough read-through. I'll work on a new version to fix these ASAP. It'd be great to plan an interop at some point too. Are you implementing your own JSON wrapper? If so, in what language?

Cheers,

David.

David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
LinkedIn: http://www.linkedin.com/companies/536082
Web: http://www.axiomatics.com
Twitter: http://twitter.com/axiomatics

Google Plus: https://plus.google.com/u/1/109113357550030353531/

Facebook: https://www.facebook.com/axiomatics

xacml-dev message