Comments on Attribute predicate profile for SAML and XACML

[Paul Tyson <phtyson@sbcglobal.net>]

Greg and Franz-Stefan,

You have worked out how to handle the SAML part pretty well.  I have a
few suggestions.  I still don't agree with the local/global mapping
approach for XACML, but have an alternate proposal, as well as a
suggestion that might put the local/global mapping on a better footing
if it is really a required feature.

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.

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.

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.

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.

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.

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.

Regards,
--Paul