[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] Minutes of 20 May 2004 XACML Focus Group
I'm sorry I was not more clear. The discussion about a std URI syntax for hierarchical resources was *in addition to* the proposal to supply "resource-ancestor" and "resource-parent" Attributes. The new syntax just allows still more ways to state policies that will apply to hierarchical resources. Anne On 20 May, Daniel Engovatov writes: RE: [xacml] Minutes of 20 May 2004 XACML Focus Group > From: Daniel Engovatov <dengovatov@bea.com> > To: Anne.Anderson@Sun.COM > Subject: RE: [xacml] Minutes of 20 May 2004 XACML Focus Group > Date: Thu, 20 May 2004 13:15:04 -0700 > > Why was bag of "ancestor" completely rejected? > I implemented a test based on this idea - and it seems to work > beautifully without any string parsing baggage, as it is very efficient > to index. > > Daniel. > > > 3. Hierarchical Resources proposal > http://lists.oasis-open.org/archives/xacml/200405/msg00064.html > > There was general agreement that specifying a standard URI > syntax for identifiers of hierarchical resource components is > both do-able and useful. These names should conform to IETF > RFC2396: "Uniform Resource Identifiers (URI): Generic Syntax": > > <scheme> ":" <authority> "/" <pathname> > > where <pathname> is: > > <hierarchical component> [ "/" <hierarchical component> ]* > > The first <hierarchical component> should be the root of the > hierarchy at the <authority>. The syntax of each > <hierarchical component> should be the representation of the > component on the <authority> that hosts the resource. > > Since a single hierarchical resource may have multiple valid > values for <pathname> (such as a UFS file whose path contains > hard links), there must be a way to supply all valid > <pathname> values so that policies that refer to a particular > element in the hierarchy using one pathname will always be > able to match. Tentative conclusion is that multiple > :resource-id AttributeValues should be supported for this > (within a single <Resource>). All such AttributeValues must > refer to the same element in the <Resource>. > > Tim's URL match function proposal > (http://lists.oasis-open.org/archives/xacml/200405/msg00075.html > and following) can be used with the standard URI > representation of hierarchical resource elements to do matches > that take the hierarchical order of the elements into account. > > There was general agreement that Tim's URL match function > should be extended to cover all URIs, and not just URLs. > Since RFC2396 specifies that "/" is reserved as a separator > between hierarchical components of the identifier, this means > that matches can always be by component, regardless of the > actual component syntax for various URI schemes. > > [ACTION ITEM] Anne to produce new draft of the Hierarchical > Resources proposal that includes: > a. Standard URI syntax for hierarchical resources that are not > XML documents. > b. New, expanded version of Tim's URL match function to include > URIs in general. > > -- > 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 > > > 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_workgro > up.php. > -- 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]