Hi David,

Thanks for the writeup to get this discussion going. :>

1. I don't agree that JSON is mutually exclusive of XML. JSON is a more
convenient representation for some applications / platforms than XML for the
request/response exchange overall, but I think there is still value in having
the ability for the PEP to submit document metadata and/or relevant document
content with the auth request.

Ideally, a JSON profile should be an isomorphic representation of the XACML
spec, not a reinterpretation of the spec. The JSON profile needs to maintain
parity with the XML spec. Any XML request or response should be transformable
into JSON and back to XML (and JSON->XML->JSON) without loss of information.
Anything less will be a one-way transform and will leave somebody on the wrong
side of a one-way door.

I suggest that we retain the XPath selectors and resource Content elements in
the JSON representation. We shouldn't prohibit clients who are XML capable from
using these features just because they choose to represent the request in JSON
format. Clients on platforms where XML is not convenient have the option to not
use it in their JSON auth requests, but this will need to be coordinated with
the policy writers, since a policy rule that contains an XPath attribute
selector will only work with a request that contains XML content.

I suspect that in most cases where XML content is provided with an auth request,
the XML content is not created by the application or the PEP, but is passed
through the application or PEP from some other source. An app that makes JSON
XACML auth requests containing XML content doesn't need to understand the XML
content, it just needs to copy the opaque blob from wherever it comes from into
the request and see what the PDP auth response is.

2. I've used JSON quite a bit for internal APIs (long ago), but I'm not as
familiar with JSON in a standards situation. I'm fine with the idea of defining
short name identifiers to correspond to the XACML spec URI constants, but how do
we differentiate lexical scope so that our short identifiers do not get confused
with somebody else's (or our own, in different spec versions) short identifiers
of the same name? Is there some convention in the JSON world by which we can
associate a namespace with a JSON object, perhaps as a property? ("namespace":
"urn:xacml:3.0:etc")?

3. Unnamed objects: Shouldn't the unnamed objects in your example be contained
in an array? A quick glance at the syntax diagram at json.org doesn't appear to
allow a sequence of anonymous curly braces as child elements. If your example
was only intended as pseudocode, then ignore this comment. ;>

4. I think shortening the identifiers only needs to be done to make JSON
property names compatible with JavaScript syntax - there's no pressing need to
shorten the values. The name: value pairs defined in the JSON objects can be
accessed via JavaScript object.member syntax (if obj.category == "asdf") so
brevity and lack of URN delimiters is a plus. The value, on the other hand, will
never be anything other than a value, so the only downside to using the XACML
urn constants verbatim is wordiness. Define some constants in a JavaScript file
that contain the XACML spec urns and instruct devs to compare against the
constants instead of using string literals. Defining the values as constants is
a good idea anyway.

Constants: (pseudocode)

var Xacml3 = { Category = { Subject =
"urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" Resource =
"urn:oasis:names:tc:xacml:3.0:attribute-category:resource" Etc... }, Attribute = { SubjectId = "urn:oasis:names:tc:xacml:1.0:subject:subject-id" Etc Xacml3 spec attribute ids } DataType = { String = "http://www.w3.org/2001/XMLSchema#string" Etc all the XACML3 spec data type ids } }

JSON object: (pseudocode) { { "category" :
"urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" { { "id" : "urn:oasis:names:tc:xacml:1.0:subject:subject-id", "datatype" : "http://www.w3.org/2001/XMLSchema#string", "issuer" : "", "value" : "alice", } } } }

JavaScript client code could use the constants (provided in the JSON Xacml
profile) to assign and test the values:

Assign: request.Add({ "category" : Xacml3.Category.Subject, ...}) or request[0].category = Xacml3.Category.Subject;

Test: if (request[0].category == Xacml3.Category.Subject)...

The serialized JSON objects always show the literal string values. The constants
are a convenience for us humans.

5. We can define short identifiers for XACML spec items for convenience, but how
do we handle arbitrary application-defined attribute Id URNs? We still need a
way to represent urns as names in JSON without causing JavaScript to blow a
gasket. I forget offhand - does JavaScript allow arbitrary characters
(including JavaScript language tokens such as "+", ";", etc) in member names
defined using quoted strings? I vaguely recall the answer may be yes, so
perhaps this is a moot point.

6. Assuming default values for infrequently used items: hmm... ok, as long as
those values can be preserved in round trip transforms to XML and back. For
mechanically transformed XML -> JSON, I can almost guarantee that all of the
required XML attributes will appear in the JSON representation, regardless of
what defaults we define for human convenience in the JSON profile. Since the
XML spec generally avoids default values, the JSON->XML transform would have to
be constructed as : "If property X exists in the input JSON, emit the property
and its value to the output XML. If property X does not exist in the input
JSON, emit property X's JSON default value to the output XML, because it's
required in XML". And it doesn't seem worth the trouble to define the XML->JSON
transform to elide the properties that match their JSON default values.

I do agree that defining default values for infrequently used properties makes
sense for JSON serialized from hand-written request objects. However, for JSON
emitted from higher-level PEP helper classes, and for JSON produced by
mechanical transformation from XML, JSON property default values will most
likely be ignored - in the sense that it's easier (and safer) to emit everything
than to keep track of which items have defaults and what those defaults are to
selectively emit values. I'm just noting this to point out that the
justification for defining property defaults in JSON is purely for human
convenience (a valid justification), not minimizing JSON data size.

More tomorrow after I sleep on this a bit. :>

-Danny

Danny Thorpe Product Architect | | Quest Software - Now including the people and products of
BiTKOO | www.quest.com<http://www.quest.com>

From: xac...@lists.oasis-open.org [mailto:xac...@lists.oasis-open.org] On Behalf
Of David Brossard Sent: Wednesday, May 09, 2012 6:21 PM To: xacml Subject: [xacml] Suggestions for a JSON representation of the XACML request -
JSON profile

Dear all,

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.

I want to make a simple JSON representation. To do this I want to assume default
values. For instance, ReturnPolicyIdList is a required attribute. In my vision
of the JSON representation, I would not force users to use it and assume a
default value of true or false. The JSON profile would be responsible for
defining default values.

The same would apply to CombinedDecision.

In JSON, I would also not include the RequestDefaults element since its use is
mainly for XPath (and therefore XML content which isn't applicable in JSON).

With respect to MultiRequests, I'm undecided. It's a nice feature of the MDP
profile but I am not sure it's actually that easy to use. We could do with the
repeated attributes element as defined in the Multiple Decision Profile.

So all is left to specify in JSON is the XACML Attributes element and the XACML
Attribute element.

With respect to the Attributes element, does it make sense to have a <Content>
element still? Could we assume that as an empty <Content> element. As for the Category attribute of the Attributes element, I believe we need to
define shorthand values for the longer category identifiers. JSON will be
particulary appealing if the ids are kept short and human-readable. This means
the profile must define these shorthand values.

Finally, the Attribute element: an attribute is a set of values, an identifier,
an issuer and a datatype. We could easily represent that as { "id" : "my-attr" "datatype" : "string" "issuer" : "" "value" : ["value1","value2"] }

includeInResult could be omitted and assumed to be false.

Please find below a sample XACML request and its JSON equivalent.

<xacml-ctx:Request ReturnPolicyIdList="true" CombinedDecision="false"
xmlns:xacml-ctx="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"> <xacml-ctx:Attributes
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject" > <xacml-ctx:Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:subject:subject-id"
IncludeInResult="true"> <xacml-ctx:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">Alice</xacml-ctx:AttributeValue> </xacml-ctx:Attribute> </xacml-ctx:Attributes> <xacml-ctx:Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:environment" > </xacml-ctx:Attributes> <xacml-ctx:Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource" > <xacml-ctx:Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
IncludeInResult="true"> <xacml-ctx:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">hello</xacml-ctx:AttributeValue> </xacml-ctx:Attribute> </xacml-ctx:Attributes> <xacml-ctx:Attributes
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action" > <xacml-ctx:Attribute
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
IncludeInResult="true"> <xacml-ctx:AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">say</xacml-ctx:AttributeValue> </xacml-ctx:Attribute> </xacml-ctx:Attributes> </xacml-ctx:Request>

{ { "category" : "subject" { { "id" : "subject-id" "datatype" : "string" "issuer" : "" "value" : "alice" } } } { "category" : "action" { { "id" : "action-id" "datatype" : "string" "issuer" : "" "value" : "say" } } } { "category" : "resource" { { "id" : "resource-id" "datatype" : "string" "issuer" : "" "value" : "hello" } } } }