It is not a typo. I am not trying to guarantee that there is some known minimal information to work with. I believe some policies will refer to resource-id, and some others might refer to resource-category, or resource-location, or some other hypothetical attribute of the resource. I do not believe this is a barrier to inter-operability. We have stated that a PEP must have some awareness of the attributes that are required by policy writers who control access to resources the PEP is responsible for enforcing. How it gains this awareness is out-of-scope for XACML, although one method is for an initial request to receive an Indeterminate Response containing a Status message listing the required attributes. For XACML to require any particular set of attributes will severely limit the uses of XACML. Anne On 3 September, Polar Humenn writes: Re: [xacml] resource-id Attribute proposal > Below you say that the "minOccurs" for a resource should be zero, > yet you describe that "typically" it is is the "resource-id" attribute. > > I suspect it's a typographic error. However, if it is to set the minOccurs > to 1 and you only say "typically carries the resource-id" we haven't > bought much in the way of guaranteeing that there is some known minimal > information there to work with. > > -Polar > > On Fri, 30 Aug 2002, Anne Anderson wrote: > > > Summary of the issue: > > > > During the TC conference call on 29 August 2002, we discussed > > whether a Request <Resource> MUST contain an Attribute with > > AttributeId="...:resource-id". > > > > Polar argued that the resource might be identified by a more > > general attribute, such as classification level: the <Subject> > > is requesting access to all documents with the given > > classification level. > > > > Hal argued that this semantic implies that the PEP is doing its > > own finer-grained access control, which is not part of the > > XACML model, and that the specific resource to which access is > > being requested MUST be specified by its id. Hal also argued > > that there was a security problem if resource-id is not listed, > > since the policy might grant access to resources it did not > > intend. > > > > Proposal: > > > > I propose that we make minOccurs on <Resource> <Attribute> > > equal to 0, and use the following wording in describing > > <Resource> <Attribute>: > > > > "At least one Attribute must be present for the <Resource> if > > <ResourceContent> is not present. Typically, an Attribute with > > AttributeId equal to > > "urn:oasis:names:tc:xacml:1.0:resource:resource-id" will be > > present to identify the resource to which access is being > > requested." > > > > Comments: > > > > I do not think Hal's security issue holds up: if a policy wants > > to grant access only according to resource-id, then its target > > or conditions will always reference the resource-id attribute. > > In that case, if the attribute is not present, the policy will > > not apply or will be indeterminate. > > > > My proposal allows for several models of access control. It is > > up to a policy writer to determine which models the policies > > conform to. It is up to a PEP to know which attributes must be > > supplied for a given policy: one way to communicate this is > > through a "missing-attributes" status code in the <Response> to > > an initial <Request> that may contain minimal attributes. > > XACML does not need to specify the model for access control or > > the model for how required attributes are determined. > > > > Anne Anderson > > -- > > 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 subscribe or unsubscribe from this elist use the subscription > > manager: <
http://lists.oasis-open.org/ob/adm.pl > > > > > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <
http://lists.oasis-open.org/ob/adm.pl > > -- 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