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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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


Subject: Re: Attribute Array in JSON Request



Hi David,

On 6/03/2018 10:05 AM, David Brossard wrote:
I agree to Steven's first point but not to Cyril's second point.

Default category objects are what makes the profile so successful. People do not want to have to think about the unique identifier. People want to be able to easily remember how to write a request without going back to a long identifier.

Cyril wasn't suggesting that we remove the short identifiers for the categories,
only that we stop using them as the name in JSON name/value pairs. They would still
be used as values for "CategoryId".

Regards,
Steven


I'm happy whether Steven makes the edits or I do.

On Sun, Mar 4, 2018 at 9:26 PM, Steven Legg <steven.legg@viewds.com <mailto:steven.legg@viewds.com>> wrote:


    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 <mailto:steven.legg@viewds.com>]
        Sent: vendredi 2 mars 2018 01:55
        To: David Brossard
        Cc: DANGERVILLE Cyril; xacml-comment@lists.oasis-open.org <mailto: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> <mailto: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 <tel:%2B1%20312%20774-9163>
            +1 502 922 6538 <tel:%2B1%20502%20922%206538>
            +46(0)760 25 85 75 <tel:%2B46%280%29760%2025%2085%2075>

            Axiomatics | 525 W. Monroe Suite 2310 | Chicago 60661
            <https://maps.google.com/?q=525+W.+Monroe+Suite+2310+%7C+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/ <https://support.axiomatics.com/>>
            Web: http://www.axiomatics.com <http://www.axiomatics.com/> Axiomatics
            Blog <http://www.axiomatics.com/blog/ <http://www.axiomatics.com/blog/>> | Events
            <http://www.axiomatics.com/events.html <http://www.axiomatics.com/events.html>> | Resources, Webinars &
            Whitepapers <http://www.axiomatics.com/resources.html <http://www.axiomatics.com/resources.html>>
            Connect with us on LinkedIn <http://www.linkedin.com/companies/536082 <http://www.linkedin.com/companies/536082>>
            | Twitter <http://twitter.com/axiomatics> | Google +
            <https://plus.google.com/u/1/b/101496487994084529291/ <https://plus.google.com/u/1/b/101496487994084529291/>> | Facebook
            <https://www.facebook.com/axiomatics <https://www.facebook.com/axiomatics>> | YouTube
            <http://www.youtube.com/user/axiomaticsab <http://www.youtube.com/user/axiomaticsab>>






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




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