Why? Why a rule without “resource-id”
can not be processed? If a particular point in the context defines hierarchical
relationship, it can be inferred from the context. Rules do not
need to contain that information.
What if the resource is defined as a
collection of name-value pairs, none of them having any special meaning?
What if you use multiple resources at the
same time? What if there are no resources?
Rule “Allow Joe to ENTER” –
for each case when action ENTER is defined, Joe is allowed – quite a
normal rule. Request is made – “Can Joe enter building A”
If “Building A” defines a hieratical structure (“sector B”
being one child) response may be: “Joe may enter building A” and “Joe
may enter building B”). This can be inferred from the context.
If one want s to write a rule that apply to a hierarchy of objects – that
still can be done using resource structure mapped into the XML document.
But there is no need to restrict general rule by requiring any particular
attributes to be present.
As far as indexing goes – requirement
for easy indexing is that the attribute and operation used for indexing is
efficient. Nothing else is needed.
From: Satoshi Hada
Sent: Monday, January
05, 2004 4:25 PM
Subject: Re: [xacml] [Issue] How
many resourceIds in request context?
>> Part of the motivation for requiring
"one and only one" was based
>> on the need to index on something that
would always be present.
comment (based on Section 7.8 Hierarchical resources):
following may be another motivation.
a request context specifies a "scope" attribute,
I think that
one and only one "resource-id" attribute
specified. Otherwise, we cannot process
sense, "resource-id" is special and
from any other attributes.
IBM Tokyo Research Laboratory
Re: [xacml] [Issue] How many resourceIds in
5 January, Seth Proctor writes: Re: [xacml] [Issue] How many resourceIds in
> On Mon, 2004-01-05 at 11:33, Anne Anderson
> > 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
> 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
I stand corrected. Seth convinced me that the
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
> > 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
> > 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
(when none is present) will be more robust than
one that depends
on each application to provide the correct dummy
Anne H. Anderson
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel:
Burlington, MA 01803-0902 USA Fax:
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_workgroup.php.