Hi Hal, On 8/08/2014 3:38 AM, Hal Lockhart wrote: I would like to see what we need to do to move forward on the Privacy and the Admin&Deleg Profiles. I will comment separately on the Privacy Profile. I cannot even find the Admin&Deleg thread. Does anyone have a reference? In both cases, my questions are: is there a concrete proposal? Are the changes needed now or is this just an enhancement request? There are two main unresolved topics of discussion for the Administration and Delegation Profile. The first is category prefixing. There are three problems with category prefixing that are introduced in these three threads on the XACML comment list. A Problem with the "delegated:" Prefix
https://lists.oasis-open.org/archives/xacml-comment/201205/msg00000.html XPathCategory During Reduction
https://lists.oasis-open.org/archives/xacml-comment/201205/msg00004.html Multiple Decision Requests During Reduction
https://lists.oasis-open.org/archives/xacml-comment/201106/msg00003.html The first of those threads canvassed some possible solutions, but by far my preferred solution is to do away with category prefixing and use policy labelling instead, which was introduced in a later thread. Policy Labelling
https://lists.oasis-open.org/archives/xacml/201209/msg00001.html Erik appeared to accept the idea of policy labelling:
https://lists.oasis-open.org/archives/xacml/201211/msg00000.html The Policy Labelling thread then morphed into the second main topic of discussion, which was about alternatives to using the reduction graph to evaluate administrative requests.
https://lists.oasis-open.org/archives/xacml/201211/msg00016.html My objection to the current mechanism is that it is too difficult to use in practice. To quote from the aforementioned email: ... working out where to put an administrative policy under the current scheme is a burden policy writers can do without. Take the simple case where User A delegates all rights to User D. This is a very simple administrative policy that basically says "if the delegate is User D, then Permit". The issue is where to put it. User A needs to place it (by copy or by reference) in every policy set where User D will potentially be creating access policies. Furthermore, as new policy sets are created that User D might put policies into, User A will have to put the administrative policy in there as well. Conversely, if User A isn't thorough or proactive in placing the administrative policy, then User D will be limited in the rights he or she can actually exercise. Compounding the difficulties is the fact that in the general case, because of multi-valued attributes and augmentation of the delegate category by a context handler, practically any untrusted policy can be authorized by any administrative policy. It all depends on the request context. It is only by making assumptions about certain attributes being single-valued or by knowing about correlations between the attributes of an access subject that we can begin to predict which untrusted policies will be authorized by which administrative policies in the absence of any specific request context. These are things that users shouldn't have to be concerned with when creating administrative policies. The reduction graph also limits what one can do with administrative policies compared to access policies and I was hoping to give writers of administrative policies the same freedom as writers of access policies. I was proposing doing away with the reduction graph and simply assessing an administrative request against the collection of administrative policies and policy sets just as we assess an access request against the collection of access policies and policy sets. It is potentially a recursive procedure because administration policies may also need to be authorized by further administrative requests. In the worst case the cost of the procedure is roughly N! (N factorial) compared to roughly N * N for the reduction graph. The worst case is the rather dysfunctional situation where every administrative policy authorizes every access policy and every other administrative policy. The typical case would be nothing like that, but as I have no useful empirical data on what "typical" actually is, there was an action item on me to find an optimization with better worst case performance. I haven't found one. Rather than make a choice between the impractical and the expensive, I will now propose a compromise. The management difficulties of the current method would be alleviated if the reduction graph were formed from the sibling administrative policies of the access policy being reduced *and* the sibling administrative policies of each policy set enclosing the access policy being reduced. In this way an administrative policy with wide scope, such as "if the delegate is User D, then Permit", could be placed once in an outer policy set where it will automatically affect all the nested policy sets, rather than being laboriously reproduced in all of those nested policy sets. Any new nested policy sets would be automatically covered by the administrative policy without further action by the policy administrator. Administrative policies would still have some limitations compared to access policies, but at least they wouldn't be such a burden to maintain. Since we're in the neighbourhood, this issue with the reduction graph could also be addressed: Reduction Should Use Extended Indeterminate Values
https://lists.oasis-open.org/archives/xacml-comment/201106/msg00004.html Regards, Steven Let’s have some discussion on the call today. Hal *From:*Erik Rissanen [ mailto:
erik@axiomatics.com ] *Sent:* Tuesday, July 29, 2014 4:47 AM *To:*
xacml@lists.oasis-open.org *Subject:* [xacml] Current state of profiles All, I did a review of the current status of the profiles I am the editor of. * XACML 3.0 Additional Combining Algorithms Profile Version 1.0 I just posted WD-08 which corrects a typo which was found during the public review. The change is non-material so we should vote the profile up to CS without another public review. * XACML v3.0 Administration and Delegation Profile Version 1.0 There is an ongoing debate about the technical contents of this profile. * XACML v3.0 XML Digital Signature Profile Version 1.0 Latest document is CS-02.
https://www.oasis-open.org/news/announcements/xacml-v3-0-xml-digital-signature-profile-version-1-0-committee-specification-02-p I guess the next step is to get three statements of use. * XACML v3.0 Privacy Policy Profile Version 1.0 Latest document is csprd-02.
https://www.oasis-open.org/news/announcements/15-day-public-review-for-xacml-v3-0-privacy-policy-profile-v1-0-ends-june-6th However, there is an ongoing debate about the technical contents of this profile, so we cannot proceed until those discussions have been resolved. There were a couple of comments during the public review:
https://lists.oasis-open.org/archives/xacml/201405/msg00041.html https://lists.oasis-open.org/archives/xacml/201406/msg00000.html * XACML v3.0 Hierarchical Resource Profile Version 1.0 Latest document is CS-02:
https://www.oasis-open.org/news/announcements/xacml-v3-0-hierarchical-resource-profile-version-1-0-committee-specification-02-p I guess the next step is to get three statements of use. * XACML v3.0 Multiple Decision Profile Version 1.0 Latest document is CS-02:
https://www.oasis-open.org/news/announcements/xacml-v3-0-multiple-decision-profile-version-1-0-published I guess the next step is to get three statements of use. * XACML SAML Profile Version 2.0 I recently posted WD-19 of this profile, which corrects typos. The changes are non-material so we should vote this profile to CS without another public review. * XACML v3.0 Core and Hierarchical Role Based Access Control (RBAC) Profile Version 1.0 Latest document is WD-11. The changes are non-material since only non-normative text was changed, but a lot of text was impacted, so I think we should do a CS draft public review as the next step. Best regards, Erik