[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Proposal for dynamic obligation parameters
All, Several XACML users (David Chadwick and John Tolbert) have presented use cases which could be solved if obligations could contain an expression which is evaluated by the PDP, rather than only a static attribute value. I have thought about this in the past as well, but I don't remember the specific use cases. And, ironically, the XACML examples in the 2.0 and current 3.0 draft specs try to implement this through a kludge where the obligation contains a static string which contains an XACML expression in XML form, which the PEP is supposed to evaluate. This approach is not a good one because it means the PEP must than contain an XACML implementation and also the PEP might not have the same context handler available as the PDP, so it won't have the same capability as the PDP. (This is crucial for Dadid Chadwick.) I know that we have agreed on a feature freeze for 3.0, but I suggest that we consider this one change before we go to CD. The change is as follows: Currently the 3.0 draft schema says this: <xs:element name="Obligation" type="xacml:ObligationType"/> <xs:complexType name="ObligationType"> <xs:sequence> <xs:element ref="xacml:AttributeAssignment" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="ObligationId" type="xs:anyURI" use="required"/> <xs:attribute name="FulfillOn" type="xacml:EffectType" use="required"/> </xs:complexType> <xs:element name="AttributeAssignment" type="xacml:AttributeAssignmentType"/> <xs:complexType name="AttributeAssignmentType" mixed="true"> <xs:complexContent mixed="true"> <xs:extension base="xacml:AttributeValueType"> <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> I propose that we keep the above elements as they are in the schema for the Response part, but in policies we replace use of the obligation with the following schema: <xs:element name="ObligationExpression" type="xacml:ObligationExpressionType"/> <xs:complexType name="ObligationExpressionType"> <xs:sequence> <xs:element ref="xacml:AttributeAssignmentExpression" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="ObligationId" type="xs:anyURI" use="required"/> <xs:attribute name="FulfillOn" type="xacml:EffectType" use="required"/> </xs:complexType> <xs:element name="AttributeAssignmentExpression" type="xacml:AttributeAssignmentExpressionType"/> <xs:complexType name="AttributeAssignmentExpressionType"> <xs:sequence> <xs:element ref="xacml:Expression"/> </xs:sequence> <xs:attribute name="AttributeId" type="xs:anyURI" use="required"/> </xs:complexType> The PDP shall evaluate the expression contained in the <ObligationExpression> in the policy and return a regular <Obligation> from it. Here is an example using an <Apply>, but other expressions such as <AttributeValue> and <AttributeDesignator> can also be used: <ObligationExpression ObligationId="some-obl"> <AttributeAssignmentExpression AttributeId="urn:...:foo"> <Apply> .... </Apply> </AttributeAssignmentExpression> </ObligationExpression> Let's say that the apply results in a string value "bar", then the response would contain this: <Obligation ObligationId="some-obl"> <AttributeAssignment DataType="http:....#string" AttributeId="urn:...:foo">bar</AttributeAssignment> <Obligation> Backwards compatibility is handled. The response is the same as before and a 2.0 policy can be translated to an ObligationExpression which contains a static <AttributeValue> element. Best regards, Erik
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]