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 From:
xacml@lists.oasis-open.org [mailto:
xacml@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" } } } }