[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] [Issue] How many resourceIds in request context?
On 5 January, Seth Proctor writes: 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 stand corrected. Seth convinced me that the spec currently does require at least one resource-id, but he never stated an opinion on whether that was goodness or not. > > 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. Part of the motivation for requiring "one and only one" was based on the need to index on something that would always be present. If we accept, however, that there are valid cases where policy is based on resource attributes other than resource-id, then an implementation that supplies its own default dummy resource-id (when none is present) will be more robust than one that depends on each application to provide the correct dummy value. Anne -- 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