[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Suggestions for a JSON representation of the XACML request - JSON profile
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 Dear all, |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]