Hal:
>I assert without
>> proof that Privacy sensitive Attributes will tend to disappear under
>> optimization since they will usually be employed in a direct Boolean
>> test. Do you have a counter example in mind?
>
> The attribute identifiers of the Resource Owner disappear but the
> values can linger on. Suppose there is a rule like this:
>
> Permit if ... and (access.subject.clearance =
> resource.classification)
>
> This will reduce to:
>
> Permit if ... and ("Secret" = resource.classification)
>
> giving away Joe's clearance level. Any comparison between an access-
> subject attribute and an attribute in another category has the
> potential to reveal access-subject information that isn't relevant to
> the requested scope. You would have to ban such comparisons in
> expressions in your solution if the tokens aren't encrypted or if the
> Resource Server can't be trusted with the information.
>
> However, I was thinking more of something like this:
>
> Permit if ... and (access-subject.id = "Joe")
> and (resource.id = "Plan to Outsource the Call
> Center to India")
>
> which reduces to:
>
> Permit if ... and (resource.id = "Plan to Outsource the Call
> Center to India")
>
> giving away the existence of such a plan (which isn't one of Joe's
> files).
> The rule could instead be:
>
> Deny if ... and not (access.subject.subject-role = "Board
> Member")
> and (resource.id = "Plan to Outsource the Call Center
> to India")
>
> which reduces to:
>
> Deny if ... and (resource.id = "Plan to Outsource the Call Center
> to India")
>
> if Joe isn't a board member, giving away the existence of a plan that
> even Joe doesn't know about.
>
> Even if privacy isn't an issue, stripping out the irrelevant stuff is
> still desirable from the point of view of minimizing the token size.
>
> Regards,
> Steven
These are all good points. I welcome your help as I try to formulate more precisely the selection and decapitation algorithms.
Hal
