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

Hi David,

On 8/03/2018 1:40 AM, David Brossard wrote:

I understand your point. At that rate, though, you could argue we should have stuck with XML :-)

Except there is a significant difference in size and processing cost between XML
and JSON.

Yes it is true that programs will send the requests and that developers will write those programs one-off. My experience is that there are a lot of developers out there that just give up at the first sign of the slightest bit of complexity.

Such as all the different ways to encode a request for multiple decisions :-)

I'm more inclined to Cyril's point of view in that I expect most PEP developers
will either be adapting an example they've seen or will be using a higher-level API
that hides the difference.

ViewDS has four implementations of the JSON profile formatter (for different
languages and platforms) and none of them use the default category objects. I'm
responsible for two of them and I decided that the processing cost involved in
trying to use the default categories was going to be higher than the cost of
sending extra characters per category. It's also much easier to toss everything
into the Category array. The only place where we use default category objects is
in regression tests for the JSON profile parser! From my perspective, default
category objects is a feature I have no real use for.

I want to make XACML as simple as possible. Note BTW that what I am doing here in the JSON profile is something we had in XACML 2.0: resource-specific elements. In XACML 3.0, we went down the path of generalization. I love the idea of generalization but how often do customers use a category other than the 4 standard ones? In my experience, rarely.

That's probably true for customer applications, but I have in-house applications
that frequently use two non-standard categories as well. For them I have to use
the Category array so I might as well put everything in there.


The example you mention is quite clearly an MDP. I think it's stated in the profile. Is it not?

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

Your previous argument can be used here: you wrote the validation. It was a one-off effort. It's done.

Re. the JSON schema, how did you do that? Would you be willing to share it with us? The schema could become the normative form.


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