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: [xacml-comment] RE: Attribute Array in JSON Request


Implementation complexity is a one-off cost so that users can have an easier time using the profile.

I still think that 


is harder to read and remember than

We seldom see policy authors use custom categories at all. It does happen and even the spec has more than the 4 usual categories (subject, action, resource, env) but still people rarely use intermediary-subject. This is why I think having the JSON name/value pair is particularly useful.

Thoughts?

On Tue, Mar 6, 2018 at 4:16 AM, Romain Ferrari <romain.ferrari@gmail.com> wrote:
Hi,

I fully agree with Cyril. Removing the short identifiers from the JSON
name/value will decrease an implementation complexity.

Regards

Romain Ferrari


On 03/06/2018 11:08 AM, DANGERVILLE Cyril wrote:
> Exactly. Thanks Steven.
>
> Regards,
> Cyril
>
> -----Original Message-----
> From: Steven Legg [mailto:steven.legg@viewds.com]
> Sent: mardi 6 mars 2018 06:39
> To: David Brossard
> Cc: DANGERVILLE Cyril; xacml-comment@lists.oasis-open.org
> 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>
>>





--
David Brossard
VP of Customer Relations
+1 312 774-9163
+1 502 922 6538


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