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

Regarding the example, all I could find about MDP – besides MultiRequests - is:


the optional default objects (based on section 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 ?


“AccessSubject”: [

                “Attribute”: […],

                “Attribute”: […],




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:david.brossard@axiomatics.com]
Sent: mercredi 7 mars 2018 15:41
Cc: xacml-comment@lists.oasis-open.org
Subject: Re: [xacml-comment] RE: Attribute Array in JSON Request




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?


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]