[xacml] [xacml model subcommittee] open issues

[Pierangela Samarati <samarati@pinky.crema.unimi.it>]

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.