RE: [xacml] Attribute Assertions in request context

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

I proposed a way to meet the requirement without changing the request
syntax, by using the fact that <AttributeValue> is an extension point.

After thinking about it, this is probably an unnecessary constraint.  We
could extend the request syntax and remain backward-compatible by
defining a new element, <AttributeAssertion>, and allowing a choice of
AttributeValue|AttributeAssertion  in <Attribute>.  The content model of
AttributeAssertion would be an Apply element.

If we back up and look for the root cause of this problem, it is simply
that the request context does not admit any predicates other than
equality.  If we relax this constraint then standard XACML can meet many
more use cases (including privacy protection).  And I do not think the
implementation burden is very great.  It does of course introduce a
greater range of indeterminate solutions, but this will have to be
addressed with better policies.  I don't see how this requires the
policy writer to have any more knowledge of the potential request
context than currently required (a concern expressed by Erik in [1])--in
fact, if the policy rules are true expressions of business requirements
there should be no change to existing policies.

I do not favor Greg's suggestions.  Although I initially proposed an
"assertion" datatype, I think this is the wrong direction.  It needs to
be an element (AttributeAssertion), with a content model that provides a
full predicate expression language (the xacml:Apply element).  We could
meet the need of "#the-certified-predicate" by defining a "this"
construct to use in the context of Attribute/AttributeAssertion/Apply to
refer to the AttributeId on the Attribute ancestor.  Other
AttributeDesignators would serve their normal purpose of referring to
attributes in the request context.

And the "#implies" function-id is not needed as a syntactic feature.
Policy evaluation (as defined in section 7 of the spec) is all about
deriving the truth-value of the logical implication represented by a
policy set.  Although abstractly, there's nothing wrong with including
explicit logical implications within a rule, I don't see any need to add
this as a standard function. 

I don't have time right now to work up a complete example, but will do
so as time permits.

Regards,
--Paul

[1] http://lists.oasis-open.org/archives/xacml/201101/msg00008.html

> -----Original Message-----
> From: Gregory Neven [mailto:nev@zurich.ibm.com]
> Sent: Thursday, January 13, 2011 11:38
> To: XACML
> Cc: Paul Tyson
> Subject: Re: [xacml] Attribute Assertions in request context
> 
> This is a response to Paul's message at [1], which was a follow-up to
> [2] and [3].
> 
> That's actually a quite interesting idea, Paul, to create a new
> datatype
> to embed a predicate as an AttributeValue, we didn't think of that. So
> would you envisage that the included <Apply> element contains a
> predicate that only involves the attribute specified in the enclosing
> <Attribute> element, or that it could involve other attributes as
well?
> In the latter case, it would actually offer the level of expressivity
> that we need to express, e.g., graduationDate < birthdate + 18Y.
> 
> I imagine though that using the same
> AttributeId="http://www.example.org/attributes/age"; with
> DataType=".../assertion" in the <Attribute> and <AttributeValue>
> elements and with DataType="...#integer" in an enclosed
> <AttributeDesignator> can cause problems.
> 
> Your suggestion inspired us for the following approach. How about we
> specify a profile that defines a new DataType
> "http://www.example.org/attpredicates#predicate";, a new AttributeId
> "http://www.example.org/attpredicates#the-certified-predicate";, and a
> new FunctionId "http://www.example.org/attpredicates#implies";. The
> DataType "...#predicate" is a complex type containing a single
> <xacml:Apply> element (which could actually contain the conjunction of
> multiple predicates by means of the "...:function:and" function). The
> XACML request context can specify a value for the attribute
> "...#the-certified-predicate", e.g.,
> 
> <Attributes
>        Category="...:access-subject">
> <Attribute IncludeInResult="false"
>             AttributeId="...#the-certified-predicate">
> <AttributeValue
>            DataType="...#predicate">
> <Apply
>          FunctionId="...:integer-greater-than-or-equal">
> <AttributeDesignator DataType="...#integer"
>                AttributeId="http://www.example.org/attributes/age";>
> <AttributeValue
>            DataType="...#integer">30</AttributeValue>
> </Apply>
> </AttributeValue>
> </Attribute>
> </Attributes>
> 
> In the policy, the policy author must explicitly specify that a
certain
> condition can be satisfied by a matching certified predicate, rather
> than having to provide full attribute values, by enclosing it in an
> <Apply> with the "...#implies" function, e.g.,
> 
> <Condition>
> <Apply FunctionId="...#implies">
> <AttributeDesignator DataType="...#predicate"
> AttributeId="...#the-certified-predicate"/>
> <AttributeValue DataType="...#predicate">
> <Apply FunctionId="...:integer-greater-than-or-equal">
> <AttributeDesignator DataType="...#integer"
> AttributeId="http://www.example.org/attributes/age";>
> <AttributeValue DataType="...#integer">30</AttributeValue>
> </Apply>
> </AttributeValue>
> </Apply>
> </Condition>
> 
> The entire logic of checking whether the certified predicate implies
> the
> condition in the policy can then be contained in the implementation of
> the "...#implies" function, which could be very simple by checking
> string equality modulo XML whitespace, or which could be more
> intelligent by calling out to Prolog as you suggested.
> 
> We can discuss during the upcoming call.
> 
> Best regards,
> Greg
> 
> [1] http://lists.oasis-open.org/archives/xacml/201011/msg00033.html
> [2] http://lists.oasis-open.org/archives/xacml/201010/msg00012.html
> [3] http://lists.oasis-open.org/archives/xacml/201011/msg00001.html
> 
> 
> 
> >    <Attributes
> >        Category="...:access-subject">
> >      <Attribute IncludeInResult="false"
> > 	       AttributeId="http://www.example.org/attributes/age";>
> >        <AttributeValue
> >            DataType="http://www.example.org/datatype/assertion";>
> > 	<Apply
> > 	    FunctionId="...:integer-greater-than-or-equal">
> >            <AttributeDesignator DataType="...#integer"
> >                AttributeId="http://www.example.org/attributes/age";>
> > 	<AttributeValue
> > 	      DataType="...#integer">30</AttributeValue>
> > 	</Apply>
> >        </AttributeValue>
> >      </Attribute>
> >    </Attributes>
> >
> > The syntax is ungainly, and not what you would design anew.  But it
> has
> > the advantage of using familiar terms and syntax.
> >
> > I believe the semantics and expected policy evaluation behavior
could
> be
> > specified very easily.  First it would be necessary to define a
xacml
> > datatype id for "assertion", which would allow (and limit) the
> content
> > of<AttributeValue>  to the XACML expression language.
> >
> > The next problem is how to specify the evaluation of a policy
against
> > this type of request context.  Prolog provides a good model for
this.
> > Here's a prolog rule that defines when the condition is true:
> >
> >    gte(R,A) :- R =>=(X,Y), A =>=(X,Z),>=(Z,Y).
> >
> > This defines a predicate, 'gte' (greater-than-or-equal) which is
true
> > iff the first argument (the Rule) is a '>=' expression with two
> > operands, the second argument (Assertion) is a '>=' expression with
> the
> > same first operand as the first expression, and the 2nd operand of A
> is
> > greater than or equal to the 2nd operand of R.
> >
> > So, 'gte(>=(X,21),>=(X,30))' returns "Yes" in a prolog system, but
> > 'gte(>=(X,21),>=(X,20))' returns "No".
> >
> > This can be made more general by adding clauses to the body of the
> rule:
> >
> >    gte(R,A) :- R =>=(X,Y), A =>=(X,Z),>=(Z,Y);
> >                R =>=(X,Y), integer(A),>=(A,Y);
> >                R =>=(X,Y), A =>(X,Z),>=(Z,Y).
> >
> > The 2nd clause allows the Assertion to be simply an integer (the
> age).
> > (This corresponds to having a bare AttributeValue in the request
> context
> > instead of an attribute assertion.)  The 3rd clause allows the
> Assertion
> > to be a strictly greater-than comparison.  If any of the clauses are
> > true, the predicate returns "Yes".
> >
> > My point is that Prolog or something like it could be used to
specify
> > the policy evaluation behavior for attribute assertions.  I
> demonstrated
> > here how it can be done for numerical comparisons.  This could be
> easily
> > extended to date comparisons.  I haven't looked at string
> comparisons,
> > but that should be straight-forward.  Regular expressions will be
> more
> > difficult, but we might be able to define a useful subset of regular
> > expression comparisons.  (But are there really any compelling use
> cases
> > for comparing a regular expression condition in a policy to a
regular
> > expression attribute assertion?)
> >
> > Regards,
> > --Paul
> >
> > [1] http://lists.oasis-open.org/archives/xacml/201010/msg00012.html
> > [2] http://lists.oasis-open.org/archives/xacml/201011/msg00001.html
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe from this mail list, you must leave the OASIS TC that
> > generates this mail.  Follow this link to all your TCs in OASIS at:
> > https://www.oasis-
> open.org/apps/org/workgroup/portal/my_workgroups.php
> >
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php