RE: Updated version of XACML JSON profile

Hi David,

Some thoughts on access-subject. If people are struggling with the name, perhaps it is inherently unclear and should be changed in the core spec? If people are having trouble with it in the JSON version, wouldn’t they also have the same trouble in the XML version? After all, it is the same concept, same name, and so on. I know that in the 5+ months I’ve been working with XACML, whenever I see “access-subject” I always (and still) say “wait a minute, is that the ‘accessing’ (‘requesting’) subject or the ‘accessed’ (‘target’) subject” and have to look at the conformance tests to figure it out. Come to think of it, wouldn’t “requesting-subject” be a better name for this field in the core spec?

Re-reading the core spec, I see that “Subject = An actor whose attributes may be referenced by a predicate”. This is intentionally ambiguous because any particular policy and request may have multiple actors involved. Therefore it would seem that using the word “subject” as the name of a field is fundamentally unclear because “Subject” is a concept (a.k.a “an Actor”), not an identification of a specific instance of that concept (e.g. “the actor who is trying to access this information”. “the actor who authorized this access”, “the actor who paid for the access”, “the actor whose data is being accessed”, etc. ). Any field in the actual Policies and Requests needs to identify a specific type of actor to avoid ambiguity.

My other thought is that we really should not support both short names. If we are going to special-case this one name (yuck), then we should explicitly map it to one name. The point of consistency (other than the human-readability/ease-of-understanding improvement) is to allow simple algorithmic processing, and if the receiver of a message needs to handle both names we don’t gain anything by including the second name because the code still needs to special-case the non-standard version.

Thanks,

Glenn

From: David Brossard [mailto:david.brossard@axiomatics.com]
Sent: Monday, April 14, 2014 8:46 AM
To: GRIFFIN, GLENN (GLENN)
Cc: xacml-dev@lists.oasis-open.org
Subject: Re: Updated version of XACML JSON profile

Hi Glenn,

Thanks for this additional round of comments.

Please find my comments inline.

On Tue, Mar 25, 2014 at 5:23 PM, GRIFFIN, GLENN (GLENN) <glenngriffin@research.att.com> wrote:

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 )

Yes, fixed.

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

No, it is correct as it is. I realize my point wasn't clear. The point is that, in XACML, the order of information (be it categories or attributes) has no impact on the semantics of a XACML request. Therefore the serialized version (be it JSON or XML) can ignore the order.

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

Fixed: changed to 3.3.1.

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

Fixed.

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

As per Steven Legg's comments, we will align the core spec with the profile.

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

Fixed

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

I am not sure what to do here. I agree with you yet at the same time, I see how much customers struggle with the name access-subject. I'll bring it up on the XACML TC list. We can support both names too.

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

Fixed.

- 4.2.2.3 Suggest adding an array in the example, e.g.
                “Action” : [
                                { “Attribute”: […] },
                                {“Attribute”: […] }
                }

Fixed

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

My pleasure. Your comments have been critical to the quality of the profile.

I will upload WD17 once we have agreed in the TC whether we should:

stick to access-subject as a short name
stick to subject as a short name, or
allow either

Cheers,

David.

Glenn

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.

Direct link: xacml-json-http-v1.0-wd16.doc

Cheers,
David.

--
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
Support: https://support.axiomatics.com
Web: http://www.axiomatics.com
Axiomatics for developers: http://developers.axiomatics.com
Connect with us on LinkedIn | Twitter | Google + | Facebook | YouTube

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

Support: https://support.axiomatics.com
Web: http://www.axiomatics.com

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

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

xacml-dev message