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] Minutes 7 March TC Meeting - action on ambiguity wrt set of returned Obligations, Advice

[David Chadwick]
>> I think we need to take the discussion up one level initially, and ask what does it mean for different
>> policies to permit (or deny) access providing its specific obligations are fulfilled, regardless of any
>> other policies decisions or obligations?
>> Surely this only has meaning if the combining rule says it does. So if the combining rule is permit
>> overrides, and one policy grants access without any obligations, then all other policies granting access
>> with obligations are irrelevant.

[Steven Legg]
> Or maybe the writer of the policy without obligations was supposed to add those obligations
> but neglected to do so. One of the motivations for me building the OAA was the realization
> that the people creating access policies are not necessarily the people who care about
> the obligations, especially in an environment where delegation is in use. For example,
> auditors care about obligations for auditing and logging, but project leaders setting
> access controls for their project's resources are far removed from those cares.
> Enabling the decoupling of obligation processing from decision processing using the OAA
> means that the auditors can determine when the obligations they care about are returned
> without having to rely on delegates to know, or do, anything about those obligations.

Agreed. This also makes management of the Obligations definitions, etc. much more practical.

[David Chadwick]
>> Each policy is not working in isolation (if it were there would not be an issue) but one might consider that
>> all policies are competing with each other for their decision to be the most important one.

[Steven Legg]
> Or cooperating. What you're talking about is obligations that depend not only on what
> access is granted/denied, but also on how that access is granted/denied, i.e., the
> reason for the decision. Since obligations can be about anything, we are going to find
> that some only depend on the "what" and some depend on the "what" and the "how", though
> the use cases I've encountered so far only depend on the "what". Fortunately, I can handle
> both with the OAA.

I believe that using Obligations for QoS would involve the "how" (or the "who" to be more precise), as would anything that generally involved "parameterized decisions". For example, Subject requests access to (abstract) Resource and Permit is granted with an Obligation that references explicit instance of Resource, where Obligation is based upon Subject (role, group) and/or Context attributes (date, load, availability, etc.)


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