MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [xacml] [Issue] How many resourceIds in request context?
>> PDP can not provide $B!H(Bresource-id$B!I(B
if it is omitted. I did not mean that PDP must supply
the value of "resource-id" if it is omitted. I just meant that PDP must be aware
of the semantics of "resource-id" and "scope"as PDP must be aware of the semantics
of the three "current-*" attributes.>> As hierarchical relationship
and meaning of resource scope can be inferred by PDP >> without having to determine
the value of $B!H(Bresource-id$B!I(BYes, I know it may be possible, but
I believe that such a flexibility violates an interoperability of PDP implementations
since different PDP implementations
may implement different semantics of the "scope" attribute, that
is, it is up to a particular PDP implementation how to process the "scope" attribute.That's why I like the current description
of Section 7.8.Satoshi Hada
IBM Tokyo Research Laboratory
mailto:satoshih@jp.ibm.com
With the difference that currently
PDP can not provide $B!H(Bresource-id$B!I(B 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 $B!H(Bresource-id$B!I(B -----Original Message-----
From: Satoshi Hada [mailto:SATOSHIH@jp.ibm.com]
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:satoshih@jp.ibm.com
| Satoshi Hada/Japan/IBM@IBMJP
2004/01/06 09:24
|
|
>> 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:satoshih@jp.ibm.com
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
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]