[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:
Hi, 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. Regards, Steven
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. Thanks, David.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]