With the difference that currently PDP can
not provide “resource-id” if it is omitted.
If it CAN provide it, when it is omitted –
then there is no reason to have it. As hierarchical relationship and
meaning of resource scope can be inferred by PDP without having to determine
the value of “resource-id”
-----Original Message-----
From: Satoshi Hada
[mailto:]
Sent: Monday, January
05, 2004 6:18 PM
To: 'XACML'
Subject: Re: [xacml] [Issue] How
many resourceIds in request context?
A complementary comment:
Section
10.2.5 says that the semantics of
"current-time",
"current-date", and "current-dateTime" attributes
are
NOT transparent to PDP since PDP must supply the values if omitted.
For
almost the same reason,
I
think the semantics of "resource-id" and "scope"
are
NOT transparent to PDP, too.
Satoshi
Hada
IBM Tokyo Research Laboratory
mailto:
Satoshi Hada/Japan/IBM@IBMJP
2004/01/06 09:24
To
"'XACML'" <>
cc
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.
One comment (based on Section 7.8 Hierarchical resources):
The following may be another motivation.
When a request context specifies a "scope" attribute,
I think that one and only one "resource-id"
attribute
must be specified. Otherwise, we cannot process
the "scope" attribute.
In this sense, "resource-id" is special
and
different from any other attributes.
Satoshi Hada
IBM Tokyo Research Laboratory
mailto:
Anne Anderson
<>
2004/01/06 04:02
Please
respond to
Anne.Anderson
To
"'XACML'"
<>
cc
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:
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311 Tel:
781/442-0928
Burlington, MA 01803-0902 USA Fax:
781/442-1692
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.
