OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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


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.


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,


as well as an initial list of work items for 3.0:

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

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
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.


Erik Rissanen wrote:

I have uploaded xacml core 3.0 wd 4 and delegation wd 18.

These fix some typos, update the examples to the new xpath datatype
and changes disjunctive/conjunctive matches to anyof/allof.

So there are not many changes, but I am uploading them anyway since I
intend to update the document templates as the next step. It's
cleaner and easier to follow the changes if I don't change the
technical content while I do that, hence the small update now.




	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

- 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
- 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 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 



I have uploaded draft 2 of the core spec and draft 17 of the delegation

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,


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:

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 



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

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,

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 



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,

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]