|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.|
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
- "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.
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.
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 >
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.
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.
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.
March 13, 2013 12:28 PM
TC; William Parducci
[xacml] Minutes 7 March TC Meeting
- action on ambiguity wrt set of
returned Obligations, Advice
I agree that a random number generator
produces a result that is indeterminate
and there is nothing ambiguous about
However, to apply that paradigm to the
present discussion, what we are then
discussing is a "random obligation
generator", which is quite different,
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.
if one rule had an obligation that
"apply a $10 charge to the
and a 2nd rule had an obligation
"apply a $500 charge to the
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
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.
March 12, 2013 11:46 AM
TC; William Parducci
[xacml] Minutes 7 March TC
Meeting - action on ambiguity
wrt set of returned
Not to quibble (because, imo, it is
important that discussions be
conducted w a
common understanding of the
terminology being used), but
Google/Webster online (google: defn
to more than
- Unclear or
has not been
I think #2
pretty much exactly describes the
situation wrt to Obligations. i.e.
in the spec:
pseudo-code represents the normative
specification of this combining
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
by this algorithm is not
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
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
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
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
March 08, 2013 4:20 PM
TC; Hal Lockhart
[xacml] Minutes 7 March TC
Meeting - action on
ambiguity wrt set of
To Hal, TC,
At yesterday's mtg I made the
point that was quoted in the
"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
rules. The following comment is
in the description of
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
advice provided by this
algorithm is not deterministic."
same comment appears in the
The same situation existed in
XACML 2.0 although the effect on
not as explicitly stated,
although there was one general
2.0 section 7.14 "Obligations".
8:28 PM, William Parducci
Time: 15:00 ET (GMT-0500)
I. Roll Call
Hal Lockhart (Chair)
Bill Parducci (Chair, minutes)
Quorum: YES (8 of 11 - 72%)
21 February 2013 TC Meeting
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
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.
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
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
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: