OASIS eXtensible Access Control Markup Language (XACML) TC

Time: 13:00 EDT Tel: 513-241-0892 Access Code: 65998 Minutes for 2 June 2011 TC Meeting: note: "->" implies an "action item" I. Roll Call& Approve Minutes: Voting Members Erik Rissanen Axiomatics Paul Tyson Bell Helicopter Textron Inc. Doron Grinstein BiTKOO David Choy EMC Remon Sinnema EMC Sridhar Muppidi IBM David Chadwick Individual Bill Parducci Individual Rich Levinson Oracle Hal Lockhart Oracle John Tolbert The Boeing Company Members David Chadwick Individual have quorum Note: did not have quorum last week, so 19-May minutes still need approval 26 May TC Meeting - UPDATED 2: http://lists.oasis-open.org/archives/xacml/201106/msg00001.html approved "notes" of 26-may 19 May 2011 TC Meeting http://lists.oasis-open.org/archives/xacml/201105/msg00053.html approved minutes of 19-may II. Administrivia F2F: will be held in June 28th, 29, 30th in Lexington, MA Hal will create a poll to gather the final attendance count for the F2F, which is needed for planning facilities. -> Hal: please respond to poll. (action is on everyone else to respond) XACML TC Anniversary http://lists.oasis-open.org/archives/xacml/201105/msg00059.html XACML 3.0 core wd 20 uploaded Core http://lists.oasis-open.org/archives/xacml/201105/msg00070.html RBAC http://lists.oasis-open.org/archives/xacml/201105/msg00071.html mtg schedule: hal: back to 2 weeks? erik: not yet hal: ok, weekly for now, next mgt jun 9 david: could we schedule jun 16 mtg hour earlier? -> hal: we will discuss on jun 9 if we can move jun 16 1 hr earlier IIIa. New Issues three questions: string-not-equal& valid FulfillOn attributevalues & placement of variableDefintions (may be resolved w follow-up emails) http://lists.oasis-open.org/archives/xacml/201105/msg00102.html wd20 policy evaluation discussion: (may be resolved in followup emails) paul: http://lists.oasis-open.org/archives/xacml/201105/msg00095.html paul: issue is with target description; not sure objection to proposed wording: target matches, doesn't, ind. erik: same info is in the table; risk of keeping things in synch; table in 7.1.2? paul: not as good as could be, but is ok. Obligations/Advice combining ambiguities. (dependent on final version of combining algorithms) http://lists.oasis-open.org/archives/xacml/201105/msg00094.html rich: working assumption is that in deny-overrides that if there are multiple permit rules then all the applicable permits add their obligations to the response if decision is permit, as opposed to the deny decision, where only one rule's obls are returned. -> rich: will update impl guide w acm ref paper; also explain in a little more detail the "bundling of obligations" from the non-biased decision (i.e. the permit in deny-overrides, etc.) Permit Deny Bias PDPs& Extended Indeterminate this issue appears resolved w no changes required: http://lists.oasis-open.org/archives/xacml/201105/msg00112.html rich: resolved - everything ok, as is IIIb. Issues Active on List Indeterminate Policy Target handling possible proposal to resolve: erik/rich: http://lists.oasis-open.org/archives/xacml/201105/msg00114.html erik: obligations wrt policies evaluated, important that policies should be understood wrt combining used rich: ok, want to see next draft before signoff -> erik: will prepare next draft PDP REST Interface - proposal - hal: http://lists.oasis-open.org/archives/xacml/201105/msg00093.html hal: has this discussion ended or is there more to come? erik: david b not here today, but issue is still active XACML Implementers Guide - updated w some cautions on ref: (note: the ref also needs update to published acm version, which addresses some of the concerns mentioned) Groups - XACML Implementor's Guide Version 3.0 (xacml-implement-guide-3.0-02-05.doc) uploaded http://lists.oasis-open.org/archives/xacml/201105/msg00113.html Attribute predicate profile for SAML and XACML - ray comment http://lists.oasis-open.org/archives/xacml/201105/msg00088.html IV. Carryover Issues (last posting listed) XACML Metadata http://lists.oasis-open.org/archives/xacml/201105/msg00004.html Attribute predicate Profile for SAML and XACML http://lists.oasis-open.org/archives/xacml/201104/msg00080.html Break The Glass Profile http://lists.oasis-open.org/archives/xacml/201104/msg00082.html hal: david should bring us up to date on where we left off; david: still before proposal stage; should pdp signal a btg response hal: does pdp know to signal btg by evaluating policy david: yes, can be by an attribute (state); if attr set to true it would give one answer, if false then a btg answer; if glass wasn't broken, it would say you are entitled to break the glass; hal: we have 2 mechanisms: missing attr w indeterminate, or in policy can have obl or advice on deny; david: based on attr modeling whether state glass is broken; if btg is provided can make decision, if not, can't. rich: it sounds like it is profile using existing mechanisms, which seems like all ok. david: agrees david: pep can ignore the advice; hal: are there any open technical issues david: no; remaining question is what does pep do in response? one opinion is that pep does everything automatically, other is w obligations such as notify parts some people think it's all over w pdp, others think that you go back to pdp; david: pdp signals w advice, obl in v2, and 2 options on pep: coord w pdp, and ind of pdp. hal: why doesn't pdp interact w authority sufficient? policy does the alg and calculates answer; state type authority to keep track of btg; david: that model w glass mgr, still needs req to ask state; erik: "in coord w pdp" needs to be more specific: david: policy rule about who is allowed to do btg; 2nd rule is about btg'ing itself; state is maintained; erik: pdp controls acces to chg the state info. david: yes. hal: policy controls the btg as resource; -> david: will update the profile Profile Examples (Hierarchy) http://lists.oasis-open.org/archives/xacml/200910/msg00024.html PIP directive (additional information directives) http://lists.oasis-open.org/archives/xacml/201010/msg00005.html Usage of status:missing-attribute in case of an AttributeSelector http://lists.oasis-open.org/archives/xacml/201104/msg00003.html "Web Friendly" Policy Ids http://lists.oasis-open.org/archives/xacml/201103/msg00046.html Specifying a specific associated Resource in a Policy (Sticky Policies) http://lists.oasis-open.org/archives/xacml/201103/msg00012.html

All,


>
Original Message-----
> From: rich levinson [ mailto:rich.levinson@oracle.com ]
> Sent: Friday, June 03, 2011 12:52 AM
> To: xacml
> Subject: [xacml] Minutes for 2 June 2011 TC Meeting

[...]

> Obligations/Advice combining ambiguities. (dependent on final
> version of combining algorithms)
> http://lists.oasis-open.org/archives/xacml/201105/msg00094.html
>
> rich: working assumption is that in deny-overrides that if there
> are multiple permit rules then all the applicable permits
> add their obligations to the response if decision is permit,
> as opposed to the deny decision, where only one rule's obls
> are returned.
>

I'm not sure I like this. First of all, this means there is an asymmetry between the permit and deny cases, as noted on the call. Secondly, this assumption rules out the following performance improvement: For deny-overrides, once an applicable permit rule has been found, other permit rules don't need to be evaluated, since they can never change the decision.

Thanks,
Ray

Hi Ray/TC, I agree, I don't like it either, which is why I wanted to state it explicitly so we all know what the current behavior implies, at least based on my reading of the text to date. My statement was that is how I understand the current operation to be, although it is not clearly and unambiguously stated in the text. However, I am not sure what other option might be inferred from the text, although your suggestion sounds like a reasonable alternative, if we were to explicitly state it that way. In any event, once the current behavior is clarified, then whatever it is can be considered the default option, and for 3.0, at least, if devs want to offer other options then they can be custom w combiner parameters, which is what would be explained in the implementers/ policy designers guide - explained so designers would know what to look for and devs would know what to implement. Thanks, Rich On 6/6/2011 5:27 AM, remon.sinnema@emc.com wrote: > All, > > >>
Original Message----- >> From: rich levinson [ mailto:rich.levinson@oracle.com ] >> Sent: Friday, June 03, 2011 12:52 AM >> To: xacml >> Subject: [xacml] Minutes for 2 June 2011 TC Meeting > [...] > >> Obligations/Advice combining ambiguities. (dependent on final >> version of combining algorithms) >> http://lists.oasis-open.org/archives/xacml/201105/msg00094.html >> >> rich: working assumption is that in deny-overrides that if there >> are multiple permit rules then all the applicable permits >> add their obligations to the response if decision is permit, >> as opposed to the deny decision, where only one rule's obls >> are returned. >> > I'm not sure I like this. First of all, this means there is an asymmetry between the permit and deny cases, as noted on the call. Secondly, this assumption rules out the following performance improvement: For deny-overrides, once an applicable permit rule has been found, other permit rules don't need to be evaluated, since they can never change the decision. > > Thanks, > Ray >

Hi all, The "proper" way to fix this would be to explicitly include obligation processing in each combining algorithm, rather than having it on the side in a different section, saying that obligations from any policy "which is evaluated" is included. In my opinion it would be worth fixing this. Best regards, Erik On 2011-06-06 14:59, rich levinson wrote: > Hi Ray/TC, > > I agree, I don't like it either, which is why I wanted to state it > explicitly so > we all know what the current behavior implies, at least based on my > reading of the text to date. > > My statement was that is how I understand the current operation > to be, although it is not clearly and unambiguously stated in the text. > > However, I am not sure what other option might be inferred from the > text, although your suggestion sounds like a reasonable alternative, if > we were to explicitly state it that way. > > In any event, once the current behavior is clarified, then whatever > it is can be considered the default option, and for 3.0, at least, if > devs > want to offer other options then they can be custom w combiner > parameters, which is what would be explained in the implementers/ > policy designers guide - explained so designers would know what to > look for and devs would know what to implement. > > Thanks, > Rich > > > On 6/6/2011 5:27 AM, remon.sinnema@emc.com wrote: >> All, >> >> >>>
Original Message----- >>> From: rich levinson [ mailto:rich.levinson@oracle.com ] >>> Sent: Friday, June 03, 2011 12:52 AM >>> To: xacml >>> Subject: [xacml] Minutes for 2 June 2011 TC Meeting >> [...] >> >>> Obligations/Advice combining ambiguities. (dependent on final >>> version of combining algorithms) >>> http://lists.oasis-open.org/archives/xacml/201105/msg00094.html >>> >>> rich: working assumption is that in deny-overrides that if there >>> are multiple permit rules then all the applicable permits >>> add their obligations to the response if decision is permit, >>> as opposed to the deny decision, where only one rule's obls >>> are returned. >>> >> I'm not sure I like this. First of all, this means there is an >> asymmetry between the permit and deny cases, as noted on the call. >> Secondly, this assumption rules out the following performance >> improvement: For deny-overrides, once an applicable permit rule has >> been found, other permit rules don't need to be evaluated, since they >> can never change the decision. >> >> Thanks, >> Ray >> > > --------------------------------------------------------------------- > 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

I agree that the core spec should be improved with respect to obligation-combining.

But I'm not sure now is the time to do it unless we want to delay 3.0 indefinitely. We don't have any good use cases or requirements around obligation processing (unless there are some from the 2.0 days), so we would spend some time digging up use cases and requirements before we could consider design options.

A purely mathematical approach that only considered possible collections of obligations would probably not meet any business needs. One goal of the design should be to reduce the indeterminacy as much as possible so the policy writer can predict what obligations/advice will be returned from a given request context.

I'm not sure we should tie obligation-combining with policy- or rule-combining, since they are really orthogonal concerns. An alternative design would be to define obligation-combining algorithms that can be specified by the policy writer. These algorithms would reduce the set of candidate obligations/advice to an actual return set. I haven't thought this out completely.

Regards,
--Paul

>
Original Message-----
> From: Erik Rissanen [ mailto:erik@axiomatics.com ]
> Sent: Tuesday, June 07, 2011 04:50
> To: xacml@lists.oasis-open.org
> Subject: Re: [xacml] Multiple obligations
>
> Hi all,
>
> The "proper" way to fix this would be to explicitly include obligation
> processing in each combining algorithm, rather than having it on the
> side in a different section, saying that obligations from any policy
> "which is evaluated" is included.
>
> In my opinion it would be worth fixing this.
>
> Best regards,
> Erik
>
> On 2011-06-06 14:59, rich levinson wrote:
> > Hi Ray/TC,
> >
> > I agree, I don't like it either, which is why I wanted to state it
> > explicitly so
> > we all know what the current behavior implies, at least based on my
> > reading of the text to date.
> >
> > My statement was that is how I understand the current operation
> > to be, although it is not clearly and unambiguously stated in the
> text.
> >
> > However, I am not sure what other option might be inferred from the
> > text, although your suggestion sounds like a reasonable alternative,
> if
> > we were to explicitly state it that way.
> >
> > In any event, once the current behavior is clarified, then whatever
> > it is can be considered the default option, and for 3.0, at least, if
> > devs
> > want to offer other options then they can be custom w combiner
> > parameters, which is what would be explained in the implementers/
> > policy designers guide - explained so designers would know what to
> > look for and devs would know what to implement.
> >
> > Thanks,
> > Rich
> >
> >
> > On 6/6/2011 5:27 AM, remon.sinnema@emc.com wrote:
> >> All,
> >>
> >>
> >>>
Original Message-----
> >>> From: rich levinson [ mailto:rich.levinson@oracle.com ]
> >>> Sent: Friday, June 03, 2011 12:52 AM
> >>> To: xacml
> >>> Subject: [xacml] Minutes for 2 June 2011 TC Meeting
> >> [...]
> >>
> >>> Obligations/Advice combining ambiguities. (dependent on final
> >>> version of combining algorithms)
> >>> http://lists.oasis-
> open.org/archives/xacml/201105/msg00094.html
> >>>
> >>> rich: working assumption is that in deny-overrides that if
> there
> >>> are multiple permit rules then all the applicable permits
> >>> add their obligations to the response if decision is permit,
> >>> as opposed to the deny decision, where only one rule's obls
> >>> are returned.
> >>>
> >> I'm not sure I like this. First of all, this means there is an
> >> asymmetry between the permit and deny cases, as noted on the call.
> >> Secondly, this assumption rules out the following performance
> >> improvement: For deny-overrides, once an applicable permit rule has
> >> been found, other permit rules don't need to be evaluated, since
> they
> >> can never change the decision.
> >>
> >> Thanks,
> >> Ray
> >>
> >
> > ---------------------------------------------------------------------
> > 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
>
>
> ---------------------------------------------------------------------
> 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

Paul,


>
Original Message-----
> From: Tyson, Paul H [ mailto:PTyson@bellhelicopter.textron.com ]
> Sent: Tuesday, June 07, 2011 3:12 PM
> To: Erik Rissanen; xacml@lists.oasis-open.org
> Subject: RE: [xacml] Multiple obligations
>
> I'm not sure we should tie obligation-combining with policy- or rule-
> combining, since they are really orthogonal concerns.

Obligations are to be returned from applicable rules *that were evaluated* (Section 7.18). Since the combining algorithms define which rules are evaluated, they also define which obligations are returned. So the two orthogonal concerns currently are tied.

I agree that this is not optimal.


Thanks,
Ray

All, I don't think combining decisions and combining obligations are orthogonal. Consider the case of the following (agreed, contrived) policy structure: PS1 ordered-permit-overrides Target: printing-enabled-for-user = true resource-id = printing P2 ordered-deny-overrides R3 permit printing with obligation "invoice-printing-cost" R4 deny printing if authentication-level = basic P5 ordered-deny-overrides R6 permit printing if staff-member = true with obligation "log-printing" Assume following request: Subject: subject-id = alice staff-member = true authentication-level = basic printing-enabled-for-user = true Resource: resource-id = printing R3 and R4 and R6 will all apply. R3 because the basic rule is that anybody with printing enabled on their account can print (given that they are invoiced). Except that R4 denies a user who is using only basic authentication. And R6 allows staff members to print regardless of level of authentication (and for free, but we want to log the access). Clearly we would like to correlate obligation combining with the combining of the decision, so that we don't invoice the staff member, although one of the leaf rules matched. However the decision from that R3 was later overridden by another rule R4, so the _reason_ why the access was permitted was different than the conditions in R3, so we should not apply the obligations from R3, since they are relevant only to the situation which R3 was about. Best regards, Erik On 2011-06-07 15:35, remon.sinnema@emc.com wrote: > Paul, > > >>
Original Message----- >> From: Tyson, Paul H [ mailto:PTyson@bellhelicopter.textron.com ] >> Sent: Tuesday, June 07, 2011 3:12 PM >> To: Erik Rissanen; xacml@lists.oasis-open.org >> Subject: RE: [xacml] Multiple obligations >> >> I'm not sure we should tie obligation-combining with policy- or rule- >> combining, since they are really orthogonal concerns. > Obligations are to be returned from applicable rules *that were evaluated* (Section 7.18). Since the combining algorithms define which rules are evaluated, they also define which obligations are returned. So the two orthogonal concerns currently are tied. > > I agree that this is not optimal. > > > Thanks, > Ray >

Erik/TC,


>
Original Message-----
> From: Erik Rissanen [ mailto:erik@axiomatics.com ]
> Sent: Tuesday, June 07, 2011 3:59 PM
> To: xacml@lists.oasis-open.org
> Subject: Re: [xacml] Multiple obligations
>
> All,
>
> I don't think combining decisions and combining obligations are
> orthogonal.
>
> Consider the case of the following (agreed, contrived) policy
> structure:
>
> PS1 ordered-permit-overrides
> Target:
> printing-enabled-for-user = true
> resource-id = printing
> P2 ordered-deny-overrides
> R3 permit printing with obligation "invoice-printing-cost"
> R4 deny printing if authentication-level = basic
> P5 ordered-deny-overrides
> R6 permit printing if staff-member = true with obligation
> "log-printing"
>
> Assume following request:
>
> Subject:
> subject-id = alice
> staff-member = true
> authentication-level = basic
> printing-enabled-for-user = true
> Resource:
> resource-id = printing
>
> R3 and R4 and R6 will all apply. R3 because the basic rule is that
> anybody with printing enabled on their account can print (given that
> they are invoiced). Except that R4 denies a user who is using only
> basic
> authentication. And R6 allows staff members to print regardless of
> level
> of authentication (and for free, but we want to log the access).
>
> Clearly we would like to correlate obligation combining with the
> combining of the decision, so that we don't invoice the staff member,
> although one of the leaf rules matched. However the decision from that
> R3 was later overridden by another rule R4, so the _reason_ why the
> access was permitted was different than the conditions in R3, so we
> should not apply the obligations from R3, since they are relevant only
> to the situation which R3 was about.

This makes perfect sense to me.

I would phrase it as follows. Combining algorithms aren't actually *combining* decisions, as there is no way to simultaneously Permit and Deny a request. One can only chose between them. So the combining algorithms are actually really doing *conflict resolution*. From that perspective, their job is to select one Rule from the potentially multiple Rules that are applicable to the request. And then it would make sense to return the Obligations associated with that one selected Rule only.

I'm wondering, therefore, why the spec mentions "evaluating" rules as a criterion for returning obligations? What was the rationale behind that wording?


Thanks,
Ray

On 2011-06-10 09:27, remon.sinnema@emc.com wrote: > Erik/TC, > > >>
Original Message----- >> From: Erik Rissanen [ mailto:erik@axiomatics.com ] >> Sent: Tuesday, June 07, 2011 3:59 PM >> To: xacml@lists.oasis-open.org >> Subject: Re: [xacml] Multiple obligations >> >> All, >> >> I don't think combining decisions and combining obligations are >> orthogonal. >> >> Consider the case of the following (agreed, contrived) policy >> structure: >> >> PS1 ordered-permit-overrides >> Target: >> printing-enabled-for-user = true >> resource-id = printing >> P2 ordered-deny-overrides >> R3 permit printing with obligation "invoice-printing-cost" >> R4 deny printing if authentication-level = basic >> P5 ordered-deny-overrides >> R6 permit printing if staff-member = true with obligation >> "log-printing" >> >> Assume following request: >> >> Subject: >> subject-id = alice >> staff-member = true >> authentication-level = basic >> printing-enabled-for-user = true >> Resource: >> resource-id = printing >> >> R3 and R4 and R6 will all apply. R3 because the basic rule is that >> anybody with printing enabled on their account can print (given that >> they are invoiced). Except that R4 denies a user who is using only >> basic >> authentication. And R6 allows staff members to print regardless of >> level >> of authentication (and for free, but we want to log the access). >> >> Clearly we would like to correlate obligation combining with the >> combining of the decision, so that we don't invoice the staff member, >> although one of the leaf rules matched. However the decision from that >> R3 was later overridden by another rule R4, so the _reason_ why the >> access was permitted was different than the conditions in R3, so we >> should not apply the obligations from R3, since they are relevant only >> to the situation which R3 was about. > This makes perfect sense to me. > > I would phrase it as follows. Combining algorithms aren't actually *combining* decisions, as there is no way to simultaneously Permit and Deny a request. One can only chose between them. So the combining algorithms are actually really doing *conflict resolution*. From that perspective, their job is to select one Rule from the potentially multiple Rules that are applicable to the request. And then it would make sense to return the Obligations associated with that one selected Rule only. > > I'm wondering, therefore, why the spec mentions "evaluating" rules as a criterion for returning obligations? What was the rationale behind that wording? > > > Thanks, > Ray > Remon, I think the rationale has been to avoid having to explicitly talk about obligations in each combining algorithm description. I don't like the way it is now. A better way to define it would be that each combining algorithm specification explicitly specifies which obligations are returned. As you say, probably the most meaningful way in most cases would be that we should view it such that there is ultimately a single leaf rule which "caused" the decision and obligations would come only from the path to this rule. In section 7.16 it says "If the PDP's evaluation is viewed as a tree of rules, policy sets and policies, each of which returns 'Permit' or 'Deny', then the set of obligations and advice returned by the PDP to the PEP will include only the obligations and advice associated with those paths where the effect at each level of evaluation is the same as the effect being returned by the PDP." This was perhaps intended to mean it. Things get more complicated if the combining algorithms do more than simple conflict resolution between policies, like for instance majority voting for the decision, in which case there would be more than one rule which "caused" the decision. All these cases would be easily defined on a case by case basis for each algorithm if the collection of obligations is specified in the combining algorithms rather than it's own section in the specification. For each algorithm we can include those obligations which make sense from a use case perspective, which would be to be collect those obligations to which belong to rules and policies which impacted the decision, not those which were later overridden. The case where there are more than one rule which actually could have caused the decision is more open in terms of what makes sense. that's what the obligation families working draft tries to address in part at least. Best regards, Erik

Erik,


>
Original Message-----
> From: Erik Rissanen [ mailto:erik@axiomatics.com ]
> Sent: Friday, June 10, 2011 1:26 PM
> To: Sinnema, Remon
> Cc: xacml@lists.oasis-open.org
> Subject: Re: [xacml] Multiple obligations
>

[...]

>
> I think the rationale has been to avoid having to explicitly talk about
> obligations in each combining algorithm description. I don't like the
> way it is now. A better way to define it would be that each combining
> algorithm specification explicitly specifies which obligations are
> returned.

I think I agree with you.


> As you say, probably the most meaningful way in most cases would be
> that
> we should view it such that there is ultimately a single leaf rule
> which
> "caused" the decision and obligations would come only from the path to
> this rule. In section 7.16 it says "If the PDP's evaluation is viewed
> as
> a tree of rules, policy sets and policies, each of which returns
> 'Permit' or 'Deny', then the set of obligations and advice returned by
> the PDP to the PEP will include only the obligations and advice
> associated with those paths where the effect at each level of
> evaluation
> is the same as the effect being returned by the PDP." This was perhaps
> intended to mean it.

That doesn't say whether the obligations of *all* such rules MUST be returned.


> Things get more complicated if the combining algorithms do more than
> simple conflict resolution between policies, like for instance majority
> voting for the decision, in which case there would be more than one
> rule
> which "caused" the decision.

I hadn't considered that possibility. I agree that that complicates things.


> All these cases would be easily defined on a case by case basis for
> each
> algorithm if the collection of obligations is specified in the
> combining
> algorithms rather than it's own section in the specification. For each
> algorithm we can include those obligations which make sense from a use
> case perspective, which would be to be collect those obligations to
> which belong to rules and policies which impacted the decision, not
> those which were later overridden.
>
> The case where there are more than one rule which actually could have
> caused the decision is more open in terms of what makes sense. that's
> what the obligation families working draft tries to address in part at
> least.

I was not aware of this effort, thanks for pointing it out. I will take a look.

Thanks,
Ray

On Jun 10, 2011, at 5:47 AM, <remon.sinnema@emc.com> wrote: >> Things get more complicated if the combining algorithms do more than >> simple conflict resolution between policies, like for instance majority >> voting for the decision, in which case there would be more than one >> rule >> which "caused" the decision. > > I hadn't considered that possibility. I agree that that complicates things. Also consider heterogenous Obligation definitions. PDP/PIP A Obligation = encrypt: 3DES PDP/PIP B Obligation = encrypt: AES-128 Both systems support an Obligation called "encrypt", but it means different things. This too is something that we attempted to address with ObligationFamilies (and why I suggest that if we are to "fix" the problem there needs to be a mechanism for PDP metadata to reference these constructs). b

On Jun 7, 2011, at 6:11 AM, Tyson, Paul H wrote: > I agree that the core spec should be improved with respect to obligation-combining. > > But I'm not sure now is the time to do it unless we want to delay 3.0 indefinitely. We don't have any good use cases or requirements around obligation processing (unless there are some from the 2.0 days), so we would spend some time digging up use cases and requirements before we could consider design options. There is a thread on the wiki that provides enough information to tackle this I believe ( http://wiki.oasis-open.org/xacml/ProposalForObligations ), however the scope of functional coverage is the is the crux of the problem with Obligations. Any "improved" solution must be able to handle extensions to any Use Case we conceptualize now. Simple examples that have been used in the past are Notify, Filter and Encrypt ( http://wiki.oasis-open.org/xacml/DiscussionOnObligations ). > A purely mathematical approach that only considered possible collections of obligations would probably not meet any business needs. One goal of the design should be to reduce the indeterminacy as much as possible so the policy writer can predict what obligations/advice will be returned from a given request context. Because Obligations are non-binary decisions I believe the solution to this needs to be referential. In other words, a source external to the Policy/PolicySet is needed that describes not only the precedence of Obligation types, but of Obligation values as well. Further, I believe that we need to complete the work on the the "meta policy" before a complete solution is possible because this seems to be the most logical place to persist/communicate what Obligations are supported by the PDP. This doesn't solve the problem of a federated system unfortunately (unless there was a mechanism to handle unaligned Obligation support amongst PDPs). > I'm not sure we should tie obligation-combining with policy- or rule-combining, since they are really orthogonal concerns. An alternative design would be to define obligation-combining algorithms that can be specified by the policy writer. These algorithms would reduce the set of candidate obligations/advice to an actual return set. I haven't thought this out completely. I do not think this is possible. In the past, the unbounded relationship between Policy/PolicySet means that the Policy writer must have awareness of the entire system to ensure the Obligation is applied as desired. b