[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml-dev] Questions and notes on the JSON Interface specification
Hi David, One more thing came up today. In the XML version of the Request the Namespace definitions are not needed in the Content node because the definitions on the Root node are used when parsing the Content. Thus <Request … xmlns:md="http://www.medico.com/schemas/record" > … <Content> <md:record> parses correctly, but in the JSON version of the same thing we do not have that context, so : {“Request”: {… “Content”: “<md:record> … “ must fail (prefix ‘md’ is not bound). I believe that the answer to this is to require that any Content sent in a JSON request MUST include all Namespace definitions needed to parse that Content. In this example that would be: {“Request”: {… “Content”: “<md:record xmlns:md=\"http://www.medico.com/schemas/record\" > … “ The Namespace is needed irrespective of whether the Content is encoded in Base64 or not. Thanks, Glenn From: David Brossard [mailto:david.brossard@axiomatics.com] 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:
But it should read
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.
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.
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:
Note that this is in line with the default object names for the 4 default categories, Resource, Action, Environment, and Subject.
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".
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.
Yes, that's allowed according to the XACML spec.
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.
That's what the original XACML specification is for. The XACML specification is neutral. This is an adaptation to JSON (and therefore _javascript_).
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.
True. Where would you add this statement?
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 Google Plus: https://plus.google.com/u/1/109113357550030353531/ Facebook: https://www.facebook.com/axiomatics |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]