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 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]