Re: [xacml] XACML & JSON - progress and ideas

On Thu, Jun 28, 2012 at 5:35 PM, Danny Thorpe <Danny.Thorpe@quest.com> wrote:

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.

Agreed

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}}?

Yes it would. It is quite natural to do so in JSON. But actually it would be an array so square brackets [] not curly {} i.e.

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>

This would look like

Attribute{“id”: “blah”, “value”: 35}

Attribute{“id”: “blah”, “value”: "Jefferson"}

Attribute{“id”: “blah”, “value”: "george@cleaners.com","type="...rfc822Name"}

Attribute{“id”: “blah”, “value”: " CN=George,O=foo ",type="...X500Name"}

I had to specify the data type of the last two ones because there is no easy way to guess it's a string or a strongly typed value.

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.

Yes, I agree some cases are loosey-goosey. We can warn users from assuming default datatypes when in doubt.

Thanks for all your pointers Danny.

Cheers,

David.

-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, June 27, 2012 9:55 PM
To: Bill Parducci
Cc: XACML TC
Subject: [xacml] XACML & JSON - progress and ideas

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)
Tel: 513-241-0892
Access Code: 65998

Proposed Agenda for 28 June 20112 TC Meeting:

I Roll Call & Minutes

Approve Minutes:
14 June 2012 TC Meeting
https://lists.oasis-open.org/archives/xacml/201206/msg00030.html

II. Administrivia

XACML v3 Combining Algorithm uploaded
https://lists.oasis-open.org/archives/xacml/201206/msg00031.html

XACML TC Summary Overview
https://lists.oasis-open.org/archives/xacml/201206/msg00032.html

XACML Interop demo opportunities
https://lists.oasis-open.org/archives/xacml/201206/msg00034.html

Status XACML IPC v1.0 Profile

III. Issues

Proposed PAP Architecture
https://lists.oasis-open.org/archives/xacml/201206/msg00026.html
(continuation of thread)

JSON Mapping
https://lists.oasis-open.org/archives/xacml/201206/msg00024.html

Metadata Profile inquiry
https://lists.oasis-open.org/archives/xacml/201206/msg00011.html

REST Profile API/PolicyId/General Plan
(no recent postings)

---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org

--
David Brossard, M.Eng, SCEA, CSTP
Product Manager
+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

xacml message