[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [xacml] Minutes of 25 March Policy Model teleconference
Minutes of Policy Model Subcommittee Teleconference Meeting
25 March 2002
Scribe: Anne Anderson
Present: Carlisle, Simon, Anne, Ernesto, Tim, Pierangela, Polar,
Michiharu, Don
ACTION ITEM: Polar agreed to attempt to write new resolutions
for issues PM-3-03, PM-3-03A, and PM-2-05.
ACTION: Carlisle and Tim look at the last few items in these
minutes and report whether they participated in the vote.
1. Discussion of OASIS Rights Language Technical Committee
Attendees discussed how the XACML TC should respond to and
coordinate with the new OASIS "Rights Language" TC. Several
XACML participants see potential overlap. Carlisle said he
would talk to Carl Best and others about potential overlap,
and whether we actually need to have two groups. Carlisle
plans to participate in the Rights Language TC in order to
track its efforts and to ensure XACML coordination occurs.
Tim pointed out that one currently has to enter into an
agreement with ContentGuard in order to see their XrML
specification, so it is difficult to assess any potential
overlap. Carlisle will also bring this issue up with Carl
Best.
Simon has viewed the XrML specification and, while not
prepared to give a full review, made the following points: it
is much more specialized than the XACML language, such as
having specialized targets for media. It does support
delegation, but does not support composition of policies from
different sources.
2. Polar: should we use "combiner" or "combinator"? Decision was
to postpone such issues until we are ready to make final
revisions to the specification.
3. VOTED TO CLOSE: ISSUE: PM-1-01-A: Implementing global deny and
Meta-Policies
Resolution: the syntax for <rule> allows for the <rule> to
return an <effect> of "permit" or "deny". It is up to the
combiner in the <policyStatement> that uses a <rule> to
determine the effect of a <rule> that returns "deny".
Likewise, it is up to the combiner in the
<policyCombinationStatement> that uses a <policyStatement> to
determine the effect of a <policyStatement> that returns
"deny".
The following example combiners can be used to implement
"global deny" semantics for a <rule>. Since an "indeterminate"
rule might have evaluated to "deny" if sufficient information
had been supplied, these examples treat "indeterminate" results
the same way as "deny" results.
GLOBAL DENY RULE COMBINER:
boolean atLeastOnePermit = false;
for <rule> in <ruleSet> {
effect = eval(<rule>);
if (effect == "deny" || effect == "indeterminate") {
return "deny";
} else if (effect == "permit") {
atLeastOnePermit = true;
}
}
if (atLeastOnePermit) {
return "permit";
} else {
return "not applicable";
}
GLOBAL DENY POLICY COMBINER:
boolean atLeastOnePermit = false;
for <policy> in <policySet> {
effect = eval(<policy>);
if (effect == "deny" || effect == "indeterminate") {
return "deny";
} else if (effect == "permit") {
atLeastOnePermit = true;
}
}
if (atLeastOnePermit) {
return "permit";
} else {
return "not applicable";
}
Policy and policy combination writers who do not wish to
support "global deny" semantics can specify different
combiners.
Policy combination writers should publish the combiner they use
to policy writers so that consistent semantics are maintained:
if a policy combination writer is implementing "global deny",
then the policy writers should be aware that returning an
effect of "deny" will by itself result in denial of access.
4. VOTED TO CLOSE: ISSUE PM-1-05: how NOT-APPLICABLE impacts a
combinator expression
Resolution: A <rule> will return NOT-APPLICABLE under the
following conditions:
<rule> Truth Table:
Target Condition Effect
------ --------- ------------
match match [Effect]
match no-match Inapplicable
match Indet. Indet.
no-match match Inapplicable
no-match no-match Inapplicable
no-match Indet. Inapplicable
It is up to the combiner in the <policyStatement> that uses a
<rule> to determine the effect of a <rule> that returns
"Inapplicable". Likewise, it is up to the combiner in the
<policyCombinationStatement> that uses a <policyStatement> to
determine the effect of a <policyStatement> that returns
"Inapplicable".
The example "GLOBAL DENY" combiners proposed in PM-1-01A can be
used to implement "remove inapplicable elements from the
computation" semantics.
The following example combiners can be used to implement
"inapplicable same as deny" semantics. Such semantics might be
desired where all rules are intended to be applicable, so a
result of inapplicable indicates some breakdown in the
consistency of the system.
INAPPLICABLE GLOBAL DENY RULE COMBINER:
if (<ruleSet> == null) {
return "deny";
}
for <rule> in <ruleSet> {
effect = eval(<rule>);
if (effect == "deny" ||
effect == "indeterminate" ||
effect == "inapplicable") {
return "deny";
}
return "permit";
INAPPLICABLE GLOBAL DENY POLICY COMBINER:
if (<policySet> == null) {
return "deny"
}
for <policy> in <policySet> {
effect = eval(<policy>);
if (effect == "deny" ||
effect == "indeterminate" ||
effect == "inapplicable") {
return "deny";
}
return "permit";
5. VOTED TO CLOSE: ISSUE PM-1-07: how can the set of combinators
be extended?
Resolution: the combiner algorithm to be used by a given
<policyStatement> or <policyCombinationStatement> is specified
using a URI.
XACML will specify a small set of mandatory-to-implement
combiner algorithms. Users are free to define other
algorithms, although not all XACML-compliant PDPs will be able
to apply them. The algorithm associated with a combiner URI
MAY be descriptive text or a formal language or pseudo-code.
6. VOTED TO CLOSE: ISSUE PM-2-01: Referencing Multiple Policies
Resolution: Multiple policies may be referenced and combined
using a <policyCombinationStatement>. This has the following
syntax:
<policyCombinationStatement>
<target/>
<policySet Combiner="myURI">
<policyDesignator>
<policyRef> or <policyStatement> or
<policyCombinationRef> or <policyCombinationStatement> or
<saml:assertion>
<policyMetadata>
</policyDesignator>
<policyDesignator>...</policyDesignator>
<obligations /> OPTIONAL
</policySet>
</policyCombinationStatement>
The <policyDesignator> element specifies a policy to include,
using one of various ways of referring to a policy. There can
be multiple <policyDesignator> elements in a
<policyCombinationStatement>. The "combiner" specifies how the
various policies are to be combined to produce a result.
7. ISSUES PM-3-03, PM-3-03A, PM-2-05: There was not agreement on
what a "base policy" is, or on whether a PDP has one, or on
whether a PDP (or some other entity) must "publish" a PDP's
base policy. One camp says every PDP must have a way of
deciding which policies and rules it will evaluate in response
to a given authorization decision request, and the "base
policy" states how the PDP makes that decision. The other
camp says that a PDP may be dealing with millions of dynamic
policies and rules, and there can not be a single "base
policy" to deal with all of them.
We did agree that a PDP must have an unambiguous way to decide
which policies may be combined to produce a result.
Possible new issue: adding syntax to ruleSet and policySet to
specify that rules, policyStatements,
policyCombinationStatements are to be retrieved dynamically
based on the authorization decision request contents.
ACTION ITEM: Polar agreed to attempt to write new resolutions
for issues PM-3-03, PM-3-03A, and PM-2-05.
8. VOTED TO CLOSE: ISSUE: PM-1-01: Negative Authorizations
Resolution: XACML allows policy writers to specify positive
(permit) or negative (deny) authorizations. A negative
authorization is specified using the effect element with "deny"
in the rule, and a rule set combiner in the corresponding
policy such as "meta-policy-1", meaning the global-deny
semantics. Using the rule combiner (XACML extension point), the
semantics of the negative authorization varies depending on the
user-defined rule combiner. PM-1-01-A discusses the global-deny
semantics.
9. VOTED TO CLOSE: ISSUE: PM-1-02: Post-Conditions
[NOTE: we need to re-vote on this, since discussion associated
with later issues affects some of this resolution. I have
submitted a revised resolution. -aha]
Resolution: We use the term "obligation" to mean what we have
previously been calling "post condition". The issue of the term
is addressed in PM-1-03.
The obligation is an annotation that MAY be specified in a
policyStatement and/or policyCombinationStatement that should
be returned in conjunction with an authorization decision
meaning that the obligations(s) SHOULD be executed by the
PEP. The obligation is specified using URI reference with
optional arguments. The processing rules of the obligation is
defined by ruleSet combiner or policySet combiner. XACML
provides a couple of combiner examples that deals with
obligations in the informative section. The actual meaning of
each obligation differs from application. It also depends on
the configuration of the PEP and/or PDP. If the PEP does not
understand an obligation, the PEP should deny access. The PDP
just collects obligations.
(from F2F#4 minutes) The set of obligations returned by each
level of evaluation includes only those obligations associated
with the effect element being returned by the given level of
evaluation. For example, a policy set 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.
10. VOTED TO CLOSE: ISSUE: PM-1-03: Post-Conditions as a term
Resolution: At the March, 2002 Face-to-Face meeting, we agreed
to use the term "obligation" to express an annotation
associated with an access decision that is returned to a PEP.
This term replaces our former use of "post-condition".
11. VOTED TO CLOSE: ISSUE: PM-2-03: Meaningful Actions
Resolution: The XACML syntax shall not address the question of
quich actions are valid for a particular resource
classification.
12. VOTED TO CLOSE: ISSUE: PM-2-08: Outcome of policies and their
combination
Resolution: the combiner algorithm to be used by a given
<policyStatement> or <policyCombinationStatement> is specified
using a URI. The algorithm associated with the URI MAY be
descriptive text.
XACML will specify a small set of mandatory-to-implement
combiner algorithms. Users are free to define other
algorithms, although not all XACML-compliant PDPs will be able
to apply them.
The combiner algorithm specifies how the associated <ruleSet>
or <policySet> is combined, and what the outcome will be.
13. VOTED TO CLOSE: ISSUE: PM-3-01: Combining Policy Elements
Resolution: PolicyCombinationStatement allows policy writers to
specify arbitrary algorithm to combine one or more
PolicyStatement and/or one or more
PolicyCombinationStatement. A policySetCombiner attribute in
the PolicyCombinationStatement is used to identify the
combination algorithm. PolicyMetaData MAY be used to combine
policies.
14. VOTED TO CLOSE: ISSUE: PM-4-10: preserve PAP identity
Resolution: a <policyStatement> or <policyCombinationStatement>
may be referenced as a saml assertion. In this case, the PAP
identity, signature (if present), and other information is
available to the associated combiner algorithm. Otherwise, the
PAP identity is not preserved, and is not available to the
associated combiner algorithm.
15. VOTED TO CLOSE: ISSUE: PM-5-11: should we use a SAML
assertion as a container for an XACML applicable policy.
Resolution: a SAML assertion MAY be used as a container for an
XACML <policyStatement> or <policyCombinationStatement>. The
policy combiner MAY ignore the container elements, or MAY
reference them in making its decision.
16. VOTED TO CLOSE: ISSUE: PM-5-17: Boolean Expression of rules
Resolution: The <condition> element in a <rule> can be a
boolean expression of predicates. <rule>s are combined in a
<policyStatement> using a "combiner" algorithm, which specifies
how the results of the <rule>s are combined. Likewise,
<policyStatement>s and other <policyCombinationStatment>s are
combined in a <policyCombinationStatement> using a "combiner"
algorithm, which specifies how the results of the
<policyStatement>s and <policyCombinationStatement>s are
combined. Some combiner algorithms may be expressed using
boolean expressions, but other combiner algorithms will use
other logic. A combiner algorithm MAY be expressed using
descriptive text rather than a formal language or pseudo-code.
17. VOTED TO CLOSE: ISSUE: PM-8-01: Internal v.s. External post
conditions
Resolution: XACML does not specify which entity is responsible
for fulfilling an obligation. If the PDP is not the
responsible entity, it is not responsible for ensuring that the
obligation is fulfilled.
18. VOTED TO CLOSE: ISSUE: PM-8-02: Mandatory v.s. advisory post
conditions
Resolution: XACML does not specify whether obligations are
mandatory or advisory.
19. VOTED TO CLOSE: ISSUE: PM-8-03: Inapplicable
Resolution: No obligations are returned to the PEP when the
authorization decision is determined as inapplicable or
indeterminate.
20. VOTED TO CLOSE: ISSUE: PM-8-04: Base policy v.s. policy
reference
Resolution: Obligations may be specified in both
policyStatements and policyCombinationStatements. The scope of
the obligation is defined in ISSUE: PM-1-02 as "The set of
obligations returned by each level of evaluation includes only
those obligations associated with the effect element being
returned by the given level of evaluation. For example, a
policy set 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."
It is up to the combiner to decide which elements to evaluate.
Only those obligations resulting from evaluated elements are
returned to the next higher level of evaluation.
21. ISSUE: PM-8-05: How to return post-condition via SAML. Tim
had not had a chance to read and respond to Michiharu's most
recent e-mail on this subject. We decided to postpone a vote.
22. VOTED TO CLOSE: ISSUE: PM-8-06: When to execute post
condition
Resolution: When and how PEP executes obligation depends on
each application. XACML (as PDP) does not assume any specific
semantics. While obligation implies that specified operation
must be dealt with prior to the requested access, it does not
necessarily mean that the specified operations must be executed
synchronously. Taking the obligatory operation usage scenario
like "customers can register themselves with their private
information provided that such information is deleted in 90
days--- obligation is delete-in-90days", it is impossible to
execute "delete-in-90days" obligation prior to the requested
access. It would be reasonable if such operation is queued in
the application and guaranteed to be executed later.
23. VOTED TO CLOSE: ISSUE: PM-8-07: Extension point (line 1315 is
typo, the issue number should be PM-8-07)
Resolution: Extension point of obligation is 1. obligationId in
policyStatement or policyCombinationStatement and 2. ruleSet
combiner or policySet combiner. This allows policy writers to
specify arbitrary identifier of the user-defined obligation and
to specify the semantics of how obligation is computed in
response to the access request.
24. There was discussion about "internal" obligations intended
for execution by the PDP or by an entity associated with the
PAP that issued a given policyStatement or
policyCombinationStatement. Pierangela suggested that such
"internal" obligations should not be passed up to the next
higher level of evaluation. Michiharu suggested that an
argument to the obligation could specify which entity should
fulfill and obligation. Anne pointed out that obligations must
be passed up because some of them may be dropped if the effect
produced by a higher level of evaluation does not match the
effect produced by the policy that resulted in the "internal"
obligation. Ernesto pointed out that our current method of
handling obligations does not allow them to be used for
debugging which rules were evaluated in reaching a decision;
there was general agreement that this was OK - debugging can
(and probably should) be handled by other mechanisms.
25. VOTED TO CLOSE: ISSUE: MI-1-01: Consistency
Resolution: Any glossary concerns should be resolved as part of
the resolution for the particular issue in the PM group.
26. VOTED TO CLOSE: ISSUE: MI-1-02: Definition of Policy vs. Rule
Resolution: A "rule" is the smallest unit from which a "policy"
is composed. A "rule" uses predicates that refer to attributes
and values.
A "policy" is a combination of rules or other policies. A
combination of rules is called a <policyStatement>. A
combination of <policyStatement>s or other
<policyCombinationStatement>s is called a
<policyCombinationStatement>. A policy is the smallest
administrative unit in XACML, and is the smallest unit that can
be signed. A policy does not refer to attributes and values,
but only to combinations of rules or other policies.
27. ISSUE: MI-1-03. We realized that Carlisle and Tim were no
longer on the call, so we no longer had a quorum. We need to
find out what was the last item on which they were present for
a vote, since one or more previous items may not have actually
had a quorum present.
ACTION ITEM: Carlisle and Tim look at the last few items in
these minutes and report whether they participated in the
vote.
28. Polar suggested we shift to making all issues and resolutions
based on the specification itself and how it should be
reworded. He will raise this issue on the mailing list.
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC