xacml — archive

[System]

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.