This raises a number of issues. 1. On the understanding that in SAML returning a wild carded decision assertion is purely an optimization that must be explicitly asked for by the requestor, I withdraw my objections. I still think this optimization is unlikely to be useful in practice, but if others disagree, I am willing to go along with it. Is the wildcard constrained to encompass the resource in the orginal request? 2. In a modern web environment, the existence of
http://www.mumble.com/x/y/z/a and
http://www.mumble.com/x/y/z/b by no means implies that
http://www.mumble.com/x/y/z is a directory. This may have been true in the mid 90's, but it is not true today. More likely all three resolve to distinct, dynamic pages. SAML functionality based on the premise that the path syntax represents a directory heirarchy, rather that merely an heirachical namespace would be an unreasonable constraint on local implementation. I am not saying the current proposal does this, I am just warning about going in that direction. 3. Its important to keep XACML separate. Since XACML is for policy exchange, it will need the richest possible language to express policy assertions. As I understand the current charter, it must be able to represent any possible resource name that can be expressed in XML (I don't think that excludes anything) and is not limited to XML documents. 4. According to RFC 2396, http:\...document.htmlBodyH1 is not a legal URI. I am aware that Microsoft is under the opposite impression, but I thought this was a open standards activity. At the least, if we are going to use URI we should identify the document defining it, if it is not RFC 2396. Hal >