XACML 3.0 open issues and work items
Dated: 5th ofJuly 2005
This document lists current open issues and work itemsin the work for XACML 3.0.
Open issues
1. Delegate attributes in the request context
An administrative request needs to define attributes of the delegate whose administrative rights are to be checked. We need a syntax for specifying these in the request context.
2. Issuer in the policy
We need to define a syntax for specifying the issuer of a policy. This also includes some special value or form for the case when the policy is a root policy. It has been suggested that the issuer of a policy should not be a simple single identity attribute, but arbitrary attributes of the issuer may be indicated, in the same fashion as the subject attributes in a request context. We also need to define how the administrative request context is built from the issuer attributes in the policy.
3. Should elements in a policy target and the request context be open?
The delegation model will require additional information besides the 2.0 elements in the request context. It has been suggested that instead of defining more elements in the schema, the schema should allow any element in the request context.
4. PDP references in policies
How could a policy delegate a decision request to another PDP? This requires a syntax for PDP references.
5. Policy statements and attribute assertions in the request context
The “push model” of attribute and policy distribution means that the requestor collects his credentials and passes them along in the request. Supporting this in XACML would require additional syntax for the request context so that policies and attribute assertions could be passed along a request.
6. Identity attributes
Do we need to differentiate identity attributes from other attributes? In that case we need a syntax for that in the request context and the policy issuer. The motivation for identity attributes is that we need to differentiate which attributes should be used for further resolution of other attributes. In a heterogeneous environment there may be multiple kinds of identity attributes, so the “subject-id” alone is not enough.
7. Maximum delegation depth in the request context
Should we let the requestor define a maximum allowed depth of delegation in the request context?
8. Alternate Owner-Policy-Statement to determine sentinel
Frank proposed that the anchor point authority for PDPs are independent. (Erik’s note: I don’t recall what this discussion was about.)
9. Backwards compatibility with XACML 2.0
Should we stay compatible with 2.0? Should we instead define a translation algorithm for converting between 3.0 and 2.0?
10. Obligations
How are obligations treated by the delegation processing model? Also, for now, until someone motivates otherwise, administrative policies cannot contain obligations.
11. Information on “downstream” delegates in the request context
In some cases it may be desirable to write conditions based delegates further down in a delegation chain besides the immediate delegate. How should this information be made available?
12. More general conclusions
It has been proposed that the XACML language should be generalized to allow more complex decisions than yes/no. This could for instance mean that a rule which specifies encrypted access would override or be overridden by a rule which specifies unencrypted access, according to rules specified in the policy. There has also been discussion about imperative sequences as conclusions. Backwards compatibility with obligations is also an issue in this context.
13. “What are my permissions?”
In some cases it may be desirable to in some manner enumerate applicable permissions for a specified individual or resource. Currently it is unknown exactly what is desired, how feasible it would be and whether it is something that should be defined by the XACML standard.
14. “What do I do?”
Should we handle questions of the type “Here is a target, what do I do?” in addition to “Here is a target, can I?”?
15. Should we use ”Delegate” or ”Issuer” in the request context and policy target?
For now the draft uses “Delegate”.
16. Our statement on negative rights.
Should we forbid the use of negative permissions, or just recommend to not use them? It would be possible to define a combining algorithm that handles negative permissions, so maybe we should leave this open for people to extend it?The current draft (draft 07) is a not consistent on this issue, but I (Erik) don’t know which way it should be.
17. Do we need an attribute selector for DelegateMatch?
18. LaterDelegate issues
Should we have attributes indicating order among the LaterDelegate elements? How can we refer to those in conditions?
Can we define an attribute for the policy issue instant? This is needed in case the context handler should look up historic issuer attributes for consistency with any attributes that may be present in the PolicyIssuer element.
Is the term “LaterDelegate” a good one?
19. Subject categories for delegates
Do we need/want them?
20. The trusted issuer
We should decide the form of the trusted/PDP issuer.
21. Should the policy issuer be called “PolicyIssuer” or just “Issuer”?
22. Right to revoke
Should we give more support for revocation? This is a complex issue that I (Erik) haven’t fully researched myself yet, but I can give use cases where it is needed.
23. Access Permitted
The “Access Permitted” feature remains to be defined. This should not be too difficult to do.
Work items
No. / Task / Responsible / Status / Est. completion1. / Define first version of a normative processing model for delegation. / Erik Rissanen / Done / 5 July 2005
1b. / Agree on the processing model and document it. / Erik Rissanen / ? / ?
2. / Define the various details and features of delegation in schema form. / Erik Rissanen / Not started / End of July 2005? (Note that this depends on the extensibility item below.)
3. / First draft of an XACML 3.0 core that is extensible so it can support the proposed delegation/generalization profiles. / ? / Not started / ?
4. / Generalization profile / ? / Not started / ?
5. / Document explaining backwards compatibility with 2.0. / ? / Not started / ?
6. / Profile for partial evaluation of policies for the purpose of policy examination? / ? / Not started / ?