RE: [xacml] XACML 3.0 Public review 04

I don’t really understand either of these proposals, I will comments on each below. As a meta comment, given the current state of XACML 3.0 Core I suspect the TC will be reluctant to make changes which alter the basic syntax or semantics of the language at this time. Changes which can be added on in the form of a separate profile, even specifying additional behavior (as for example is done in the Admin Profile) seem much more appropriate for now.

My comments on part 2 are shorter so I will cover them first.

I simply do not understand what you are trying to accomplish here. In particular, I am baffled by this:

“There are cases where it is desirable to resolve the value at the time of authorization, in a late-bound manner: in these cases, the rule specifies that the actual value of a given attribute needs to be resolved, given an attribute identifier, much in the same way attribute designators currently work.”

All attributes, whether indicated by a designator or a selector are supposed to be the current value at the time of the decision. They may be provided by the PEP as a part of the request or obtained from other authoritative sources. I think you have miss interpreted the specification.

Perhaps the issue is, as Erik has suggested your use of Target vs. Condition. Target only accepts limited arguments, whereas Condition permits completely generalized operations on any number of attribute values obtained dynamically at decision time.

Your response to Erik suggests that what you are proposing is not a change to XACML itself, but a way of communicating policy templates which could be further processed into XACML policies. I have been talking about policy templates for years, but I see them as solving a much more generalized set of problems, such as the structure of the policy set tree, the use of certain types of attributes and the style and formatting of policies (what is in targets vs. conditions, how are policy ids and versions structured, how are policies document). If your goal is to propose a standard meta-language from which XACML policies can be constructed, I would be interested in working on this.

Part 1, alarms me a little. The determination of whether policies are applicable is THE fundamental mechanism of the XACML language. This change seems both very sweeping and underspecified. I see both architectural and practical difficulties. In no particular order:

How do policy references interact with the rest of policy evaluation? What if the id matches, but other Resource attributes don’t? What if the policy is not applicable because of Subject, Action or Resource Attributes? If the referenced policy is not applicable, can the PDP use other policies or does the policy id reference bar that?

This scheme would seem to imply that there must be broad global agreement on attribute names and values. This has proven difficult in practice.

Does policy id reference imply that only that policy is evaluated or would an enclosing policy set or a contained policy or policy set also be included? What if the policy (policy set actually) references other policies, are they evaluated?

Where does one find the authoritative instances of referenced policies? How do you know this policy is the same one as it was intended? Policies can be edited to correct errors for example and their id not necessarily changed. BTW, policy references should be to Policy Id and Version.

What is the trust model? If the PEP says to use a particular policy, does that mean it is automatically trusted?

In practice, there are many usecases where a specified policy for document needs to be combined with other local policies. For example, ITAR regulations and privacy rules may have to be followed everywhere, but a particular web site may further restrict access to members. Does your scheme support that?

If you are trying to bind a policy to a specific resource, why not have the policy reference the policy id or have a special value meaning “the resource I am attached to”, rather than mapping from request to policy?

It would seem that your requirements could be addressed by the use of per-decision policies as specified in XACML 3.0.

As I said, this is a major change to XACML evaluation. Do you have any operational or prototyping experience with this scheme?

Hal

From: Jean-Paul Buu-Sao [mailto:jean-paul.buu-sao@tscp.org]
Sent: Thursday, June 14, 2012 5:02 AM
To: xacml@lists.oasis-open.org
Subject: [xacml] XACML 3.0 Public review 04 - Feedback from TSCP

Greetings,

On behalf of TSCP (www.tscp.org), please find enclosed our feedback to the XACML 3.0 draft public review 04. We are aware that this feedback goes beyond the scope that you have defined, and would be grateful if you could consider it for further discussions.

With regards,

Jean-Paul Buu-Sao

Email:Jean-Paul.Buu-Sao@tscp.org

xacml message