Dear Paul,
Very sorry about the delay in answering. I thought I had subscribed to
the list, but must have done something wrong when signing up. Thanks to
David for pointing out your post to me.
Just to make sure: you are talking about the XACML request context
schema, and not SAML, right?
Embedding the predicate inside the Attribute element is indeed an
interesting option for simple predicates of the form <attribute>
<operator> <constant>, such as the birthday example that you mentioned.
It would be harder though to express more complex predicates where
operations have to be performed on the attribute itself (e.g., first 5
characters of phone number are +4144) or where multiple attributes occur
in a single predicate (e.g., graduationdate - birthdate < 18Y).
I also agree that no changes to the policy language itself would be
required, but you would have to break open the schema of the XACML
request context, right? Wouldn't that already prevent these extensions
from being defined in a profile? Because that was what I was trying to
avoid in my "simple solution". But I definitely agree that multiple
interesting issues come up in the "more challenging solution" that I
sketched: how to communicate asserted predicates to the PDP, how to
evaluate a policy against a set of asserted predicates, and also how to
determine and communicate "missing predicates".
Best regards,
Greg
>
> -------- Original Message --------
> Subject: [xacml] Attribute Assertions in XACML request
> Date: Fri, 22 Oct 2010 08:15:57 -0500
> From: Tyson, Paul H <>
> To: xacml <>
>
> Regarding Gregory Neven's proposal for attribute conditions in the
> request context:
>
> Greg's approach to put the full <Condition> element syntax in a SAML
> assertion would work. But a simple change to the <Attribute> element
> structure in the request would also work.
>
> <Request>
> ...
> <Attribute AttributeId="example:bday" DataType="date-time">
> <AttributeAssertion
> FunctionId="...date-less-than">1990-10-01</AttributeAssertion>
> </Attribute>
> ...
> </Request>
>
> We allow <AttributeAssertion> in place of <AttributeValue>, and move
> DataType to the parent element. We re-use the function identifiers
> already defined in XACML.
>
> <AttributeValue> is actually a degenerate case of attribute assertion,
> which only allows equality, or name-value pairs. <AttributeAssertion>
> generalizes this to allow other predicates besides equality.
> <AttributeAssertion FunctionId="...equals"> would be the semantic
> equivalent of <AttributeValue> for each datatype.
>
> In keeping with the bag-of-attribute-values paradigm for the request
> context, we would probably have to assume a bag-of-attribute-assertions
> as well. While it is OK to put the "one-and-only" restriction on
> birth-date, it might be quite reasonable to have several assertions
> about birth-date.
>
> (Actually this example is a bit more complicated. You probably don't
> really want to write rules about birth-date. The laws or business rules
> are about age, so your rule condition would say "age >= 18". But the
> request context might only have values or assertions about birth-dates.
> In that case the PDP needs additional information to reach a decision.
> That's another interesting topic.)
>
> No change to the policy language is required; however, section 7 of the
> spec would have to specify the required behavior, which might be tricky.
> A PDP implementation could, for example, use a Prolog library to test a
> rule condition, "bday < 1992-10-22" against the assertion "bday <
> 1990-10-01" to return "true". But this sort of inference depends on
> axioms and rules of deduction outside of XACML.
>
> I don't have Greg's email. If anyone has his email, please forward to
> him.
>
> Regards,
> --Paul
>
> ---------------------------------------------------------------------
> 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
>
>
>
