"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