[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Minutes from Focus Group Meeting 29 Jan 2004
>4. WI#18 Obligations in Rules > >Polar: issue with combinators. Formal semantics document points >out an existing issue. Have to know there are obligations >attached to rules; have to evaluate all policies. Polar not >happy with text that says "only obligations associated with rules >that are actually evaluated are used" this because it is >non-deterministic. I think that evaluation of policy (or policy set) with obligations is non-deterministic only if the policy uses either deny-overrides or permit-overrides. Policy with Ordered version, first-applicable, or only-one-applicable does not cause this non-deterministic problem. If you are saying that "the spec should give more text about this", then I agree. >Another problem with mixing Policies and PolicySets: may have >only a decision from a subordinate policy. If eval PS before >evaluating contained PS, if combinator changes its decision, then >it ditches all obligations that may have been emitted by >subordinate policies. If writing a policy in isolation and >expecting Oblig 1 to be true because effect is Permit, but these >are thrown away because enclosing policyset returns Deny, then >these are thrown away. >Semantics in specification are consistent, but the behavior is >not actually what policy writers may expect. As far as I understand, the case you wrote is also applicable to cases that has no obligations. (e.g. one of subordinate policy decision is permit but it can be turned over if a higher policy decision denies it). If you think throwing returned obligations away is the problem, one of the solution would be that the system generates an exception when the subordinate policy that includes obligation is reversed. >Tim would like to see a convincing use case. I think this extension is for economy. One of the example: Rule1: Silver member can access contents A at AM, provided $1 are charged per access. Rule2: Silver member can access contents A at PM, provided $1.5 are charged per access. <Policy algid="deny-overrides"> <Target>Silver member</Target> <Rule effect="permit"> <Condition>AM</Condition> <Obligation>payment $1</Obligation> </Rule> <Rule effect="permit"> <Condition>PM</Condition> <Obligation>payment $1.5</Obligation> </Rule> </Policy> The same semantics can be specified using policy instead of rules. <PolicySet algid="deny-overrides"> <Target>Silver member</Target> <Policy> <Rule effect="permit"> <Condition>AM</Condition> </Rule> <Obligation>payment $1</Obligation> </Policy> <Policy <Rule effect="permit"> <Condition>PM</Condition> </Rule> <Obligation>payment $1.5</Obligation> </Policy> </PolicySet> In this case, each policy includes only one rule just for specifying a condition. Best, Michiharu Anne Anderson <Anne.Anderson@Su n.COM> To XACML TC 2004/01/30 01:21 <xacml@lists.oasis-open.org> cc Please respond to Subject Anne.Anderson [xacml] Minutes from Focus Group Meeting 29 Jan 2004 XACML Focus Group Meeting 29 January 2004 Present: Anne Anderson (scribe) Simon Godik Tim Moses Polar Humenn Frank Siebenlist Agenda: Discuss open work items and see if group can produce recommendations on how to close them. 1. WI#58 Standard hierarchy schemas Frank says OGSI describes "service data"; resource properties document includes schemas for hierarchies; see http://www.globus.org/wsrs, although Frank will send out a more precise link. Things have changed since Frank last looked at it. 2. WI#7 ConditionReference Michiharu's current proposal is at: http://lists.oasis-open.org/archives/xacml/200401/msg00035.html Modifications to the policy schema are: + Create VariableDef element definition + Create VariableDef reference below PolicyType + Create VariableRef definition + Create VariableRef reference in ApplyCoreType + Modify Condition and ApplyType definition Polar not entirely happy about ApplyCoreType, but not sure how to fix it. VariableDef should also be able to be the contents of an ApplyCoreType, for example having a VariableDef that is the value "true". Simon agrees. Possible: make VariableDefType a choice. ACTION: Simon will post modified detailed proposal by Monday 2 Feb 2004, along with some text about how it should be used. Tim will put edited form into Draft 6. 3. WI#13 Optional Target Elements This is being done for economy and readability; it would not be backwards compatible. Polar is happy with the optionality of Subjects, Resources, Actions, [Environments] - thinks it is actually semantically more consistent. Simon prefers leaving it, but does not object if others want it. Polar notes that <Subjects></Subjects> is false. <Subjects> is modelled as a disjunctive sequence - absence of any elements is an edge case. ACTION: put Polar's note about <Subjects></Subjects> being false. 4. WI#18 Obligations in Rules Polar: issue with combinators. Formal semantics document points out an existing issue. Have to know there are obligations attached to rules; have to evaluate all policies. Polar not happy with text that says "only obligations associated with rules that are actually evaluated are used" this because it is non-deterministic. Another problem with mixing Policies and PolicySets: may have only a decision from a subordinate policy. If eval PS before evaluating contained PS, if combinator changes its decision, then it ditches all obligations that may have been emitted by subordinate policies. If writing a policy in isolation and expecting Oblig 1 to be true because effect is Permit, but these are thrown away because enclosing policyset returns Deny, then these are thrown away. Semantics in specification are consistent, but the behavior is not actually what policy writers may expect. Tim would like to see a convincing use case. ACTION: Michiharu to present a convincing use case. ACTION: Polar will try to develop a different approach based on the formal semantics document. That approach would require all policies to be evaluated [which may have a high cost in a distributed environment]. 5. WI#11 XACML Extension Points Discussed Simon's proposal in http://lists.oasis-open.org/archives/xacml/200401/msg00046.html: Allow element of type xacml:ParametersType as an optional child of xacml:PolicySet, xacml:Policy, xacml:Rule, and xacml:Obligations elements. If xacml:Parameters element is not empty, pdp must be able to process all xacml:Parameter elements. (Alternatives possible: 1 - pdp may ignore properties it does not understand, 2 - introduce MustUnderstand attribute to the xacml:Parameter element). Has to be pretty generic, but would like to prevent abuse. Simon has use case, Michiharu has use case (parameters to combining algorithms). "MustUnderstand" attribute should have to go into Parameters, not Parameter. Parameters is a list, not a set. Question about how many instances of Parameters can be in an instance of the schema. Question about using Parameters for Frank's policy issuer, location information, etc. - might need multiple instances of Parameters, each with an identifier to say what is contained: parameters for combining algorithms, policy issuer identification information, attribute location hints information, etc. Polar thinks parameters should not be contained inside the PolicySet, Policy, or Rule to which they apply, but should be outside, in parallel, attached by the composer of the enclosing policy[set]. Otherwise, there is no control over where the policy, policyset, etc. is used, and weighting parameter (e.g.) might not be appropriate in new context. Polar's alternative: replicate the structure in the combining algorithm, and attach parameters to elements there: e.g. "weighting associated with first policy you encounter is 3, weighting associated with second policy you encounter is 4", etc. Eliminates problem of PDP not understanding parameters: they would only occur inside the combining algorithm that does know how to use them. ACTION: Simon to produce modified proposal for standard way to include Parameters in the element that has the combining algorithm that uses them, not in the elements enclosed by the element that uses them. ACTION: Michiharu to study whether Polar/Simon's alternative satisfies his use case. If not, publish use case with explanation for why something else is needed. -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692 To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]