Simplify the policy language model (XML schema) - Merge Obligation/Advice(Expression)s into one element

[cdanger]

In order to remove duplication in the XSD and in the XACML spec and possibly in implementation code, we propose to merge the Obligation and Advice (and similarly Obligations, ObligationExpression(s), AssociatedAdvice and AdviceExpression(s)) elements into one element, e.g. AssociatedNotice (name to be decided, see down below for suggestions), with a boolean attribute like isObligation = true|false to say this is an Obligation or an Advice.

This change is not backward compatible, therefore the target milestone should be next major release (4.0).

For the name of that new element replacing Obligation / Advice, here are a few suggestions:

1. AssociatedNotice isObligation="true|false" (optional attribute, default value: false);
2. AssociatedInfoItem isObligation="true|false" (optional attribute, default value: false);
3. AdditionalNotice isObligation="true|false" (optional attribute, default value: false);
4. AdditionalInfoItem isObligation="true|false" (optional attribute, default value: false);
5. PepAction required="true|false" (optional attribute, default value: false);

Options 1 and 2 are inspired by the existing AssociatedAdvice element from the XACML spec (list of Advice elements). Other suggestions are welcome, especially from native English speakers.

As a reminder, here are the current definitions of obligation / advice from XACML spec:

• Obligation: operation [...] that should be performed by the PEP in conjunction with the enforcement of an authorization decision.
• Advice: supplementary piece of information [...] provided to the PEP with the decision of the PDP.

To go into further details about resulting changes, if we take the first option - AssociatedNotice - as an example, this means the following changes:

• <ObligationExpression ObligationId="x" FulfillOn="Permit|Deny"> is replaced with <AssociatedNoticeExpression Id="x" isObligation="true" AppliesTo="Permit|Deny">;
• <Obligation ObligationId="x"> is replaced with <AssociatedNotice Id="x" isObligation="true">;
• <AdviceExpression AdviceId="x" AppliesTo="Permit|Deny"> is replaced with <AssociatedNoticeExpression Id="x" AppliesTo="Permit|Deny">;
• <Advice AdviceId="x"> is replaced with <AssociatedNotice Id="x">.

In Rules, the AppliesTo/FulfillOn is useless, Obligations/Advice should apply to the Rule's Effect always. So we should define a AssociatedNoticeExpressionType without the AppliesTo attribute for Rules, then a PolicyAssociatedNoticeExpressionType that extends the AssociatedNoticeExpressionType with the AppliesTo for Policies/PolicySets.

Plus, <Obligations>, <ObligationExpressions> and <AssociatedAdvice>, <AdviceExpressions> become obsolete if we change the XACML schema as follows:

1. Replace

<xs:element ref="xacml:ObligationExpressions" minOccurs="0"/>
<xs:element ref="xacml:AdviceExpressions" minOccurs="0"/>

... with:

<xs:element ref="xacml:AssociatedNoticeExpression" isObligation="true|false" minOccurs="0" maxOccurs="unbounded"/>

2. Replace

<xs:element ref="xacml:Obligations" minOccurs="0"/>
<xs:element ref="xacml:AssociatedAdvice" minOccurs="0"/>

... with:

<xs:element ref="xacml:AssociatedNotice" isObligation="true|false" minOccurs="0" maxOccurs="unbounded"/>

Note: it would be easy to provide an XSLT stylesheet that converts a Policy(Set) in the old model to the new.

[steven-legg]

I suggest simply Notice or Notification for the new element name with IsObligation or Obligatory for the new attribute name.
I agree with keeping the AppliesTo attribute name and dispensing with FulfillOn.

[steven-legg]

Back in 2013 I drafted "XACML v3.0 Obligation and Advice Authority (OAA) Profile Version 1.0" (link to be provided when the TC migration is finished) which described a solution for better handling the applicability of obligations and advice. The solution used a separate PDP to generate obligations and advice. However, most of the use cases could be solved by adding a condition to ObligationExpression and AdviceExpression. This feature request provides an opportunity to do that.

The XSD would be:

    <xs:complexType name="AssociatedNoticeExpressionType">
        <xs:sequence>
            <xs:element ref="xacml:Condition" minOccurs="0"/>
            <xs:element ref="xacml:AttributeAssignmentExpression" minOccurs="0" maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="Id" type="xs:anyURI" use="required"/>
        <xs:attribute name="IsObligation" type="xs:boolean" use="optional" default="false"/>
        <xs:attribute name="AppliesTo" type="xacml:EffectType" use="required"/>
    </xs:complexType>

So the obligation/advice/notice is only returned if the effect type matches and the condition is true. An absent condition is treated as true.

[cdanger]

Agreed 👍
One little tweak: if IsObligation is optional, then make the default value explicit:

<xs:attribute name="IsObligation" type="xs:boolean" use="optional" default="false" />

[steven-legg]

One little tweak: if IsObligation is optional, then make the default value explicit

Good idea; I've amended the XSD.

[cdanger]

The consensus of the active members of the TC is that the preferred base name is "Notice", which leads to "Notice", "NoticeExpressions" and "NoticeExpression" as element names and "NoticeType", "NoticeExpressionsType" and "NoticeExpressionType" as type names.

We seem to have consensus that instead of defining two versions of NoticeExpression, one for policies with AppliesTo and one for rules without AppliesTo, we will make AppliesTo optional and say in the prose that an absent AppliesTo means the NoticeExpression applies to both Permit and Deny. Rules can then just leave it out.