[xacml] [xacml model subcommittee] open issues

Hi,

Hope everybody had nice holidays and wish you all a very happy 2002.

In the last concalls it was agreed to keep a list of open issues to be
discussed (expecially in view of the F2F meeting where, hopefully, all
open questions should be solved). As a starting point, below are open
issues we could gather from the discussions in the December concalls.
Anne, thanks for the well done minutes, we have included also the
issues you mentioned. We also took into account Michiharu's document.

talk to you tonight.

best,

- Ernesto & Pierangela

P.S. Ken, could you post it on the web as requested by Carlisle? thx
P.P.S. As agreed in the last concalls tonight's agenda should be the
enrichment and refinement of the open issues list (and their solution
where possible) in view of the F2F.

===========================================================

OPEN ISSUES:

- RULES.
  * authorizations can be either positive (permit) or negative

(deny). There seems to be agreement on the fact that the core

schema should support positive authorizations only. Negative ones

are supported as an extension [Michiharu].
  * post-condition. The current schema [Tim, Jan.3] mentions

post-conditions, distinguishing between external and internal,

depending on whether their execution requires dialoging with

external entities. The current schema suggests (via a comment) that

post-conditions can be expressed as invocations of SOAP

services. Post-conditions are still to be discussed in details:

what is their semantics; how are they executed? A complication of

post-conditions associated with a rule involves the distributed

scenario (see POLICY COMPOSITION issue). In fact, if I say that a

post-condition should be applied whenever a rule fires then I have

to evaluate *all* rules.

- APPLICABLE POLICY.
  * According to the current schema an Applicable Policy seems to refer

to a single Policy.  The discussions in the last concalls seem to

assume that an Applicable Policy can refer to several Policies

(distributed scenario and multiple issuers [Anne]). Is

there agreement on this point? If so, the schema should be

modified accordingly.

  * Target. According to the current schema each applicable policy can

have multiple targets, each of which is an action and a URI

identifying a set of resources (possibly with a transfer function

to support wildcards).  One may want to specify the target with

reference to resource attributes (e.g., this policy applies to all

files older that two years). How can I specify this?

There are pairings <resource,actions> which are not meaningful

(e.g., execute a PDF file) [Simon G.]. Should we control

resource/action bindings in the language or refer to an external

authority?

Also related to target are indexing issues and how to retrieve,

given a request, the applicable policy for it [Tim].

  * The applicable policy is defined as the ``complete'' set of

policies that apply to a resource. How do I ensure completeness

(meaning no two targets should intersect?)

- POLICY COMPOSITION.  Assuming an Applicable Policy can refer to
  several Policy elements, we need to answer the following questions:

  * How are the Policy Element combined? For instance, we could

support boolean expressions of policies. E.g., if there are three

policies by independent issuers, I can say ``P1 AND (P2 OR P3)?

This could fit well in the multiple issuers scenario Anne was

envisioning.

Should this be part of the core of the extension (external URI

[Michiharu])?

  * How should the policy outcome be specified. Possibilities are

2-valued (access decision is ``grant''/''deny'') or 3-valued

(policy outcome is ``grant''/''deny''/nothing). Note the

``nothing'' means that no rule applies, to be solved according to

default.

(related work on composition

- TRIPLET BASE SYNTAX (syntactic sugar). The current schema assumes
  authorizations are specified as a pre-condition which is an
  expression made of predicates on SAML attributes (conditions on
  principal, resource and environment can be interspersed), let's call
  it Option ``pre-cond'' [Carlisle, Tim, Anne, ...]. In the last
  concalls it was agreed to leave as an open issue whether to group
  conditions about principal, resource, and environment in three
  different elements, let's call it Option ``triplet'' [Michiharu,
  Ernesto, Simon, ....].  The argument for Option ``pre-con'' is that
  there are predicates that involve both principal and resource
  attributes (e.g., an authorization that states that users can read
  the files they own). The counter-objection to this is that you can
  naturally include all predicates on resources in the resource
  condition element (which can also refer to principal
  attributes). The argument for the triplet is that it makes
  authorization specifications conceptually clearer and closer to
  current approaches.

- NON-SAML INPUT. In the current schema attributes on resources and
  principals, which can be used in the Target (for resources) and in
  predicates, are retrieved using URIs pointing to SAML dataflow.
  Two issues:
  * Can this mechanism be extended to point to non-SAML authorities as

required in the Java environment [Sehkar]?
  * How do we express wildcards on the resource hierarchies [Simon

G.]?

Note: the current schema includes ResourcetoClassificationTransform

to this purpose. Is this sufficient?

- PREDICATE CANONICALIZATION. Values used in predicates can refer to
  various standard formats (e.g, X.509 [Anne]) that could make the
  predicates evaluation difficult. For instance, if a principal's name
  is expressed in X.500 syntax you cannot compare it against a simple
  string. How do we make the representations canonical?

- ROLES AND GROUP HIERARCHIES. Are roles and groups hierarchies
  available via SAML [Simon G.]? Hierarchies could be needed, in case
  of support of negative rules, for resolving conflicts based on
  more-specific-takes-precedence. Note: policy resolution conflicts
  fit well when the principal is a group, they may be difficult to
  apply in case of principal's expressions.

OTHER HINTS FOR DISCUSSION:

- from the schema it seems that expressions are predicates whose
  arguments are always URI or value.  Are SAML assertions always URI?

ACTIONS:

- Tim's document should be updated as agreed.