OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: Updated version of XACML JSON profile

Hi David,


Thank you for all the work you’ve done on the spec.  It is much cleaner now.


A few minor notes:


- 3.2.1 I would recommend that another paragraph be put into this section:

                “The name of the XACML XML ‘Attributes’ element has been changed in JSON to the ‘Category’ object.

                The name has been changed to make the purpose of the object clearer.”

(In other words, because this is the only name that gets changed from the XACML core spec, you should elevate it’s importance and explain why it needs to be different from the core terminology.  As I mentioned before, when you have people working separately on XML and JSON versions this can become a communication problem.  It is also a learning-curve issue for newbies like me.  It will probably also cause some confusion in these forums for that reason.  Just for consistency I think it should be left as ‘Attributes’, but ‘Category’ is so much clearer that I  think I’ve lost that battle. J )


- 3.2.2 Should this be “JSON” rather than “XACML”?


- 3.3.2 contains reference to 3.4.1 which needs to be updated.


- 3.3.2 second paragraph, suggest “If an array of values contains integers and doubles with no other types,…”  (existing text includes non-numeric values)


- 3.3.4 As I learned from the discussions, these values are allowed in the core XACML version.  By dis-allowing them in this profile we are making the JSON not equivalent to the XML version.

                If that is what we want to do, then it should be clearly stated as such.

                Now that these values are stated in terms of the IEEE standard (thank you for removing the _javascript_ references) and I have learned that they are included (by reference) in the XACML core standard, I now think we should allow them in this interface.  The issue of what to do with them really needs to be resolved in the XACML core spec, not here, so perhaps this section should be removed?  On the other hand, because of the possibility that a client might be written in _javascript_ and thus there is a greater possibility of these values appearing on this interface, perhaps we need to leave the section in?  Either way my preference would be that these values be treated the same way as the core spec.


- 4.2.1 In the description of Category, “Much like the Attributes…” should be “Just like the Attributes…” since these are equivalent, not just similar.


- Strongly urge that the identifier ending in “access-subject” have the short name “access-subject”.  This is the only case where the Short name is not exactly the last part of the full identifier.  I know that it is easier to type and read “subject” but, aside from being consistent, “access-subject” is more precise and clearer as to its purpose, especially since we have multiple other types of subjects.  Over the years I have found that the annoyance of typing more is usually repaid later in better comprehension.


- Minor maintenance simplification: remove the number (eight) from the first and last sentences.  The reference to the table should be sufficient.  Also remove the specific names from the last sentence.


- Suggest adding an array in the example, e.g.

                “Action” : [

                                { “Attribute”: […] },

                                {“Attribute”: […] }




Again thanks for all your work and for listening to my suggestions.




From: David Brossard [mailto:david.brossard@axiomatics.com]
Sent: Tuesday, March 25, 2014 10:38 AM
To: xacml-dev@lists.oasis-open.org; GRIFFIN, GLENN (GLENN)
Subject: Updated version of XACML JSON profile


Hi Glenn, dear all,


I'm not sure whether you get the usual XACML emails so I wanted to point out that I've updated the JSON profile and that it is available for review. It is now in WD 16.


Everyone's feedback is welcome. I will be cleaning up WD16 and uploading WD17 based on the conversations we had on the TC call last week (error handling and profile name). I will then ask we move WD17 through the OASIS process. Now is your chance to review the document.







David Brossard, M.Eng, SCEA, CSTP
VP of Customer Relations
+46(0)760 25 85 75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden

Axiomatics for developers: http://developers.axiomatics.com

Connect with us on LinkedIn | Twitter | Google + | Facebook | YouTube

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]