Subject: RE: [xacml] URI-match function proposal
Colleagues - Attached is my first attempt to describe the use-case for a simple URL matching function. Let me know what you think. This is not an attempt to write a "flexible string matching language". But, perhaps it can coexist with the regular expression approach that Bill has described and that may be required to address more general requirements. All the best. Tim. -----Original Message----- From: Bill Parducci [mailto:email@example.com] Sent: Thursday, June 24, 2004 2:04 AM To: 'xacml' Subject: Re: [xacml] URI-match function proposal Michiharu Kudoh wrote: > I should have written that I am not trying to create yet another > regular expression match. I just tried to create a simple but useful > convention for hierarchy-wise matching. Since we are extending XACML > to support hierarchical resource, I think XACML needs to show a > right-focused hierarchical match solution that works on hierarchical > string representation (URI syntax). Some of them have been summarized > in the hierarchical resource profile document and this would be one > new addition to the profile (it means OPTIONAL) and i would offer that more will continue to show up as we encounter numerous examples that have not be covered by our attempt at writing a flexible string matching language. > Conventional regular expression standard could support our needs but > the reg-exp examples somehow loses policy writer's intuition on > hierarchy-wise matching (I am saying that policy writer could not > write that syntax). If hierarchy-wise matching expression could be > converted into reg-exp expression, it helps implementer. They don't > have to implement their own code for the hierarchy-wise matching. I > think we should focus on the issue of what is the right-focused > hierarchy-wise matching solution to XACML users, not only from > implementers' perspective. ultimately i agree, but i consider our first requirement to be deterministic policy interchange and i fear that the impreciseness of our matching semantics will impede that because we do not have something we can point to and say, 'that is a hierarchy' (as is the case with simple URIs, email addresses, etc.) via external reference and apply some implementation tweaks. > Re the syntax, I have no problem with removing '?' letter from my > proposal. Hierarchy-wise matching works only at the relativeURI > portion of the URI syntax and is supported only using "*", "**", and > "***". "*" and "**" are borrowed from Apache ANT. Only "***" is my > artifact but it is just a technical syntax sugar and useful for > representing a policy in concise manner. personally, i think the functionality of the '?' adds value and that is my point. there are many such mechanisms that have demonstrable value for making the corpus of policies more concise, my problem lies in our attempting to create the expressions for such. again, regex can be ugly and counterintuitive, but it IS precise and it can be tested very easily. i also have problems with the argument that regex impedes policy writers given that we expect XPath expressions to be used all over the place (i don't know too many non-IS types who can gen those reliably ;o) just my two cents. i was on board with 'simple extensions' originally but the discussion has changed my mind; i don't think the extensions will stay simple. b To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.p hp.
Locating and retrieving policies that use url.pdf