OK David, I understand that readability is the main concern for you here. I can understand that this can help humans read the raw JSON more easily, especially for debugging/testing purposes. But most of the time, the Requests will be produced and consumed/read by programs, not humans, won’t they? As for “harder to remember”, I would say this is not an issue, because, if the users want to write the Request by hand, they would/should reuse valid examples (from the standard), and just copy-paste/modify for their needs, instead of writing from scratch. Ideally, they would use a nice JSON-beautifying editor or, even better, a Request editor that masks the low-level JSON syntax. Maybe Axiomatics provide one already ? ;-) I would not recommend writing the JSON manually from scratch because this is the best way to make syntax errors. Our concern – I mean my team’s – is more about safety/security. When the syntax allows two ways of writing the same thing, or one generic way with some exceptions, it makes validation trickier and more error-prone. (I wrote a JSON schema for the JSON Profile and this makes quite a difference in complexity.) For example, let’s look at the tricky example where both ways are used to specify attributes in the same category (AccessSubject in that case): "Request": { "Category": [{ "CategoryId": "AccessSubject", "Attribute": […] }, … ], "AccessSubject":{ "Attribute": […] }, …. } What is the standard way in this case? Maybe this is obvious to you that you should merge everything, but I am pretty sure that some implementers handle it differently at the moment. Kind regards, Cyril [@@ OPEN @@] --- Cyril Dangerville Security Engineer, CISSP Thales Services From: David Brossard [mailto:david.brossard@axiomatics.com]
Sent: mardi 6 mars 2018 14:09
To: Romain Ferrari
Cc: xacml-comment@lists.oasis-open.org
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. - "Category": [ ... { "CategoryId": "AccessSubject", "Attribute": [...] } ...]
is harder to read and remember than
- "AccessSubject": { "Attribute": [...] }
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. 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 |