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

[Anne Anderson - Sun Microsystems <Anne.Anderson@sun.com>]

"Seth Proctor" <seth.proctor@sun.com> wrote:
>> 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.

There was no consensus on the list, and it was not moving toward consensus.  The
default is to make no change to the existing specification unless it is actually
broken and could not work.

>> 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.

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/.

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.

By specifying the particular roots, we can ensure that the Attribute being
selected is in the correct element (i.e. is of the correct type).  Any implementation
that prepends strings must check to be sure that the expression does not use
. to back up over the pre-pended string.
 
>> 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.

We could clarify using language similar to that used in describing the
environment attributes: current-time, etc.

>Also, "AttributeDescriptor" should be "AttributeDesignator."
> 
>> 62. Subject: Two different URIs for access-subject
>>     RESOLUTION: Use
>>     "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?

The urn:...:subject-category:access-subject, etc. values are not Attribute
Identifiers.  They are attribute values.  Yes, all our defined Subject
Attribute Identifiers use :subject:<identifier>, and all Resource Attribute
Identifiers use :resource:<identifier>, etc., but that is not true for
Attribute values.

Anne
------
Anne Anderson          Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
Burlington, MA         781-442-0928