Lots of great comments. Thanks. I will take them into account in the next
flavor of the example I had written. The example given was indeed meant to
Fundamental points from our conversation so far:
(a) the JSON request/response should be a reflection of the XML version.
One can translate in either direction without any loss
(b) Use of constants vs. use of assumed (default) values: I still think
assuming values is nicer. It makes creating requests by hand so much
easier. It reduces the size of a request as well and increases readability.
(c) short attribute Ids vs. longer (fully qualified ones): Danny you say
that shorter names would lead to possible clashes. But I have never run
into that issue w/ customers who tend to live in a closed world where all
attributes are clearly defined.
My example, in fact, should have skipped the datatype and the issuer (as
Ray pointed out later).
I will get back to you w/ additional work in the coming weeks.
Unfortunately, due to a prior commitment, I won't be able to attend today's
On Thu, May 10, 2012 at 3:15 PM, <remo...@emc.com> wrote:
From: xac...@lists.oasis-open.org [mailto:xac...@lists.oasis-open.org] On
Behalf Of David Brossard
Sent: Thursday, May 10, 2012 3:21 AM
Subject: [xacml] Suggestions for a JSON representation of the XACML
request - JSON profile
I've had a look at the reference definition of a XACML request defined
in 5.42 Element <Request> on line 2726 of the specification PDF.