[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml-comment] RE: Attribute Array in JSON Request
Regarding the example, all I could find about MDP – besides MultiRequests - is:
the optional default objects (based on section 188.8.131.52) can also be an array instead of single-valued in order to cater for multiple decision requests as defined in [XACMLMDP]
But I’m not sure what it means. Does it mean that you can have something like the following for MDP ?
As for the JSON schema, I just wrote it by hand L and used a Java library to make sure it is valid and works. I’ve been waiting for the JSON Profile to be finalized before making it official, in case there are new changes following the review period (which I hope there will be). Anyway, I can share what we have for now. You can find the draft on AuthzForce’s github :
Beware of a few things:
- It is split in 3 schemas: common.schema (common to Requests and Responses), Request.schema (for Request only) and Response.schema (for Response only)
- I tried to keep it simple for our needs, so it does not support Default Category objects actually, only the generic Category one (but it is possible to support both with json schema).
- It is written according to draft 06 of JSON schema. Yes, JSON schema is still a draft spec and, since I wrote this 3 months ago, the draft 07 has come out. There are still many issues to be fixed on this spec: https://github.com/json-schema-org/json-schema-spec/issues
From: David Brossard [mailto:email@example.com]
I understand your point. At that rate, though, you could argue we should have stuck with XML :-) 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. 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.
The example you mention is quite clearly an MDP. I think it's stated in the profile. Is it not?
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.