Re: [xacml] resource-id Attribute proposal

[Anne Anderson <Anne.Anderson@Sun.com>]

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