Re: [security-services] Issues Status

[Polar Humenn <polar@syr.edu>]

On Thu, 14 Feb 2002, Hal Lockhart wrote:

> Here is the current status report.
>
> Irving, Prateek, Eve, Phill, Polar, RL Bob, Scott,Simon and Rob you are
> listed as Champions for issues. Please confirm that you agree with my
> assessment of the status.
>
> Document Authors look at the Red items and see if you need to make a change
> to close the issue.
>
> Ones I think are about to fall thru the cracks:
>
> I don't think the Empty Strings issue has been resolved or did I miss that?
>
> I think the spec should say that no attributes in an attribute query means
> "all the attributes you are entitled to see."  If this is not acceptable, I
> think it should at least say "the intended meaning is that all attributes
> available by policy should be returned. An implementation may not interpret
> this request as asking for no attributes."

I don't like the fact that if there aren't any attributes in the attribute
query it means "get me all" of them. This ruins the montonicity of the
function the service is providing. Which means special cases have to be
made when generating requests.

I've run into this problem in implemenations before, when automatically
generating requests for attributes by their types. Some systems due to the
access decision language and other dynamic information the attribute types
are automatically derived, which could be for no attribute types. All of a
sudden, it got a whole host of things it didn't want, which complicated
the process, not to mention slowed it down.

If the Query function is "get me the attributes that match these types"
and there aren't any types supplied, isn't the logical consistent thing to
do is maintain consitency and return no attributes?

Cheers,
-Polar

> We still do not have a "Bearer" Subject Confirmation method, even though the
> bindings spec says there is one.
>
> Hal
>
>