Errata reguarding ReturnPolicyIdList feature in the JSON Profile

[Hal Lockhart <hal.lockhart@oracle.com>]

As noted by David Brossard, the JSON Profile contains the following table in section 4.2:

 

 

Attribute	Type	Default value
ReturnPolicyIdList	Boolean	False. ReturnPolicyIdList can be omitted in the JSON representation.
CombinedDecision	Boolean	False. ReturnPolicyIdList can be omitted in the JSON representation.
XPathVersion	String	There is no default value. The attribute is optional. It is REQUIRED if the XACML request contains XPath expressions.

 

Davis reports an error in the second row, which will be dealt with elsewhere.

 

The Default value cell in the first row is technically correct, but misleading IMO. It suggests that there is a functional difference between the XML and JSON formats, but the difference is actually only syntactic.

 

First some background. There are two related XACML features which in theory could either have been mandatory or optional. There is a PDP feature of providing a list of applicable Policy Ids for a given request. There is also the PEP feature of asking for such a list in a particular request. The item in the table is a Boolean used by the PEP to ask for the list.

 

The asking for a list on any given request must obviously must be optional for performance and compatibility reasons at least. If it is optional for any given request, it clearly must be acceptable for a PEP to never ask for it. Thus this has always been considered optional behavior.

 

The TC decided that the PDP feature of returning a list should be optional to implement. So both features are optional to implement at all.

 

Going back in XACML history, two general principles were adopted by this TC within the first year of its existence and we have maintained consistency with them ever since.

 

The first was that XML documents used for Security purposes should not depend on the use of default values. The reason was that in XML the defaults are specified in the Schema. The working assumption was that the schema might not be available at runtime. Therefore, two different implementations of a relying party might interpret the same assertion in different ways leading to a security flaw. This was actually first noted in the SAML TC and at that time (2001) we generally tried to follow SAML as much as possible, particularly in our use of XML.

 

The second principle was that for all optional  Elements and XML Attribues, the  name (tag) would be required to be present (typically with no value specified) even when the feature was not being used. The rationale for this was that it was asserted that it would make it easier to write tools which generated policies programmatically. Polar Humenn in particular advocated this.

 

One can argue whether these were good decisions or not, but that is what happened.

 

Consistent with these principles, the XML version requires that the Boolean XML Attribute “ReturnPolicyIdList” be present whether its value is true or false. No default was explicitly defined in the spec, although clearly it is intended to be optional, since PDP support is explicitly made optional.

 

In JSON, defaulting is used extensively and the notion of requiring unused features to appear in the message has been dropped.

 

I am not sure this really warrants an errata item, but if we are going to update the JSON Profile anyway, it probably makes sense to clarify this point.

 

Hal