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

A couple of questions/comments.

> 33. Subject: map function
>     RESOLUTION: keep "map" as is (un-typed)

After all the discussion on this point, can we at least get an explination
of how this was decided? I'd like to hear the justification for making one
function different than all the others.

> 52. Subject: 5.31 Element <AttributeSelector>
>     This comment was not resolved, and discussion is requested
>     from TC members, especially Michiharu and any other XPath
>     experts.  The following points were made:
> [...] 
>     Does XPath expression start with the <Subject>, <Resource>,
>     <Action>, or <Environment> element, or with <Request>, or, in
>     the case of <Target> elements, with the path following
>     <Subject>, <Resource>, or <Action>?

The XPath expression should be valid against the document, so it should
always start with the root of the document, Request. You may want to specify
that for attributes resolved outside the physical request document, it is
legal to start with some other root (which may aid the attribute resolver),
but otherwise you should require a valid XPath expression against the
request document.

>     -Request element is always implied.  XPath expression in Target
>      implies Subject, Resource, or Action.  XPath expression in
>      Condition implies only Request.  Implementations can pre-pend
>      Request/[Subject|Resource|Action] depending on whether the
>      expression appears in a Target or in a Condition if they want to
>      make use of an XPath library.
>     -But what if the XPath expression is an absolute expression?  Or
>      if it uses .. to back up and go down a different path?

Making the implementation guess at some pre-pending string is a very bad
idea. The second item above points out some of the reasons why. I can think of
no reason why it's easier or cleaner to allow this. The spec says now that the
expression must be valid against the request, and I think that's the right
way to go. Specify only that the expression must be valid, and then it's
always handled correctly.
> 60. Subject: A002
> [...] 
>     7.9.2 change: from
>     "The PDP SHALL reference the attributes as if they were in a
>     physical request context document, but the context handler is
>     responsible for obtaining and supplying the requested values."
>     to:
>     The "signature" of the interface between the PDP and the Context
>     Handler module has two inputs: an AttributeDescriptor or
>     AttributeSelector, and a Boolean "MustBePresent" value.  The
>     output from the Context Handler to the PDP is either a bag of
>     values or "Indeterminate" (in the case where an empty bag
>     resulted, but "MustBePresent" is true).  The Context Handler is
>     responsible for retrieving the referenced attribute value
>     regardless of whether the attribute was supplied in the original
>     Request context or whether the attribute is available elsewhere
>     in the system.

Hrm. I think the new language is more confusing than the old language, since
it's just defining an AD/AS, but it doesn't say that that's what it's doing.
Still, it makes it clearer that a PDP should be able to look outside the
physcial document for attribute values. One thing this still doesn't address
is the issue of when it has to look elsewhere: if values are found in the
physical document, does it still have to do a search? If a value is found at
one location, must the CH continue on, doing an exhaustive search? If this
is left undefined, then different implementations can produce different
results from the same request.

Also, "AttributeDescriptor" should be "AttributeDesignator."
> 62. Subject: Two different URIs for access-subject
>     "urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
>     rather than ...:subject:subject-category:..."

Is there a reason this was decided? All the other attributes are nested
in a namespace (like subject: or resource:), and since this is a subject
attribute, it seems like it should also be in the :subject: namespace if
it's going to look like all the other attributes. Otherwise, it isn't
a subject attribute...is that the intent?


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

Powered by eList eXpress LLC