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


I look forward to seeing what such a mechanism would look like. :)

b


On Mar 15, 2013, at 9:00 AM, Erik Rissanen <erik@axiomatics.com> wrote:

Yes, we are in agreement here. :-)

Well, mostly. I don't think it's necessary for the PDP to have intimate knowledge of what the obligations mean. It's enough for it to have the mechanism to determine precedence.

/Erik

On 2013-03-15 16:21, Bill Parducci wrote:
I mean that if you have 2 Obligations that distill out from an access control decision that are in conflict (cannot be mutually implemented) there is no way for the PEP to process them. Precedence in this case refers the deterministic resolution of this situation. The PDP cannot solve this unless it has intimate knowledge of what the Obligations mean (absent by design, as Hal noted earlier) and a mechanism for determining precedence. Attributes within a Policy cannot address this (each Obligation could declare itself supreme) so it falls upon some sort of "common understanding" amongst Policy writers to ensure the Policies are written to ensure conflicts do not happen. This is not practical, nor possible in anything other than a tightly closed system.

"...whatever that might mean" is precisely the problem that I believe needs to be addressed if we are going to try to resolve this.

b

On Mar 15, 2013, at 7:11 AM, Erik Rissanen <erik@axiomatics.com> wrote:

It depends on what you mean by "solve precedence". It is already today possible to use obligations consistently by making sure that the way your rules in your policies match is such that the associated obligations never conflict. Trivially this can be done by making sure that all rules are disjoint and have the right set of obligations associated with them.

I am not saying that this is ideal. There certainly is room for improvement. I just want to point out that what we are looking for here is in the realm of syntactic sugar, similar to what combining algorithms are in a sense. So requirements likely need to be use case driven. And since obligations are so open ended, we'll never likely solve it for all cases, whatever that might mean. ;-)

Best regards,
Erik

On 2013-03-15 14:59, Bill Parducci wrote:
Yes, that is what I was referring to as well. By allowing the existing mechanism to distill the set of Obligations that are applicable to the access decision you have completed one half of what is necessary to implement an Obligation deterministically across systems. However, without unambiguous definitions and a precedence mechanism this is irrelevant from an interoperability standpoint. While one might be able to cobble up some sort of mechanism for self-description of Obligations, it is not possible to solve precedence within a Policy.

b

On Mar 15, 2013, at 1:58 AM, Erik Rissanen <erik@axiomatics.com> wrote:

With context I meant that an obligation only applies if a certain set of conditions permitted/denied the access. This is not about definitions and precedence of obligations. Like someone (Mohammad?) already said on the list, putting the obligations separately would lead to redundancies of the access decision conditions.

I haven't thought about it much, but there are at least the following to consider about obligations:

- The "consequence" of an obligation, that is, what the PEP has to do to enforce it.

- Related to the consequence are various "guarantees" about the enforcement, such as order, atomicity/rollback, etc, which perhaps should be managed independently, and could interact with other obligations.

- "When" an obligation applies. Today this is defined by the same policies as the access policies for the decision itself. There probably are good reasons for having it like this, I would think because the access policies define the various ways of permitting and denying access. The conditions for obligations probably are highly co-variant with the access conditions in most cases.

- Resolving "conflicting" obligations. We don't have anything about this in XACML explicitly, but by writing the right policies, conflicts could at least in theory be avoided, but it might not be nice to work in this way. This is somewhat analogous to combining algorithms in that in a sense combining algorithms are just syntactic sugar, since one could live without combining algorithms if one would always write the policies such that individual rules can never conflict. But it's easier to work with the rules if one can define rules and exceptions through combining algorithms. Something similar probably applies to obligations as well.

- Finding "all applicable" obligations. Again, there is nothing explicit in XACML for this, but by writing the right policies, one can make sure you get "all applicable" obligations, whatever that means. The choice of combining algorithms and how you split up your rule target/conditions make this possible. Again, maybe there should be something which makes this task easier.

Best regards,
Erik

On 2013-03-14 17:26, Bill Parducci wrote:
I think this may be resolved by allowing the "Obligation Set" (Obligations falling out from Policy Evaluation) to be "combined" by an authority which has access to unambiguous definitions and precedence. This would address the context concern and separate what I believe will ultimately be some fairly complex logic from basic evaluation. I do not think a Profile will solve anything but the most specific and brittle use case because all of this would have to be spelled out explicitly.

b

On Mar 14, 2013, at 9:11 AM, Erik Rissanen <erik@axiomatics.com> wrote:

There is the problem of the context of an obligation in relation to the authorization policy and the rules for the decision. They are not independent, which suggests that obligation processing should be part of the policy evaluation.

And like you say, the obligation lexicon is unbounded, which is a problem. I would think that any obligation combining mechanism will require obligation declarations of some kind. If the solution has to handle any obligation of any kind without any kind of metadata, then the problem is likely to be impossibly to solve, or the solution will consist of a language which has to be used to "hand code" on a case by case basis each obligation instance which is being processed.

Erik


On 2013-03-14 16:45, Bill Parducci wrote:
Agreed re: Policy evaluation. This is why I am personally warming to the concept of an Obligation Authority posted by others on the list. 

I do not believe that Policy evaluation should attempt to resolve this problem because: (1) the machinery necessary to address Obligations there will likely lead to a significant increase in complexity and overheard for basic evaluation: (2) as I have asserted for years, Obligations have a definitional issue that requires an authority higher than a Policy to resolve. It is relatively easy for us to come to agreement on the meanings of "Permit|Deny" ("Indeterminate" took a bit more wrangling :), but the Obligation lexicon is unbounded and not only requires a mechanism for registering Obligation types IMO, but also must have a mechanism for defining precedence for each "family" type as well (e.g. encrypt AES-256 > encrypt 3-DES).

Anyway, I am excited that TC is taking a serious look at this now. It is a fascinating topic and I believe that should we be able to come up with a cogent solution it will greatly add to the value of the XACML specification.

b

On Mar 14, 2013, at 8:29 AM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

Just to add to the historical record, Obligation support was optional in XACML 2.0 and prior versions. The view taken was that the highest priority was to calculate the Effect as rapidly as possible and that Obligations were a sort of frill.
 
There was also some concern about some IPR IBM disclosed relating to Obligations. IBM subsequently issued a non-assert statement for a large number of patents including those relating to Obligations.
 
Partly as a result, we decide to make Obligations MTI in V 3.0, but did not address all the implications of the new viewpoint.
 
The TC is free to reconsider these and other decisions at any time. However I think any change to Policy evaluation would require a Version 4.0.
 
I propose we first see how many of the requirements for Obligations implied by the Healthcare Obligation Profile, the Obligation Families Spec and other sources can be met without changing the current  PDP behavior. Then if it seems warranted we can take up the idea of changing the policy evaluation logic.
 
Hal
 
From: rich levinson 
Sent: Wednesday, March 13, 2013 12:28 PM
To: Hal Lockhart
Cc: XACML TC; William Parducci
Subject: Re: [xacml] Minutes 7 March TC Meeting - action on ambiguity wrt set of returned Obligations, Advice
 

Hi Hal,

I agree that a random number generator produces a result that is indeterminate
and there is nothing ambiguous about that.

However, to apply that paradigm to the present discussion, what we are then
discussing is a "random obligation generator", which is quite different, because
unlike "numbers" which may be regarded as equivalent in the functional context
of a random number generator, "obligations", in general, are not equivalent
in the same sense.

For example:

    if one rule had an obligation that said:
        "apply a $10 charge to the customer account"
    and a 2nd rule had an obligation that said:
        "apply a $500 charge to the customer account"

    then we'd have a situation where if the customer satisfied both rules
    that sometimes they would be charged $10 and other times they
    would be charged $500.

Therefore, I would assert that for any given customer transaction that
it is ambiguous how much the customer will be charged.

While this exact situation may not actually occur, it does demonstrate
the "nature of the ambiguity" that I have been addressing.

Furthermore, I am not saying it is right or wrong that the spec allows
for this situation, but that as the spec currently stands, this particular
situation, where one cannot accurately specify which obligations will
be produced for a given request, is an example of a situation where
the results may be considered ambiguous.

Finally, in terms of "optimization", my sense is that if the price of
optimization is such that one needs to introduce randomness to
the results, I would think that generally, for an authorization service,
this would be too high a functional price to pay for a performance
improvement.

    Thanks,
    Rich


On 3/12/2013 11:57 AM, Hal Lockhart wrote:
At the risk of pressing the good will of the TC, I still believe that a specification can describe behavior which is indeterminate without being ambiguous. For example, a spec can state than a random number, 128 bits in length must be included in a message. No one can predict what the number will be, but there is no ambiguity. I would argue that this case, like that of obligations meets both definitions you give.
 
Hal
 
From: rich levinson 
Sent: Tuesday, March 12, 2013 11:46 AM
To: Hal Lockhart
Cc: XACML TC; William Parducci
Subject: Re: [xacml] Minutes 7 March TC Meeting - action on ambiguity wrt set of returned Obligations, Advice
 
Hi Hal,

Not to quibble (because, imo, it is important that discussions be conducted w a
common understanding of the terminology being used), but according to
Google/Webster online (google: defn ambiguous):

am·big·u·ous  

/amˈbigyo͞oəs/

Adjective

  1. (of language) Open to more than one interpretation; having a double meaning.
  2. Unclear or inexact because a choice between alternatives has not been made
I think #2 pretty much exactly describes the situation wrt to Obligations. i.e. the statement
in the spec:
"The following pseudo-code represents the normative specification of this combining algorithm. 
The algorithm is presented here in a form where the input to it is an array with children
(the policies, policy  sets or rules) of the policy or policy set.
The children may be processed in any order, so the set of obligations or advice provided
by this algorithm is not deterministic."

Specifically, the "choice between alternatives" in terms of the order of processing is not
determined in advance, and so it is unclear which obligations will be produced, which
is precisely what's described in defn 2 of "ambiguous".

From an implementation point of view, this is more important than defn 1, which simply
has to do w unclear language, which can be identified and corrected. However, the 2nd
category of ambiguous, when correctly specified, as it appears to be in the spec really
makes the ambiguity a "property" of the system that it is up to developers to take
into consideration w their design and implementation.

One final note is that this "situation" was not introduced in 3.0, it existed in 2.0 as well.
What is different is that 3.0 goes into more detail defining the nature of the ambiguity.

  Thanks,
  Rich



On 3/12/2013 11:19 AM, Hal Lockhart wrote:
I am well aware of the fact that when the most common combining algorithms are used, different optimizing PDPs may produce different sets of Obligations from each other, given the same policies and inputs. If fact I was attempting to discuss exactly this issue in the context of reviewing Section 8 of the Healthcare Obligation s Profile.
 
In that context I made the following points. 1. This behavior has been understood and debated since XACML 1.0 it is not some kind of oversight. 2. A judicious choice of combining algorithms can force the evaluation of all policies containing Obligations and thus this is a question of whether to allow an optimization or not. 3. The Profile proposes a specific mechanism to force this evaluation, but since it alters PDP evaluation logic, it would be easier to get the Profile deployed if we could live without these new features. (The same goes for any PDP-based aspect of Obligation handling.)
 
An old argument of mine, which  I did not make last week and which I cannot prove is universally true is that generally policies can be easily structured so that Obligations are associated with the logic for the decision on the Effect and will generally produce the correct Obligations. For example, suppose one class of users can access the Resource under normal circumstances and another class of users can only access it under special conditions in which case the access should be recorded in the audit trail. By arranging to have the normal case checked first, the result will be that the audit will only happen under the special conditions.
 
During the call I was objecting to the fact that I thought you were describing the specification as “ambiguous”. The Merriam-Webster Collegiate Dictionary (the nearest one to hand) defines “ambiguous” as: “capable of being understood in two or more possible senses”. As the quote you cite makes clear, the specification is not ambiguous, more than one result is possible. The Obligations returned can depend on the PDP implementation. From the PEP’s point of view it is indeterminate, but the specification is not ambiguous.
 
IMO, Ambiguity in a Standard is Always a bug and must be fixed. However, allowing policy evaluation to produce different outcomes wrt Obligations may or may not be a good idea. Historically the view of the TC has been to allow optimized policy evaluation by default and let the policy author override it if he or she wishes to.
 
Hal
 
 
From: rich levinson 
Sent: Friday, March 08, 2013 4:20 PM
To: XACML TC; Hal Lockhart
Cc: William Parducci
Subject: Re: [xacml] Minutes 7 March TC Meeting - action on ambiguity wrt set of returned Obligations, Advice
 
To Hal, TC,

At yesterday's mtg I made the point that was quoted in the minutes that:
"There seems to be a level of ambiguity in the evaluation (of policysets,
 policies, and rules) that has ramifications on Obligations. "
The comment was based on my understanding of the "ordered" combining
rules. The following comment is in the description of "deny-overrides":
"The following pseudo-code represents the normative specification of this
 combining algorithm. The algorithm is presented here in a form where the
 input to it is an array with children (the policies, policy sets or rules) of the
 policy or policy set.
The children may be processed in any order, so the set of obligations or
 advice provided by this algorithm is not deterministic."

The same comment appears in the "permit-overrides",  "deny-unless-permit",
and "permit-unless-deny" algorithms.

The same situation existed in XACML 2.0 although the effect on Obligations was
not as explicitly stated, although there was one general comment in
2.0 section 7.14 "Obligations".

    Thanks,
    Rich




On 3/7/2013 8:28 PM, William Parducci wrote:
Time: 15:00 ET (GMT-0500)
 Tel: 513-241-0892
 
I.  Roll Call
  Voting Members
   Richard Hill
   Mohammad Jafari
   Steven Legg
   Rich Levinson
   Hal Lockhart (Chair)
   Bill Parducci (Chair, minutes)
   Remon Sinnema
   John Tolbert
 
  Members
   Richard Skedd
 
  Quorum: YES (8 of 11 - 72%)
 
  Approve Minutes:
   21 February 2013 TC Meeting
   APPROVED UNANIMOUSLY
 
II. Adminstrivia
  Future TC meeting times
   Options (ET): 9:00am, 4:30pm, 5:00pm, 11:00pm
   TC has 24 hours to submit additional time proposals to Bill who will
   create a ballot on the Oasis site, duration one week. Format "vote
   against" poll. results will be used to update time of TC meetings
   going forward.
 
  Status EC-US/IPC Profiles
   Passed review for CS status. Ready for Attestations.
 
  Interop
   John: Demonstrated new technology, went well. Higher degree of
         interoperatbilty demonstrated over pervious years.
   Action Item: Hal will gather materials from interop, confirm
                approval to share and post demo materials.
 
   Oasis is asking for 2014 participation now. Any interested parties
   are encouraged to voice interest as soon as is feasible by posting
   to the list.
   John: A Profile for ISMAP would make for an interesting demo
 
  XACML v3.0 Issues and Errata
   Hal: There is an official process for errata. Main limitation is
        only releasable annually. The wiki is likely the best place to
        capture the errata. 
 
III. Issues
 
  REST Profile
   Stephen: Example in REST Profile in what response should be
            (non-normative). Remon explained that the text was
            speculative based upon assumptions of operation.
   Hal: suggest that there is a comment that highlights this
        understanding.
 
  Starter Document/Obligation Profile for Healthcare
   Mohammed: some of the Obligation material goes beyond the HC Profile.
             Those things should come out into a more general Profile
             and retain the HC specific content in a separate profile.
   Hal: suggested mechanism for ensuring consistency of version in the
        TC discussion
 
  Obligations
   Hal: It is important that our next foray into Obligations should
        drive semantics into a workable solution. TC members should
        start considering requirements. Hal offered that his preference
        is that the PDP remain unchanged in Obligation processing.
        Perhaps PDP changes could be considered later. Use cases that
        would not allow for this requested. Finally, the relationship
        between Policy processing and Obligation need to be revisited
        to address Obligations that are part of Policies dropped during
        evaluation.
   Mohammed: Combining algorithms seem to ignore Obligations.
   Bill: There are some old discussions re: Obligations on the wiki for
         those interested in looking at the historical discussions.
 
 
  XACML v3.0 - multiple category elements, normative ambiguity?
   Rich: There seems to be a level of ambiguity in the evaluation that
         has ramifications on Obligations.
   Hal: Please post any such finding so that we can explore it
 
meeting adjourned.
 
 
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that 
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
 
 
 
 











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