Re: [xacml] Groups - Request / Response Interface based on JSON and HTTP

Subject: Re: [xacml] Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded

Thanks a lot for great feedback. I've integrated most of it in the new WD that I just uploaded. Please see also my comments below.

On Fri, Jul 6, 2012 at 8:22 PM, Danny Thorpe <Danny.Thorpe@quest.com> wrote:

Hi David,

Looking good! Great start!

Some comments and questions:

1. 3.1.2 Requirements – suggest “It must be possible to translate XACML requests and responses between XML and JSON representations in either direction at any time without semantic loss.”

Changed, thanks.

2. 3.2.2 Object Names – should note that JSON object names MUST match the XACML XML element names exactly, including case.

Correct, changed.

3. 3.2.4 Datatypes –

a. What is the purpose of the # prefix on the data types that come from XML schema? Is there a name collision issue with _javascript_ built-in types? It just strikes me as odd that some of the XACML JSON shorthand data types have the # prefix and some don’t. I’d prefer to see all the shorthand type names prefixed with #, or none.

It was just to remind people that this was an XML datatype and that the full value is xml.org/..../#string but it's really superfluous so I removed it.

b. Data-types is hyphenated in the core spec, and not capitalized except in headings or sentence starters. Probably should follow suit here.

I made sure that the text uses data-type or Data-type and that the property name is DataType as per the XACML spec.

c. Note that the full XACML data type string can also be used in JSON. This is necessary to support custom data types defined by an application, XACML profile, or other standard. The JSON shorthand type codes are a convenience, not a replacement.

Yes, correct. I added your statement.

d.      XACML JSON emitters are strongly encouraged to substitute JSON shorthand type codes for XACML type identifiers where appropriate, but this is not a strict requirement.

e.      When reading JSON, the rules for inferring the XACML type from a _javascript_ value need to be spelled out.

                                                               i.      _javascript_ “Number” with no fractional portion and within integer range -> XACML #integer

                                                             ii.      _javascript_ “Number” with fractional portion or out of integer range -> XACML #double

                                                            iii.      _javascript_ “String” -> XACML #string

                                                           iv.      _javascript_ “Boolean” -> XACML #boolean

                                                             v.      _javascript_ “Object” -> undefined, inferencing must fail

                                                           vi.      _javascript_ “Array” -> undefined, inferencing must fail

I don't agree with the Array failure - as a matter of fact, neither do you - your email below says that we should be able to infer Array of int if we have [12,12,12]

vii. _javascript_ “null” -> undefined, inferencing must fail

viii. _javascript_ “Undefined” -> undefined, (my favorite) inferencing must fail

When inferencing fails, we assume string to be the datatype.

f.        When emitting JSON, the data type may optionally be omitted ONLY in the following cases:

                                                               i.      XACML #string -> _javascript_ quoted string

                                                             ii.      XACML #integer -> _javascript_ integer

                                                            iii.      XACML #double -> _javascript_ number

                                                           iv.      XACML #boolean -> _javascript_ boolean

g.       For all other XACML types:

                                                               i.      The data type MUST be specified and value expressed in the XACML string representation of the value.

                                                             ii.      _javascript_ code may choose to parse the XACML string values into internal numeric representations for internal use, such as for DateTime or Duration values, but the JSON transport representation must always express the value in the XACML string representation of the XACML data type.

h.      We also need to define what to do with special _javascript_ numeric values:

                                                               i.      _javascript_ NaN -> NaN

                                                             ii.      _javascript_ positive infinity -> INF

                                                            iii.      _javascript_ negative infinity -> -INF

                                                           iv.      _javascript_ positive zero -> 0

                                                             v.      _javascript_ negative zero -> 0 (-0 is a valid text representation, but the sign will be ignored by XACML in comparisons, per XML #double)

4.       3.3.2 RequestDefaults – I appreciate the desire to flatten the RequestDefaults structure and just represent its one and only child, XPathVersion, as a child of the Request itself. However, we have to ask why that was not done in the original XML schema as well. I suspect the intent was that “other stuff” could be added to the RequestDefaults in the future, and by creating a distinct container for such things name collisions can be avoided. If this is the case, JSON should follow suit so that “other stuff” defined in XACML in the future will have a corresponding unambiguous home in JSON.

Ok, I removed my flattening idea. It's not a biggie. We can decide to change it back later. Besides, since it's an optional element, the flattening (or lack thereof) won't get in the way.

If this is not the case and the RequestDefaults element is a vestigial tail of some long ago issue that is no longer relevant, then we can flatten it for JSON.

5. 3.3.4 Content object representation. Let’s just make the JSON content object data type a string which may contain an XML payload per the XACML spec. Having XML here won’t be a burden on JSON clients because Content is usually a pass-through blob of metadata obtained from somewhere else, such as a document. It’s not XML that the client application will have to synthesize (like a request) or digest (like a response).

Agreed

While it’s technically conceivable that XPath expressions could be used to traverse a JSON object representation, we really (really) should not go down that rabbit hole.

Agreed

6. 3.3.5 Attribute representation.

a. “The datatype value can be omitted in the JSON representation. Its default value will be http://www.w3.org/2001/XMLSchema#string”. What about data inferencing here? “value” : [123, 456] inferred as array of int?

Yes, I would say so. Of course arrays cannot be of mixed datatype.

b. Need to state that the values in the value array MUST be of the same data type. To represent attribute values of different data types, separate Attribute objects are required for each data type.

Yes, agreed

c. Typo: “The issuer value can omitted” -> “can be omitted”

Thanks.

Overall, the voice of the text tends to be future tense – “will be”. Probably needs to be more present-tense declarative/assertive: “is”

You are very right. This will be changed. No, sorry, this is now changed :-)

A significant portion of the text is spent on restating XACML spec fundamentals. The normative JSON content is frequently only one sentence or paragraph at the end of each section. This can be occasionally confusing as to which is XACML reference and which is JSON normative.

You are right. I trimmed that out.

Correlating the JSON bits to the XACML bits is good, but I’m guessing that some portion of the readership of this JSON profile will be _javascript_ devs who only want to know how to write a XACML-JSON request and process the response. The _javascript_ devs aren’t that interested in the XML back story. Perhaps this JSON profile could just define the JSON syntax and reference the XACML core spec for each JSON section for those that are curious? This is the JSON object, these are its fields and their default values if any, etc, and away you go. It would make the JSON profile more succinct and higher impact for _javascript_ devs.

Yes, many thanks!

-Danny

Danny Thorpe

Product Architect | | Quest Software - Now including the people and products of BiTKOO | www.quest.com

From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of David Brossard
Sent: Wednesday, July 04, 2012 2:32 PM
To: xacml@lists.oasis-open.org
Subject: [xacml] Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded

Submitter's message
Dear all,

Here is my first go at trying to formalize the different ideas on the JSON representation that we have exchanged on the mailing list.

Cheers,
David.
-- Mr. David Brossard

Document Name: Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0

No description provided.
Download Latest Revision
Public Download Link

Submitter: Mr. David Brossard
Group: OASIS eXtensible Access Control Markup Language (XACML) TC
Folder: Specifications and Working Drafts
Date submitted: 2012-07-04 14:31:50

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

xacml message