OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xacml] [Issue] How many resourceIds in request context?

Colleagues - While the debate rages, I'll just remove the minOccurs
constraint from the schema of draft 4, which I expect to publish today.
Thanks to Seth for pointing out my error; put it down to a head cold.  All
the best.  Tim.

-----Original Message-----
From: Seth Proctor [mailto:Seth.Proctor@Sun.COM] 
Sent: Monday, January 05, 2004 12:53 PM
To: Anne.Anderson@Sun.COM
Cc: Tim Moses; 'XACML'
Subject: Re: [xacml] [Issue] How many resourceIds in request context?

On Mon, 2004-01-05 at 11:33, Anne Anderson wrote:
> Some people, including Hal and, I think, Seth, believe that there 
> absolutely must be one and only one resource-id attribute.  The 
> reasoning is that any Request must at least specify the resource-id in 
> order to know what is being accessed.

I don't know why you think I have such a strong opinion on this. I don't
think I've ever weighed in on this matter. I do believe that the spec
currently requires a valid Request to contain exactly one resource-id
attribute, so that requirement is in my open source project.

> I disagree with this view.  I believe a resource could be described 
> via attributes other than its resource-id.  For example, a Request 
> could ask for access to a resource that has a security label of "Top 
> Secret".  The policy may not care what the resource-id is, but is 
> willing to grant or deny access based on whether the Subject has a 
> corresponding security clearance attribute.

As it currently stands (see below) you can include any of these kinds of
attributes, as long as you also name the resource in question. In your
system you may not care about a resource identifier, so your PEP might
always just include some placeholder. There's nothing in the XACML
specification that keeps you from doing exactly what you've described here.

> If we ever support partial evaluation, then cases arise in which there 
> may be no resource attributes in the Request at all, because any 
> resource attributes have already been factored out of the policy to be 
> evaluated.  This applies also to subject and action attributes.

I think if we ever decide to support partial evaluation, we will have to
revisit several issues. For the time being, a separate question is whether
it's worthwhile to allow a Request with no identified Resource. I can't see
this being used very often, but I can think of some use cases (for instance,
an OS asking if a given user is allowed to invoke a given kernel function,
regardless of the resource). Again, these can be supported now (see above),
but it would be cleaner to make the resoruce optional. I'm probably easy
either way.

Now, as to Tim's orginal question (which you didn't actually address, I
don't think)...

> On 5 January, Tim Moses writes: [xacml] [Issue] How many resourceIds 
> in request context?  > From: Tim Moses <tim.moses@entrust.com>  > To: 
> 'XACML' <xacml@lists.oasis-open.org>  > Subject: [xacml] [Issue] How 
> many resourceIds in request context?  > Date: Mon, 05 Jan 2004 
> 11:12:20 -0500  >
>  > Colleagues - In section 6.3 of v1.1 we define the syntax for
>  > <xacml-context:Resource> thusly:  
>  > 
>  > 	<xs:element name="Resource" type="xacml-context:ResourceType"/>
>  > 	<xs:complexType name="ResourceType">
>  > 		<xs:sequence>
>  > 			<xs:element ref="xacml-context:ResourceContent"
>  > minOccurs="0"/>
>  > 			<xs:element ref="xacml-context:Attribute"
>  > minOccurs="0" maxOccurs="unbounded"/>
>  > 		</xs:sequence>
>  > 	</xs:complexType>
>  > 
>  > Consider the 5th line (... ref="xacml-context:Attribute" ...).
>  > 
>  > Below, we say:
>  > 
>  > "The <Resource> element MUST contain one and only one <Attribute> with
>  > AttributeId of "urn:oasis:names:tc:xacml:1.0:resource:resource-id"."
>  > 
>  > The "minOccurs="0"" in line 5 and the "one and only one" below it
appear to
>  > conflict.

As the specification stands now, the minOccurs line isn't needed. There will
always be at least the resource-id attribute. I don't see any problems with
removing that constraint.

>  > I expect we mean "no more than one".  Can I go ahead and change 
> this?  All  > the best.  Tim.

Sorry, I don't follow here. Where do we mean "no more than one"? The
Resource section may certainly contain more than one Attribute, though it
must always contain at least one. I think that the text is right, and the
schema should change (if we stay with the current requirement). If we decide
to make the resource-id attribute optional, then obviously both text and
schema should change.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]