OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: Providing JSON default values


I am wondering whether we only have default values on the request side, perhaps not so the response. Where would we have defaults in the response? In that case, what you describe might actually not be an issue. Or am I missing the point?

On Thu, Jul 12, 2012 at 8:30 PM, Danny Thorpe <Danny.Thorpe@quest.com> wrote:

On these default values in JSON…  do we need to describe how that should work?  As JSON objects, there’s no inherited behaviors so there’s no intrinsic way to define the defaults in the JSON representation itself. Somebody has to provide the defaults for the JSON objects.

 

This is less of a concern for PDP implementations since we’re expecting most implementations will be transforming the JSON representation into an internal object format already used to represent the XML representation in memory. Default values can be provided by the internal objects’ existing default-on-demand mechanism for optional XML artifacts or can be injected by the transformer for mandatory XML artifacts.

 

Client applications receiving JSON XACML decision responses, though, are less likely to be funneling JSON objects into an existing XACML object representation. For many _javascript_ applications, the JSON objects *are* the XACML object representation. For these cases, the application will need a way to supply default values for artifacts that are elided from the JSON object representation.

 

I’m assuming that the JSON objects would need to be composed with “actual” objects that provide default values for the consumer of the JSON objects – be that the PDP (receiving a JSON request) or the client application (receiving a JSON response).

 

Profile text something like this maybe?

 

An implementation will need to perform some fashion of post-processing or composition to provide the default value semantics defined in this profile on JSON objects, since JSON objects cannot provide default values themselves. 

 

For example, an application may implement wrapper classes which can express all the entities and attributes defined in this profile, and can be bound to JSON object instances.  When application code requests an attribute/property value using a wrapper class, the wrapper class can check to see if that attribute/property is defined in the bound JSON object. If it is defined in the JSON object, it returns the JSON value(s). If it is not defined in the JSON object, the wrapper class can return the appropriate default value for that attribute/property.

 

Alternatively, an application may instead traverse the JSON objects immediately after receipt and inject default values for attributes/properties not present in the JSON object. This avoids the wrapper classes but uses more memory than a default-on-demand approach.

 

-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: Monday, July 09, 2012 11:29 AM
To: xacml@lists.oasis-open.org
Subject: [xacml] Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded

 

Submitter's message
Integrated comments from XACML list. Enhanced the section on data-types. Added a class diagram for clarity. Changed tense to present. Removed overly explicit comparisons with XML representation.
-- Mr. David Brossard

Document Name: Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0


No description provided.
Download Latest Revision
Public Download Link


Submitter: Mr. David Brossard
Group: OASIS eXtensible Access Control Markup Language (XACML) TC
Folder: Specifications and Working Drafts
Date submitted: 2012-07-09 11:28:31
Revision: 1

 




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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]