MHonArc v2.5.0b2 -->
xacml message
[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
From: Anne Anderson <>
To: Daniel Engovatov <>
Date: Fri, 21 May 2004 09:19:28 -0400
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 <>
> To:
> 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:
> 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:
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel: 781/442-0928
Burlington, MA 01803-0902 USA Fax: 781/442-1692
