[this is a resend with a more descriptive Subject line]
Here are some thoughts on the problem of how to deal with the Assertion
Type of an XACMLPolicyAssertion, XACMLAuthzCredential, or an
XACMLAuthzAssertion. The problem is how a client should match the
client's policy or implicit policy against the service's policy where
these XACML Assertions are used. "The policy assertion type is
identified only by the XML Infoset [namespace name] and [local name]
properties (that is, the qualified name or QName) of the root Element
Information Item representing the assertion. Assertions of a given type
MUST be consistently interpreted independent of their policy subjects."
Again, the three proposed new Assertion types are:
- XACMLPolicyAssertion: contains an entire XACML Policy or PolicySet
representing the authorization or access control policy that a service
wishes to publish externally. It may well be a subset of the actual
policies used internally. We would specify that no more than one
XACMLPolicyAssertion can be used in a single WS-Policy alternative (one
acceptable combination of Assertions).
- XACMLAuthzCredential: contains an XACML authorization decision in the
form of a SAML Assertion containing an instance of an
XACMLAuthzDecisionStatementType. The instance should contain the
associated Request Context in order to provide the proper context for
the decision. This Assertion is used to either require or provide an
authorization token or credential that is in the form of an XACML
authorization decision.
- XACMLAuthzAssertion: a constraint on an individual authorization
vocabulary element in the form of an XACML