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

Hi David,

On 15/03/2013 10:15 PM, David Chadwick wrote:
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.

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.

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.

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.

> Thus the
combining rule is the meta policy that adjudicates the results of the competition.

If we want there to be ordering and selection between obligations, then we surely first need some new
combining algorithms that say how this is to take place, such as

Majority wins (and all their obligations are enforced)

There is no existing combining rule like this, but if there were, then I expect that
the relevant set of OA policies would be combined using deny-overrides.

Permit overrides with all obligations enforced

By combining the relevant set of OA policies using deny-overrides.

Permit providing there are no conflicting obligations

By combining the relevant set of OA policies using only-one-applicable.

Or if the obligations always conflict no matter what the situation, then they can be
described such that PEP cannot satisfy the obligations in combination and the access
will be denied by the PEP.

Permit in priority order

By combining the relevant set of OA policies using first-applicable. If the first applicable
OA policy doesn't actually have any obligations, then the combining OA policy set doesn't
return any obligations, thus suppressing the obligations when the situation warrants it.
This is also due to deliberate construction, not the result of neglecting to do something.

The OA policies could also be constructed with conditions that exclude the situations
where the obligations are intended to be suppressed.


By etc. :-)


Without these higher level rules the obligation enforcement function will not know what behaviour is
expected of it



On 15/03/2013 08:58, Erik Rissanen 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,

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.


On Mar 14, 2013, at 9:11 AM, Erik Rissanen <erik@axiomatics.com
<mailto: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.


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.


On Mar 14, 2013, at 8:29 AM, Hal Lockhart <hal.lockhart@oracle.com
<mailto: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.
*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
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
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
    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
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
this would be too high a functional price to pay for a performance


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.
    *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):




     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.


    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.
        *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"
        rules. The following comment is in the description of
        "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",
        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".


        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


                Richard Skedd

               Quorum: YES (8 of 11 - 72%)

               Approve Minutes:

                21 February 2013 TC Meeting


            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.


                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


               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


                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


                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:


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:

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