Re: [xacml] Comments on Attribute predicate profile for SAML andXACML

[Gregory Neven <nev@zurich.ibm.com>]

Hi Paul,

Thanks for your comments, responses are in-line.

> 1. A suggestion for writing the SAML profile: instead of specifying the
> evaluation of AttributePredicate with reference to a hypothetical XACML
> policy evaluation, maybe you could just refer to section 7.4 of the
> XACML spec for how to evaluate expressions.

I guess we could, but Section 7.4 in the XACML spec seems somewhat 
short. Especially how AttributeDesignator elements need to be treated 
seems to need a bit of clarification, don't you think?

> 2. I had to read closely to determine that the required return type of
> the AttributePredicate/Apply/@FunctionId is boolean.  Consider putting
> this earlier in the description.

Okay, will do.

> 3. Is it necessary to allow multiple AttributePredicate elements in a
> query?  It seems simpler to have the relying party wrap its predicates
> in an "and" function if they want this behavior.

I agree that the semantics of having multiple predicates in a 
query/assertion is equivalent to an AND over the same predicates. When 
using the local/global attribute mapping that we proposed for XACML, 
though, it is quite likely that one may need assertions for multiple 
predicates (corresponding to multiple local variables). It makes sense 
to bundle the queries/responses for all these predicates in a single 
query/response.

> 4. I'm not too familiar with SAML, so I assume that the
> samlp:Status/samlp:StatusCode/@Value attribute is the conventional way
> to confirm or deny a SAML assertion?  For the purpose at hand it seems
> like a roundabout way of communicating the truth-value of a
> (potentially) complex predicate.  Rather than just echoing the predicate
> back to the relying party, could there be a dedicated
> AttributePredicateResponse with Result=true|false?  Optionally, the
> predicate could be returned as well.  This would be analagous to the
> XACML Response, with optional return of the Request attributes.

When a predicate is not explicitly included in the response, is it still 
possible to have the description of the predicate (and not just some 
ID/reference to it) be signed by the XML Signature? If so, then you're 
right, one could make the predicate optional in the response. If not, 
then there's a danger that, if the PEP and IDP communicate over an 
insecure connection or through redirects via the user, an adversary 
replaces the queried predicate with a fake predicate and so that a 
"true" response from the IDP would be misinterpreted by the PEP as being 
for the real predicate instead of the fake predicate.

> 5. Some of the preceding comments are to support a scenario that is not
> addressed in your proposal but was mentioned in the TC call of
> 2011-03-24.  That is, allow the PDP during the course of its evaluation
> to call an IDP to evaluate an AttributePredicateQuery.  The content of
> the query could be a literal chunk of the policy being evaluated, or a
> partially-processed chunk (e.g. with known attribute values in place of
> AttributeDesignator elements).  In either case, the query would have to
> conform to the restrictions given in the profile.  I would favor a very
> slim XACML profile to specify this sort of behavior--but I'm not sure
> just what needs to be specified, as it is really just an implementation
> option.  It does not affect the specified result of policy evaluation or
> add any syntactic or functional features to the XACML core.

I'm not sure I understand your point here. Which "restrictions given in 
the profile" do you mean, those specified in section 3.2 of our draft? 
Which sort of behavior do you exactly mean?

> 6. Policy evaluation using AttributePredicateQuery seems to obviate the
> need for local/global attribute mapping.  Weren't local boolean
> attributes introduced as a feature of an earlier design solution for
> this problem?  Now that the design has advanced further, they are not
> needed.  If however, there are real use cases requiring them, you should
> specify how to bind the local boolean attribute to the predicate over
> global attributes.  Your draft specifically excludes this mechanism from
> standardization, but that is exactly the point that would facilitate
> interoperability.  I have some ideas on that but will hold until the
> requirement is confirmed.

Do you mean that the attribute predicate profile as specified in our 
draft obviates the need for the local/global attribute mapping? I 
actually don't think so. As discussed before, there are some research 
challenges to be solved to feed the attribute predicates straight to the 
PDP and let the PDP decide whether they imply the policy or not. (Cf. 
the Prolog-style statements you once illustrated on the Wiki.)  As long 
as we haven't tackled those issues, the local/global translation 
solution is the best we have.

Greg