XACML Face to Face #4

Date: March 11/12, 2002

Location: Burlington, MA (SUN)

Minutes of Meeting

(Minutes taken by Anne Anderson, Edited by Ken Yagen)

Contents

Votes
Proposed Agenda
Roll Call
Action Items
Summary
Agreements Reached
Deferred Issues And Questions
Detailed Notes

Votes

Proposed Agenda:

Monday, March 11th

9:00 a.m. - 5:00 p.m. (or later):

- aside from roll call, etc., for the first 10 minutes or so, we take as much of the day as necessary to come to consensus on the definition and high-level contents of

RULE,

("basic" or "elementary") POLICY,

("compound" or "higher-level") POLICY, and

META-POLICY

- breaks: roughly 10:30-10:45; 12:00-1:00; 3:00-3:30

- be prepared to camp out in the Sun conference room if necessary. I would really like these basic definitions to be closed before we adjourn on Monday.

Tuesday, March 12th

9:00-10:30: Post-conditions / Obligations discussion (led by Michiharu)

10:30-10:45: BREAK

10:45-11:15: Post-conditions / Obligations discussion

11:15-12:00: Arithmetic Operators discussion (led by Ernesto or Tim)

12:00-1:00: LUNCH

1:00-2:00: Extensibility discussion (led by Simon)

2:00-3:00: Use Case discussion (Michiharu on protecting XML resources; Sekhar or Simon on J2SE; any others?)

3:00-3:30: BREAK

3:30-5:00: Resolve as many remaining issues from the Issues List as practical

5:00: Adjourn

Roll Call

Voting Members

Simon Godik, Self

Hal Lockhart, Entegrity

Carlisle Adams, Entrust

Tim Moses, Entrust

Don Flinn, Hitachi

Michiharu Kudoh, IBM

Bill Parducci, Self

Polar Humenn, Self

Sekhar Vajjhala, Sun Microsystems

Anne Anderson, Sun Microsystems

By Phone

Pierangela Samarati, Univ. of Milan

Probationary Members

Konstantin Beznosov, Hitachi

ACTION ITEMS:

[Tim] Update specification to Version 11, incorporating decisions from this meeting.

[Tim, Michiharu] Propose specific set of mathematical operators and associated syntax appropriate for XACML requirements. Present at the subcommittee meeting on March 25, 2002.

[Hal, Konstantin] Provide more verbal text describing function and use of the various element types. To be done after Tim provides Version 11. The verbal text might be a type of "primer" on XACML; something to introduce XML neophytes to the way the language is intended to be used.

[Carlisle] Determine availability of sites and dates for next face-to-face meeting. Date preference order: week of April 15, week of April 22, week of April 29. Location preference order:

Univ. of Milan (Ernesto,Pierangela)
SF Bay area (Ken)
Manhattan Beach (Bill)
Burlington (Anne, Sekhar).

Constraints: Michiharu not available week of April 29. Sekhar has problems with weeks of April 15 or April 22.

[All] Determine acceptability of Univ. of Milan as a site for the next face-to-face meeting.

SUMMARY:

We resolved most issues related to the overall policy model. The following chart lists overall areas that are still OPEN, those on which we are in AGREEMENT, and those where we have done some work, but need more work (?). Most of the OPEN areas have to do with details of the XML syntax rather than the policy model itself.

Operators	Boolean	? [1]
	Math	OPEN
Predicates	Predefined	? [2]
	Definition	OPEN
Values	Boolean	? [1]
	Math	OPEN
	SAML:attribute	OPEN
Expression	Boolean	? [1]
	Math	OPEN
Condition		? [1]
Obligation		AGREEMENT
Obligation arguments		OPEN
rule	ref	AGREEMENT
	statement	AGREEMENT
ruleCombiner		OPEN
ruleSet		AGREEMENT
policy	ref	AGREEMENT
	statement	AGREEMENT
	saml:assertion	AGREEMENT
policySetCombination		OPEN
policySet		AGREEMENT
policyCombination	ref	AGREEMENT
	statement	AGREEMENT
	saml:assertion	AGREEMENT

[1] We have not written out and agreed upon Boolean expressions, but we expect we are in agreement modulo nits.

[2] We have discussed some predicates that would be predefined, but there is more closure required on this.

AGREEMENTS REACHED:

Three major elements from which a policy is constructed:

1. low level <rule>s,

2. <policyStatement>s that combine rules, and

3. <policyCombinationStatement>s that combine policies.

<rule>

</target>

[arbitrary boolean predicate over subject, action, resource]

</condition>

<effect>..</effect> [CHOICE: Permit or Deny]

<obligations> [OPTIONAL]

...

</obligations>

</rule>

<target> allows efficient indexing. <target> MUST contain only references that will always be available in the SAML request because the <target> MUST NOT return an "indeterminate" result.

Another reason for requiring <target> references to be readily available is to support the use of <target> for efficiently eliminating clearly inapplicable <rule>s without requiring

extensive evaluation.

A <rule> can produce one of three possible results: grant/deny, inapplicable, indeterminate. The same <rule> will never return "grant" from some <authorizationDecisionRequests> and "deny" from others: a <rule> has a single associated <effect> and either returns that one effect or inapplicable or indeterminate.

The <condition> element participates equally with the <target> element in determining the applicability of the <rule>. <target> is the easily-computed first stage, and <condition> is the arbitrarily complex second stage.

<rule> Truth Table:

Target	Condition	Effect
-------	------------	--------------
T	T	[Effect]
T	F	Inapplicable
T	Indet.	Indet.
F	T	Inapplicable
F	F	Inapplicable
F	Indet.	Inapplicable

Scope of <rule> does not go beyond the <policyStatement> that references it.

Policy is smallest unit that can be signed. Rules can stand by themselves, but can't be signed. Policy can include a hash of the actual syntax content of a <rule>. In this case, the policy writer wants this particular <rule> content. If no hash, then then policy writer wants current rule associated with this <ruleId>. Example: a <ruleId> may be associated with the semantic "conditions under which someone is allowed to access Anne's files". Anne may change the specific conditions over time, but might retain the same <ruleId> so that the current rule can be referenced in a policy without having to rewrite the

policy.

<policyStatement> extends saml assertion:

</target>

</ruleDesignator>

</onPermit>

</onDeny>

</obligations>

</ruleSet>

</policyStatement>

<policyStatement> Evaluation Table:

Target RuleSet Result

------ ------- --------

match [effect] [effect]

match Inappl. Inappl.

match Indet. Indet.

no-match Inappl.

<ruleReference uri="http://..."

authority="..."

hash="..." [OPTIONAL: only if ruleId content must be fixed]

</ruleReference>

A <ruleSet> is a set of <rule>s along with a way to combine the rules. A <ruleSet>s "combiner" is a URI associated with a description of the algorithm for producing a result from the given set of rules. The "combiner" MAY be a textual description.

Examples of possible <rule> combiners:

o If any <rule> evaluation returns "inapplicable", "deny", or "indeterminate", return "deny". Otherwise, return "permit".

o If any <rule> evaluation returns "deny" or "indeterminate", return "deny". Otherwise, if at least one <rule> evaluation returns "permit", return "permit". Otherwise, return "inapplicable".

o Return effect of the rule whose <target> "most closely matches" the request (for some definition of "most closely matches").

o Return effect of first rule from list that returns "permit" or "deny".

</target>

<policyRef> or <policyStatement> or

<policyCombinationRef> or <policyCombinationStatement> or

<saml:assertion>

</policyDesignator>

<obligations> OPTIONAL

</onPermit>

</onDeny>

</obligations>

</policySet>

</policyCombinationStatement>

The <policyCombinationStatement> "combiner" is a URI associated with a description of the algorithm for producing a result from the given list of policies. The "combiner" MAY be a textual description.

If you want to select policies based on data other than <target> and <ruleSet>, then you have to embed policyStatement in SAML assertion. Then the "combiner" can select on things like the issuer of the policy, whether policy is signed, etc.

We may decide for simplicity to remove some choice options from <policyCombinationStatement> in Version 1.0, but we are going to leave it all in for now and flesh it out.

We will use the term "obligation" to mean what we have previously been calling "post condition".

An Obligation is specified via URI and optional value attribute.

</target>

<operation uri="http://www.xyz.com/obligation/log"

value="abc" />

</onPermit>

</obligation>

</policyStatement>

The set of <obligations> returned by each level of evaluation includes only those <obligations> associated with the <effect> being returned by the given level of evaluation. For example, a <policySet> may include some policies that return Permit and

other policies that return Deny for a given request evaluation. If the policy combiner returns a result of Permit, then only those obligations associated with the policies that returned Permit are returned to the next higher level of evaluation. [If

the PDP's evaluation is viewed as a tree of policyCombinationStatements, policyStatements, and rules, each of which returns "Permit" or "Deny", then the set of <obligations> returned by the PDP will include only the obligations associated paths where the effect at each level of evaluation is the same as the effect being returned by the PDP.]

If the PEP does not understand an obligation, it should deny access. The PDP just collects obligations.

policyStatement and policyCombinationStatement allow determinism:

their "combiner"s can control order or completeness of evaluation. If determinism is desired at the expense of performance, then the combiner algorithms can force evaluation of all rules and policies.

XACML will not define "profiles" for specific application domains such as J2SE. XACML will try to anticipate issues that may arise in using XACML within various domains, and may give examples of how those issues can be resolved using XACML.

DEFERRED ISSUES AND QUESTIONS:

This is a list of issues and topics that came up, but that we deferred. Some of these may have been effectively closed, but I am erring on the side of caution in listing possible open issues here.

[Sekhar]PDP-oriented versus Policy Writer oriented? Wants to keep all rules from one policy writer as a discrete collection. What do you call this thing?

Exchanging <rule>s: is this valid XACML?

[Carlisle]Does PRP/PDP have a base policy? Does PDP publish its base policy?

[Anne/Sekhar]See a need to allow a PEP to provide a Base policy to the PDP as part of or in conjunction with the authorizationDecisionQuery.

[Tim]Special case for hierarchical subjects and resources to make merging targets simpler. Or is higher-level target just the union of lower level targets? Anne: but doesn't this only apply when the meta-policy uses "closest match"?

[Anne]Is higher-level target derived or declared? If derived, by whom? On what trigger? At time a new <rule> or <policyStatement> is added to a list?

Which <rule> combiners will we spell out?

[Carlisle]Extensibility points. Is <rule><effect> extensible?

If additional values, then have to define a new <rule> combiner that references them?

[Simon] syntax for referring to resource in SAML authorizationDecisionQuery. This is a SAML and XACML syntax issue: they have to be coordinated.

How do we know whether an attribute is of subject, resource, etc.?

How is obligation returned to PEP? SAML changes required.

[Hal] Is a SAML response that has advices and conditions the right way to return obligations.

[Konstantin] can same PDP, with different extension profiles, handle J2EE, J2SE, .NET, etc.?

[Anne] Does Predicate in referencing an attribute need the attribute authority name, authority key, ClassName, class base location?

[Hal] Need to have way to restrict XACML to subsets so that a given PDP/PRP can handle. E.g. PDP might be "J2SE-compliant".

E.g. [blue sky] limit on numbers of rules, only certain combiners supported, limits on # of levels of policyCombiners, only certain ways to reference a policy inside a policyCombinationStatement, only those things required to support J2SE. Spell out to a PAP how it is limited to apply to a given PDP. PDP spells out what it can support.

[Konstatin] wants more verbal text around element types. Have UML as well as XML. Purpose is to sell ideas behind XACML to someone who does not understand XML.

Are obligations mandatory to implement for XACML compliance?

DETAILED NOTES:

These are my sequential notes. I have made some of the terminology a bit more consistent with our final agreements, but in general, information is presented here as it evolved. Syntax often represents intermediate discussion proposals, and should not be confused with the AGREEMENTS REACHED above.

Agenda:

Monday, March 11

9:00 a.m. - 5:00 p.m. (or later):

- aside from roll call, etc., for the first 10 minutes or so, we take as much of the day as necessary to come to consensus on the definition and high-level contents of

RULE,

("basic" or "elementary") POLICY,

("compound" or "higher-level") POLICY, and

META-POLICY

- breaks: roughly 10:30-10:45; 12:00-1:00; 3:00-3:30

- be prepared to camp out in the Sun conference room if

necessary. I would really like these basic definitions to

be closed before we adjourn on Monday.

Tuesday, March 12th

9:00-10:30: Post-conditions / Obligations discussion (led by Michiharu)

10:30-10:45: BREAK

10:45-11:15: Post-conditions / Obligations discussion

11:15-12:00: Arithmetic Operators discussion (led by Ernesto or Tim)

12:00-1:00: LUNCH

1:00-2:00: Extensibility discussion (led by Simon)

2:00-3:00: Use Case discussion (Michiharu on protecting XML resources; Sekhar or Simon on J2SE; any others?)

3:00-3:30: BREAK

3:30-5:00: Resolve as many remaining issues from the Issues List as practical

5:00: Adjourn

March 11, 2002

Agenda:

o Resolve Rule, Policy, MetaPolicy

RULE/POLICY/METAPOLICY

Simon: Presented following model:

r1: g+(view, /dir1/file1.html, user1) if a>b and c>d.

r2: g+(view, /dir1/file*, user1) if c>d.

r3: r(view, /dir1/file1.html, user1) if e>f

Request: g(view, /dir1/file1.html, user1)

Can say have to solve restriction first, then positive rules. Answer to request will be yes/no.

Now say don't care about restrictions first, just match in order. Will arrive at a yes/no.

Now if have separate policies administered by different authorities. Each can answer yes/no. Need way to combine:

solve P[A](P,R,A), P[B](P,R,A)

Need another meta-policy: P[A] OR P[B]

P[A] AND P[B]

Metapolicies for rules and policies are different.

Can match query against rule and see which one applies. Simon suggests taking two rules, grouping into the policy, but don't try to make one rule out of the two.

Sekhar: "policy" versus "rule"

Now PDP-oriented. ebXML has Registry Client, Registry Server. Client wants to impose conditions on server access for business partners. So client writes XACML policy. Policy is submitted as part of the content. Policy contains rule statements of some sort: resources to be protected, rule for each resource.

What do you call the thing where set of rules is submitted by a policy writer.

Wants to keep all rules from one policy writer as a discrete collection. Wants to be able to send this collection as part of a SOAP request. Simon: Target is union of all targets in

rules.

Carlisle: PDP only evaluates policies, which are fully worked out rule statements or policy combination statements. It doesn't make any sense to assign an effect to a rule unless you have a meta-policy. Policy writer can override the meta-policy. At

rule level, effect is a hint.

Pierangela: Is meta-policy associated with policies or with rules?

Simon: same two rules may be used in different ways in two different policies. Carlisle says this is same as no effect on the rule: the policy writer who includes the rules will determine the effect in this case.

Don: might want to include effect in the metapolicy without implying use of a specific metapolicy.

Polar: even policy writer does not know how his policy will be combined administratively. Effect determines how evaluation gets mapped to the higher logic.

Hal: thinks <effect> is a hack. It is when you have loosely coupled policy administrators that you really need metapolicy. Each needs to see how his piece fits into the whole world only enough to do his job.

Konstantin: only one person writes rules for one policy.

[Tim Moses came in here]

Anne: two models: database of rules that are sorted into a logical statement according to a metapolicy; high-level policy that refers to specific rules or sub-policies.

Why have metapolicy ref in rule?

Don: have we removed requirement for not wanting to have to retrieve all rules. [NO]

Simon: proposes only policy writers, no rule writers.

Hal: proposal "rule is atomic unit of administration". Policy is combination of policies or rules.

Simon: merge vs. combine. disagrees because no semantics. Two cases: two policies from different sources to be combined (="policy combination"); take two policies, super-administrator will merge the two policies. Super-administrator can choose to combine vs. to merge. Rule=authorization to perform an action on a resource. One target, one effect. Polar says merge vs combine must be equivalent by Church-Rosser property.

Hal: still need finer grained targetting.

Assume for now that targets are defined: may be complex, may be simple.

Curently, metaPolicyRefs always point up: from rule or from policy. ruleCombiners and policyCombiners now point down.

<rule>

</target>

P(S,A,R, ...)

</condition>

<effect>..</effect> Permit, Deny

</rule>

<target> optional. For finding applicable policies when have multiple ones either in database or when will need to combine.

</target>

</policy>

Given a particular request, PDP only acts on a policy that has all applicability elements resolved. Rule-combination policy already applied or not?

Exchanging rules: is this valid XACML? Role of targets in the policy. PRP returns one completely applicable policy to PDP. PRP needs a base policy that applies to everything. It returns a metaPolicyRef and set of rules.

Is XACML for policy writers (PAPs) or for PDP?

[LUNCH BREAK]

Meta-policy now associated with policy, not rule. Meta-policy points down, not up now. Meta-policy1 is a rule-combiner. Metapolicy2 is a real metapolicy (combining policies).

Pierangela gives 5 min. How do you combine boolean policy with metapolicy. Carlisle: you don't. You deal with one or the other.

Pierangela: if multiple levels of composition, is one level the root?

Polar: role of PRP and how many levels of metapolicy? Have to guarantee top level returns only one, or else have to have a way to combine them.

Carlisle: suggestion that PDP publishes its base policy. Anne: case where PEP provides the base policy.

Simon: PDP should know which resources it is intended to protect. Hal: PRP sits in front of huge database of policies and returns the applicable ones to the PDP.

Hal,Sekhar: policy is what policy writer writes. Applicable policy is the set of policies that apply to a given request.

Set of applicable policies will be determined depending on matching the request against the target, and will be retrieved by the PRP.

Tim: special case for hierarchical subjects, resources. Makes combining policies much simpler. Anne: but doesn't this only apply when the meta-policy uses "closest match"?

Proposal: Policy target is derived from the targets in the rules. Alternative is that policy target is Declarative, specified by policy writer as "intended target". Consequences:

Derived:

- complex calculation

- updated whenever a rule is added to database?

- simplify target to make this feasible

- derived subject is difficulty

Declarative:

- declare intention of use

- target is broader than true applicability

- lower policies and rules may not be consistent with each

other.

- can have rules that never fire.

- Could write tools to analyze consistency.

PDP looks at target in its directly referenced policies, and selects based on that.

Note: target specification must enter in to the logic. It is the first hurdle. There may be more in the <condition>.

Pierangela: deriving targets much harder if conditions are included in applicability. Tim suggests conditions are handled in the policy that includes the rules:

<or>

<and>

<T1>

</equals>

<C1>

</and>

...

</or>

Polar:

<rule>

</target>

</rule>

</target>

<rule1>

<rule2>

</policy>

same

</policyLevel2>

Rule produces three results: grant, deny, inapplicable.

Conditions are always applicable from the rule writer's point of view.

Polar: OwnerOf(R,S) -> [R is "old", Permit]

target cond effect

<resourceName>=Age is "old"

<subject> any

</target>

OwnerOf(R,S)

</condition>

<effect>Permit</effect>

</policy>

If <condition> is false, then return <not applicable>. By metaPolicyOne, this will result in <deny>?

Need different rule-combiner from the "MetaPolicy One" to get the intended semantics.

Pierangela: Need way to indicate that someone gets permit without implying that everyone else gets deny.

semantics:

condition

target T F

T effect inapp

F inapp inapp

Polar: then rule and policy same. Move these semantics up to higher level.

Michiharu: specific use cases. Simple example does not use <condition>. More complex example uses conditions and meta-policy-hierarchy. His example also implies complexity in the <target>, at least at the level of using subject role (attribute), but Michiharu says that can be moved out to <condition> in newer proposal.

Polar: so scope of rules does not go beyond the policy. Michiharu's <ruleSet> is equivalent to rule-combiner policy level.

Pierangela: what if not all information available? Answer: indeterminate. Error condition. Rule-combiner handles this case. Rule combiner can specify algorithm in plain English referenced via a URI.

Now don't need permitOnlyIf because now have Deny and way for <rule> combiner to give "permitOnlyIf" semantics to <not>Deny if that is what is desired.

Issues:

- Do we need more than one RuleCombiner

- Syntax for specifying RuleCombiner (URI; can be English text)

- Effect extensible or just Permit/Deny?

Resolution: if additional values, then have to define a new RuleCombiner that references them.

<rule> = v10 minus metapolicyref; effect={permit,deny}; target and condition equally participate in applicability. Effect returned only if both are true.

<rule> Truth Table:

Target Condition Effect

------ --------- ------------

T T [Effect]

T F Inapplicable

T Indet. Indet.

F T Inapplicable

F F Inapplicable

F Indet. Inapplicable

[AFTERNOON BREAK]

POLICY: generated and manipulated by one person in one place.

</policy>

Fits into data model in case where you want to write a policy down. Could pass policy back to a PDP, in which case the target is then superfluous.

<rule>...</rule> Can contain rule syntax or ruleId.

</ruleSet>

Need for ruleSet depends on whether ruleCombiner is associated with ruleSet or whether ruleSet is re-usable with other rules.

Signature on policy <rule>: can also include hash of <rule>, or just (hash of?) <RuleId>. If hash of <rule> syntax, then policy writer wants this particular <rule> content. If just (hash of?) <ruleId>, then policy writer wants current rule associated with this ruleId. Example: a <ruleId> may be associated with semantic "conditions under which someone is allowed to access Anne's files". Anne may change the specific conditions over time, but might retain the same <ruleId> so that the current rule can be referenced in a policy without having to rewrite the policy.

<ruleRef uri="http://..."

authority="..."

hash="..." (optional)

</ruleRef>

Policy is smallest unit that can be signed. Rules can stand by themselves, but can't be signed.

v10 has <rules>. Take metaPolicyRef (ruleCombiner) out of <policy> and put into <rules> and then <rules> is like new <ruleSet>.

Policy extends saml assertion:

<rule> [ruleId (attribute of rule element)

or rule syntax] </rule>

...

</policyStatement>

Target RuleSet Result

------ ------- --------

match [effect] [effect]

match Inappl. Inappl.

match Indet. Indet.

no-match Inappl.

Carlisle: is policyStatement always wrapped in a SAML assertion. If you want to select policies based on data other than <target> and <ruleSet>, then you have to embed policyStatement in SAML assertion.

Michiharu: what if you want to assign priorities to rules.

Proposal: evaluate in sequence order. Define new ruleCombiner that understands priority attribute in rules.

Now:

<ruleX>

<rule>

</rule>

<ruleMetaData

name="..." value="..." />

<effect> CHOICE

Permit or Deny

</effect>

</ruleX>

RuleCombiner can operate on ruleMetaData, which might include something like priority.

</target>

<saml:assertion>

</saml:assertion>

</choice>

</policyDesignator>

</policyCombinationStatement>

Version1: only use <policyStatement> and <ruleStatement>?

Alternative: flesh out, but then remove in a month if we don't like it.

Consensus: we need to be able to combine policies.

Version1: only use <policyRef> or <policyCombinationRef>?

Consensus: leave it all in for now.

xacml message

XACML Face to Face #4

Votes