RE: [xacml-comment] JSON Profile Revision

+1 to generally disallowing null.

Hal

From: David Brossard <david.brossard@axiomatics.com>
Sent: Monday, May 21, 2018 2:36 PM
To: Steven Legg <steven.legg@viewds.com>
Cc: xacml-comment@lists.oasis-open.org
Subject: Re: [xacml-comment] JSON Profile Revision

On Mon, May 21, 2018 at 5:48 AM, Steven Legg <steven.legg@viewds.com> wrote:

The XACML TC decided to keep the default category objects in the JSON profile but
make them always arrays instead of a choice between a single object or an array. I'm
currently editing the profile to remove all the cases where there was this choice
and making it always an array, but I've noticed a couple of things that warrant
attention.

There are a couple of cases where an array is required to have at least one value,
and hence is mandatory, but all the rest are optional. The profile doesn't say
whether an empty array is acceptable for these optional cases. In my implementation
I allow an empty array and treat it the same as the type/value pair being absent
since the XML representation is the same either way. I avoid outputting a type/value
pair if the array would be empty. What are other implementations doing and what
should the profile have to say about empty arrays?

Empty arrays should be handled as an absence of value (an empty bag in XACML).

                        "AccessSubject": {

            "Attribute": [

                    "AttributeId": "com.acme.user.approvalLimit",

                    "Value": [],

                    "DataType": "double"

},

                    "AttributeId": "com.acme.user.employeeId",

                    "Value": "Alice"

is the same as

        "AccessSubject": {

            "Attribute": [

                    "AttributeId": "com.acme.user.employeeId",

                    "Value": "Alice"

The second thing is that the optional "Content" type/value pair is allowed to have a
null value. This is the only case where null is allowed. The situation is
analogous to the empty array case in that it makes no difference to the XML
representation whether a type/value pair is absent or the value is null. However,
I propose to disallow null in this case and to make a general statement in the
profile that null isn't used. By analogy we could outlaw empty arrays too, but they
are easy to deal with when parsing. Opinions?

It is odd to have an optional value be null. If it's optional it's because it can be skipped (and therefore null). I agree that we could disallow null in the profile. Either you do not show a property, or you show it and it has a value (including, when arrays are allowed, an array of zero elements)

Regards,
Steven

Thanks for taking the time Steven,

David.

--
This publicly archived list offers a means to provide input to the
OASIS eXtensible Access Control Markup Language (XACML) TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: xacml-comment-subscribe@lists.oasis-open.org
Unsubscribe: xacml-comment-unsubscribe@lists.oasis-open.org
List help: xacml-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/xacml-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml
Join OASIS: http://www.oasis-open.org/join/

xacml message