[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] XACML & JSON - progress and ideas
I’m fine with not requiring a strict structural match between the XML schema and the JSON equivalents. We just have to be careful not to cut off future growth
directions. For the case of Attribute+AttributeValue being reduced to a JSON Attribute{“id”: “blah”, “value”: 35}, what about multi-value attributes? An <Attribute> element
can contain multiple <AttributeValue> elements. Would that become Attribute{“id”: “blah”, “value”: {35, 36, 37}}? Also, the <AttributeValue>s within an <Attribute> are not required to all be the same data type. The JSON syntax above can distinguish number and string, but
beyond that things get a little blurry. What would the JSON equivalent of this look like? <Attribute AttributeId = “blah” IncludeInResult=”false”> <AttributeValue DataType=”…integer”>35</AttributeValue> <AttributeValue DataType=”…string”>Jefferson</AttributeValue> <AttributeValue DataType=”…rfc822Name”>george@cleaners.com</AttributeValue> <AttributeValue DataType=”…X500Name”>CN=George,O=foo</AttributeValue> </Attribute> XACML to _javascript_ type mapping sounds fine. Things could get a little loosey-goosey with numerics (Is it a float? Is it an int? It depends!) but _javascript_
devs are used to that. If in doubt, include the data type explicitly. Ecma may have already mapped the _javascript_ built-in types to RFP definitions, so hopefully alignment with XACML will be easy. -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, I won't be able to make it on tomorrow's call. A quick update on my end. In order to simplify things in the JSON profile, I don't think the structural format of the JSON request should respect that of the XACML XML request
so long as the semantics are kept. For instance the AttributeValue inside an Attribute is a bit awkward. I would rather have a single Attribute with the datatype defined there rather than inside an attribute value. There is no loss of information. Also, I think we should define a _javascript_ to XACML datatype mapping. In previous posts on the list, I said that the default datatype should be string. well, actually the default datatype should be the one used in _javascript_ in the JSON
notation when detection is possible. Example Attribute { "id" : "blah" "value" : 35 } is obviously a numerical type - assume integer. This could always be overridden by a datatype attribute. Thoughts? On Wed, Jun 27, 2012 at 6:06 PM, Bill Parducci <bill@parducci.net> wrote: Time: 13:00 EDT (GMT-0400)
-- |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]