OASIS eXtensible Access Control Markup Language (XACML) TC

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  

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

That’s a fair point.  Attribute values aren’t going to show up in responses except for obligations and advice which are fairly rare.   Ok, false alarm.  The profile doesn’t need to discuss how to supply default values.   -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: Thursday, July 12, 2012 1:31 PM To: Danny Thorpe Cc: xacml@lists.oasis-open.org Subject: [xacml] 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

Yes, and in advice / obligations, I don't think we can escape the default XACML representation anyway so no need for default values. On Thu, Jul 12, 2012 at 10:57 PM, Danny Thorpe < Danny.Thorpe@quest.com > wrote: That’s a fair point.  Attribute values aren’t going to show up in responses except for obligations and advice which are fairly rare.   Ok, false alarm.  The profile doesn’t need to discuss how to supply default values.   -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: Thursday, July 12, 2012 1:31 PM To: Danny Thorpe Cc: xacml@lists.oasis-open.org Subject: [xacml] 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 -- 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