OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [xacml] Minutes of 12/02/02 comments subcommittee call

I knew this would come back to bite.

The original intent for the AttributeSelector was to be able to look into
the resource, should the resource or anything else exist as an XML
document. Somehow, it got mucked into looking into the RequestContext,
because the context is specified in XML, ho hum.

As far as I'm concerned the "selector" shouldn't be able to look in the
RequestContext at all, greatly simplifing matters.

The RequestContext is kept "notional", but specified in XML for the lack
of a using a good interface language.

I think the AttributeSelector should only be used to look into
XML based resources using XPATH, and not into the request context. That is
why we have the *AttributeDesignator stuff.


On Tue, 3 Dec 2002, Seth Proctor wrote:

> > You don't have to "guess".  If the AttributeSelector occurs in a Target Subject,
> > then pre-pend "Request/Subject.  If the AttributeSelector occurs in a Target
> > Resource, then pre-pend Request/Resource, etc.  If the AttributeSelector
> > occurs in a Condition, then prepend Request/.
> Well, you do have to "guess" since, as the original comments pointed out, the
> expression may already have been absolute, or may contain back pointers or
> other XPath wierdness. You can parse the expression, figure out what it has,
> and then do some pre-pending, but that's slower, and means you can't as
> easily use existing libraries (see next comment). If you require a valid
> XPath expression from the start, you don't need to worry about this, though
> you should probably check that you're pointing into the right part of the
> request (which _can_ be done with most libraries).
> > Such pre-pending is just for an implementation that somehow is able to use an
> > XPath library even though, as far as I know, no such library would be able
> > to deal with the "notional" Request Context and be helpful in resolving
> > attributes not supplied in the physical request.  Since a conforming implementation
> > must deal with such attributes, a conforming implementation will probably have
> > to parse XPath expressions itself (possible with some help), and can validate
> > the expression according to the XACML-specified root.
> Not true. A conforming implementation that uses AttributeSelectors must be
> able to look in the physical request document, and if nothing is found, it
> should pass the request on to the Context Handler. In this case, the first
> step can be done with an off-the-shelf XPath library, and if that fails, the
> expression can be passed to the Context Handler, which can choose what to
> do next. I'm not saying that this is the way it must be done, but it's
> certainly reasonable to expect that implementors will use existing libraries
> for this step (and probably use them in part for the next step).
> seth
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC