[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] New core and delegation drafts uploaded
|
Hi Erik, As a quick test I ran thru the updates to XACML 3.0 core emails for releases and collected the info in a single text doc. Please check over the attached and let me know if you think it is complete and accurate. Also, would there have been any preliminary emails or other docs that describe what the intended changes to xacml-core-3.0 were. Thanks, Rich Erik Rissanen wrote: 46D10E40.3060002@axiomatics.com" type="cite">Hi Rich, There is no such document at the moment, but it would be fairly easy to make one. There is a summary of changes for each draft and a word diff, so you could just read those and collect them into a single document summarizing the changes. Regarding requirements, there are discussions about these in the email archives and meeting minutes. Look for discussions where Frank Siebenlist is participating. Also, the 3.0 issues list is on the wiki. Old closed issues are on a separate page. All this could of course also made into a doc if that would be useful. Regards, Erik Rich Levinson wrote:Hi Eric, I am trying to get a handle on what is included in XACML 3.0 that is different from XACML 2.0. Is there a doc that lists each spec and what changes have been made to it, plus a list of new specs and what they consist of? I think there were some attempts along these lines in 1.0->2.0, http://www.oasis-open.org/committees/download.php/12821/xacml_1.x_2.0_diffs_draft.doc as well as an initial list of work items for 3.0: http://www.oasis-open.org/committees/download.php/13387/XACML%203.0%20open%20issues%20and%20work%20items.doc However, I have not found something similar for 2.0->3.0. The reason I ask is that I think it would be useful to have a list of the major changes that are in the 3.0 package, so that when the time comes for approval votes that we have a full context for evaluating the package. What I would envision is for example in the core doc, a list of the major issues that were addressed, possibly with a pointer to the main section(s) of the doc where the changes associated with that issue may be found. For the new docs, possibly a brief list of the major reqts that drove the need for the new spec, possibly w pointers to email archives where discussion relevant to the plans for the spec might have occurred. Finally, each schema probably should have a list of changes as well. I would be happy to help out with this, but it would be useful if any existing items along these lines would be made known for a good starting point. Thanks, Rich Erik Rissanen wrote: |
XACML 3.0 Core: ******************************************************************************** Subject: Groups - xacml-3.0-core-wd-04.zip uploaded From: erik@axiomatics.com To: xacml@lists.oasis-open.org Date: 24 Aug 2007 14:08:24 -0000 -------------------------------------------------------------------------------- Fixes some typos, updates the examples to use the new xpath datatype and changes disjunctive/conjunctive to anyof/allof. -- Erik Rissanen ******************************************************************************** Subject: Groups - xacml-3.0-core-spec-wd-03.zip uploaded From: erik@axiomatics.com To: xacml@lists.oasis-open.org Date: 5 Jul 2007 13:29:24 -0000 -------------------------------------------------------------------------------- This is an updated XACML 3.0 core draft. It contains the following changes: - A text about Xpath 2.0. This has not yet been discussed much in the TC, so please review this carefully. - Refer to the approved W3C recommendation on xpath 2.0 for some function and datatype definitions instead of an early draft. - Fixes some typos and makes some clarifications - Incorporates all 2.0 errata - Clarifies text about Indeterminate and status code in case of missing attributes (issue 83). This has not been reviewed much in the TC yet, so please do so. - Adds an xpath datatype and defines new functions which use it (issue 78) - Adds string conversion functions and deprecates the old uri concatenate function (issue 38) - Adds the IncludeInResult xml attribute, which functionally replaces the resource-id xml attribute in the response. (issue 77) Best regards, Erik -- Erik Rissanen ******************************************************************************** Subject: Groups - xacml-3.0-core-wd-02.zip uploaded From: erik@axiomatics.com To: xacml@lists.oasis-open.org Date: 10 May 2007 08:19:52 -0000 -------------------------------------------------------------------------------- New core spec draft. See separate email for details. -- Erik Rissanen Subject: New core and delegation drafts From: Erik Rissanen <erik@axiomatics.com> To: xacml@lists.oasis-open.org Date: Thu, 10 May 2007 10:30:48 +0200 -------------------------------------------------------------------------------- All, I have uploaded draft 2 of the core spec and draft 17 of the delegation profile. The changes are that I have implemented a number of "Pending" issues: 32. Exception handling (aka reduction of indeterminate) The new delegation processing model now handles indeterminate results, as I described earlier on the list and at the F2F. Note that this means that the delegation algorithm description has changed quite a bit. 40. The <ResourceContent> element I removed the content URI as decided. 50. Maximum delegation depth with attribute categories There is a special XML attribute for this now, rather than it being an XACML attribute. 54. Number of policies required by administrative policy delegation I have added a section describing this issue under "Optimization". 64. Treatment of administrative deny The new reduction algorithm has a simpler treatment of administrative deny, as described earlier. 68. Backwards compatibility of generalized Target As decided, I changed the DisjunctiveMatch to the more general form which is backwards compatible. I will update the issues list so the status on all these will be pending review. Feedback is encouraged as usual. Meanwhile I will work on solutions for the remaining open issues which I "own". Best regards, Erik ******************************************************************************** Subject: Groups - xacml-3.0-core-wd-01.zip uploaded From: mirty@sics.se To: xacml@lists.oasis-open.org Date: 22 Feb 2007 09:53:43 -0000 -------------------------------------------------------------------------------- The document named xacml-3.0-core-wd-01.zip has been submitted by Mr Erik Rissanen to the OASIS eXtensible Access Control Markup Language (XACML) TC document repository. Document Description: View Document Details: http://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=22558 Subject: New drafts uploaded From: Erik Rissanen <mirty@sics.se> To: xacml@lists.oasis-open.org Date: Thu, 22 Feb 2007 11:01:28 +0100 -------------------------------------------------------------------------------- All, I have uploaded the first draft of 3.0 core and an updated delegation profile draft. There are still issues pending as I have posted on the list, but I wanted to make it available for all so you can start reading them and providing comments. Also, particularly the core document, I have probably missed many small things. Here are some highlights of the changes and issues remaining: The problem with the generalized target and backwards compatibility of subject categories remains in this draft. The id is still there in the AttributeSelector, although it should probably be removed. I updated the reduction table according to the simpler reduction model I explained at the last meeting. Treatment of indeterminate is still not defined. In line with this, I removed references of combination happening during reduction. Since we don't support negative administrative rights, there is no need to combine during reduction. I have tried to simplify the descriptive text as well. In particular I removed the talk about "policy values" being reduced which didn't help the description much. Now it's just policies which are reduced. Thanks to all the simplifications and the generalized core, the delegation processing model is only about three pages now. :-) Note that there is a corner case in the simplified delegation model with regard to nested policy sets. When an administrative request enters a nested policy set, if there are any policies with non-trusted issuers, they will be reduced even if they say deny on the administrative request. Deny results during reduction still have no effect though, as intended. (What we don't want is that one policy says yes and another no during reduction.) It is also possible to write a nested policy set which contains trusted policies, where the trusted policies may override each other with deny even if they are administrative policies. This is a good thing since it allows writing policy sets based on a broad permit and exceptions in the form of deny, even in the case of administrative policies. Again, deny administrative policies are ignored during reduction. Could someone who knows, check that I chose the right version of the legal boilerplate? I removed the last paragraph from use case 1 in section 3.1.1 in the delegation profile. It used to say: 'It is also desirable to support multiple levels of indirection, so it should be possible to say things like "Jack can create policies that let Mary create policies about the Financial Servers."' This is not possible without indirect delegates, which make delegation NP-complete. (Let it be known if you think this use case is important enough to make delegation NP-complete.) Maximum delegation depth is still the same as in the previous draft, with the problems I explained on the list. There are some issues with the Access Permitted feature. I am explaining those in a separate email so the issues are not lost in this email. Best regards, Erik Subject: Issues with the Access Permitted feature From: Erik Rissanen <mirty@sics.se> To: xacml@lists.oasis-open.org Date: Thu, 22 Feb 2007 11:04:00 +0100 -------------------------------------------------------------------------------- All, There are some issues with the Access Permitted feature as it is in the current draft (delegation wd 16, section 9). It says that the access permitted function takes a parameter of string type which shall be interpreted as the XML content of an <Attributes> element of Category “Subject”. However, there is no special category “Subject” in the generalized form of XACML 3.0. Each subject category is now its own attribute category. Is it intended to be the access-subject? Another alternative is that the parameter to the function may contain a number of <Attributes> elements with identified categories, and the supplied <Attributes> elements replace the corresponding elements from the request context, to form the recursive request. Would this solve the intended use cases? However, I think this form is NP-complete. (I have a sketch for a proof in my head, but I haven't it in writing, so I might have missed something.) Also, it says in the section on Access Permitted in the delegation draft that it should be moved to the core. I don't remember why it says so. Should it be in the core or the delegation draft? In principle it could stand on its own in the core, but the functionality is somewhat similar to delegation. Best regards, Erik
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]