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

[Polar Humenn <polar@syr.edu>]

On Mon, 2 Dec 2002, Seth Proctor wrote:

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

Hi Seth,

I think it was decided to keep "map" the way it is for the following
reasons:

1. First and foremost, it has been determined that the specification is
   not broken because "map" is polymorphic.

2. No change needs to be made to the spec, i.e. we do
   not have to introduce "integer-map", "string-map", etc., which further
   implies that we must make restrictions on the functions that can be
   applied to each <type>-map function.

3. Accepting <type>-map would enlarge our conformance test space.

I think that's about it. Anne, am I right with the summary?

Cheers,
-Polar


> > 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
> >     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?
>
>
> seth
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>