Re: [xacml] JSON mapping choices

[David Brossard <david.brossard@axiomatics.com>]

Hi Danny, all,

A few comments.

(a) we should not necessarily try to go from the XACML request in XML to the XACML request in JSON. We could start from the XACML normative definition in the .doc 

(b) we should definitely look at existing tooling
(c) much as I love XSLT, this is a technical answer to a non-technical issue (ease of use).

Actually, if we do this exercise correctly, could this actually lead to providing a Java or C# open representation of a XACML request and response from which JSON could be derived?

On to the request / response structure.

A year or so ago, when I actually requested the template for the JSON format, I also read through the spec and XSD of XACML 3.0 to understand what a request and response are technically.


I am now walking back through the spec one by one to identify those elements and/or attributes for which a default value can be assumed.

Following the JSON example I had given and which contained errors, I wrote a new one which I believe is truer to what we would want to achieve. Your feedback is much appreciated as always. I am hoping to have an initial spec out by CoP Friday.

{
    "Request": {
        "Attributes": {
            "Category": "urn:oasis:names:tc:xacml:1.0:subject-category:access-subject",
            "Attribute": {
                "Id": "user-role"
                "AttributeValue" : {
                   "value" : ["manager","administrator"]
                }
            }
        }
        "Attributes": {
            "Category": "urn:oasis:names:tc:xacml:3.0:attribute-category:resource",
            "Attribute": {
                "Id": "document-id"
                "AttributeValue" : {
                   "value" : ["123"]
                   "DataType" : "http://www.w3.org/2001/XMLSchema#integer"
                }
            }
        }
    }
}

Cheers,
David.

On Thu, May 31, 2012 at 9:41 PM, Danny Thorpe <Danny.Thorpe@quest.com> wrote:

As mentioned in earlier emails and in the TC call today, there are several different “ad-hoc” schemes for mapping JSON to/from XML.  There is concern that if we pick one of these, it may be one that falls into obscurity as some other scheme picks up in popularity and ubiquity.

 

The advantages of picking an existing mapping scheme are

1.       We don’t have to define a scheme ourselves

2.       We can take advantage of existing tools to perform JSON/XML transforms.

 

Are there any other advantages of picking an existing mapping scheme?  I think most clients will be more interested that the JSON we define faithfully represents XACML notions and is easy to use and less concerned about the wire format or tool chain.

 

If we define our own mapping scheme, we can produce something that is a more natural fit for XACML notions and structure than a more generic scheme. As mentioned on the call, the generic schemes have to deal with the full extent of XML _expression_. We don’t need to represent all of XML, we only need to represent XACML notions in a way that can be transformed in and out of XML. We can look to existing schemes for inspiration but not be bound by them.

 

The main caveat is then tooling – making sure that it is easy for implementations to transform XACML XML to JSON and back.

 

I believe a transform from XACML XML to whatever JSON we determine can be defined using XSLT.  I don’t think XSLT is well suited to transform JSON to XML. That transform is probably best defined as a _javascript_ function that takes the JSON object tree and serializes to XML text.  Both of these transforms could be defined by the XACML TC and provided in the XACML JSON profile.  A reference implementation, if you will.

 

While using an existing pre-baked mapping scheme is attractive as a least-effort solution, I think the XACML community will be better served by defining our own mapping scheme using existing transform tools such as XSLT. 

 

-Danny

 

Danny Thorpe

Product Architect | | Quest Software - Now including the people and products of BiTKOO | www.quest.com

 

-- 
David Brossard, M.Eng, SCEA, CSTP
VP Product Marketing & Customer Relations
+46(0)760 25 85 75

Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
http://www.linkedin.com/companies/536082
http://www.axiomatics.com


http://twitter.com/axiomatics