[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml-comment] Resource types
Paul Andrews, On 12/02/02, the XACML TC comments subcommittee resolved this comment by rewording Section A.12 Matching elements as in the attached document. Anne Anderson, Comments Editor On 22 November, Paul Andrews writes: [xacml-comment] Resource types > From: Paul Andrews <paandrew@cisco.com> > To: xacml-comment@lists.oasis-open.org > Subject: [xacml-comment] Resource types > Date: Fri, 22 Nov 2002 10:28:59 -0500 > > I note that the set of types allowed in a 'resource' element is restricted, > as is the match criteria. Given the nature of my employers business I would > like to be able to use types and match criteria that have not been defined. > My reading of the spec. shows that the accepted answer to that is to move > the resource specification to a 'condition' element instead, but that simply > begs the question of why a 'resource' element exists in the first place if a > 'condition' element can achieve the exact same thing (or conversely, if a > condition element can be extended, then why not a 'resource' element). > > I understand the desire to facilitate indexing, however moving a resource > match to a condition makes it difficult, i fnot impossible, to deduce the > role played by the arguments to the condition. This in turn makes it hard to > automatically translate the XACML representation of a policy into a > different representation (as might be necessary if the actual access control > were being performed by a legacy system). > > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > <HTML><HEAD> > <META http-equiv=Content-Type content="text/html; charset=iso-8859-1"> > <META content="MSHTML 5.50.4807.2300" name=GENERATOR></HEAD> > <BODY> > <DIV><SPAN class=072370915-22112002><FONT face=Arial size=2>I note that the set > of types allowed in a 'resource' element is restricted, as is the match > criteria. Given the nature of my employers business I would like to be able to > use types and match criteria that have not been defined. My reading of the spec. > shows that the accepted answer to that is to move the resource specification to > a 'condition' element instead, but that simply begs the question of why a > 'resource' element exists in the first place if a 'condition' element can > achieve the exact same thing (or conversely, if a condition element can be > extended, then why not a 'resource' element).</FONT></SPAN></DIV> > <DIV><SPAN class=072370915-22112002><FONT face=Arial > size=2></FONT></SPAN> </DIV> > <DIV><SPAN class=072370915-22112002><FONT face=Arial size=2>I understand the > desire to facilitate indexing, however moving a resource match to a condition > makes it difficult, i fnot impossible, to deduce the role played > by the arguments to the condition. This in turn makes it > hard to automatically translate the XACML representation of a policy > into a different representation (as might be necessary if the actual access > control were being performed by a legacy system). </FONT></SPAN></DIV> > <DIV><SPAN class=072370915-22112002><FONT face=Arial > size=2></FONT></SPAN> </DIV></BODY></HTML> -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692
Attachment:
A.12withPolarEditsAndArgOrder.doc
Description: Section A.12 Matchin elements - reworded
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC