OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [xacml] Using XACML Policies to Express Scope in OAuth


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]