Re: Attribute Array in JSON Request

[Steven Legg <steven.legg@viewds.com>]

Hi Cyril,

On 2/03/2018 10:45 PM, DANGERVILLE Cyril wrote:
> Hello,
> If I may, I would strongly suggest the TC to consider also removing section 4.2.2.2 (Default Category Objects) for the same reason. Just as reminder, this allows to write certain Request attribute categories in two possible ways. For example, you can have the AccessSubject category either like this, i.e. the generic way:
>
> "Category":  [ ...  { "CategoryId": "AccessSubject", "Attribute": [...] } ...]
>
> OR like this, the "special" way:
>
> "AccessSubject": { "Attribute": [...] }
>
> So again, the extra code complexity to validate and process both ways isn't worth it to save a couple of octets.

Yes, it does add complexity, though it's at least 13 extra characters per category
to do it the generic way. Anyhow, I would not object to making this simplification
as well.

Regards,
Steven

> Regards,
> Cyril
>
> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@viewds.com]
> Sent: vendredi 2 mars 2018 01:55
> To: David Brossard
> Cc: DANGERVILLE Cyril; xacml-comment@lists.oasis-open.org
> Subject: Re: Attribute Array in JSON Request
>
>
> Hi David,
>
> On 10/02/2018 12:23 AM, David Brossard wrote:
> > Hi,
> >
> > In retrospect, I think I probably forgot. The profile is inconsistent in how I handle arrays. That said, now that I attempted to write a swagger definition, I realize that shortcuts like allowing an array to be a single-valued object does not save you much and makes your code much harder.
>
> I and others in the TC agree. The extra code complexity isn't worth it to save a couple of octets here and there. Also, a future work item for the TC is a JSON profile for XACML policies and policy sets which would share a number of constructs with the JSON profile for the protocol. We would want to make the implementation easier by not having any options to output an object instead of an array of one object, but it would be messy if the protocol still allowed it.
>
> Consequently, the TC is proposing to remove from the JSON profile all the cases where the implementer is given the option to use an object instead of an array with only one object. Unless you particularly wanted to do it, Hal and I will take care of these edits for the JSON profile.
>
> To maximize interoperability, those of us with an existing implementation should stop using the option to send an object instead of an array as soon as it is practical to do so, but continue to accept a single object where an array is expected. Implementations of the revised JSON profile would not be expected to use or accept that option.
>
> We will also need new statements of use, which strictly speaking should be from implementations that don't ever send an object in place of an array.
>
> We will be starting the edits in a few days, so if anyone has concerns they should voice them now.
>
> > Did anyone get a chance to try the swagger I wrote?
>
> I haven't tried it.
>
> Regards,
> Steven
>
> > Thanks
> >
> > On Thu, Feb 1, 2018 at 4:45 PM, Steven Legg <steven.legg@viewds.com <mailto:steven.legg@viewds.com>> wrote:
> >
> >
> >      Hi David,
> >
> >      Cyril's review comments on the JSON profile call out the Attribute field in
> >      the Action object in the example request in Section 8.1 as being in error because
> >      it is not an array of objects. I'm not so sure that is the error. You have various
> >      cases where fields that may take multiple values may be represented as a single
> >      object instead of an array containing a single object. Did you intend that this
> >      rule should also apply to the Attribute field but didn't make it explicit, or
> >      did you intend that the Attribute field always be an array?
> >
> >      Regards,
> >      Steven
> >
> >
> >
> >
> > --
> > David Brossard
> > VP of Customer Relations
> > +1 312 774-9163
> > +1 502 922 6538
> > +46(0)760 25 85 75
> >
> > Axiomatics | 525 W. Monroe Suite 2310 | Chicago 60661
> > <https://maps.google.com/?q=525+W.+Monroe+Suite+2310+%7C+Chicago+60661
> > &entry=gmail&source=g>
> > Support: https://support.axiomatics.com
> > <https://support.axiomatics.com/>
> > Web: http://www.axiomatics.com <http://www.axiomatics.com/> Axiomatics
> > Blog <http://www.axiomatics.com/blog/> | Events
> > <http://www.axiomatics.com/events.html> | Resources, Webinars &
> > Whitepapers <http://www.axiomatics.com/resources.html>
> > Connect with us on LinkedIn <http://www.linkedin.com/companies/536082>
> > | Twitter <http://twitter.com/axiomatics> | Google +
> > <https://plus.google.com/u/1/b/101496487994084529291/> | Facebook
> > <https://www.facebook.com/axiomatics> | YouTube
> > <http://www.youtube.com/user/axiomaticsab>