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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-dev message

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

Subject: RE: [xacml-dev] XACML 2

Hi Seth,

Interesting... Now I understand why there is no version in the Policy
element, but there is a Version in the PolicySet. I like the feature.

About the policy language version issue, or any versioning problem (i.e
policy.version != context.version), we can agree about a behavior in
this forum and notify the TC about it. It will be great because both
implementations will behave similar, in this out of scope issue for the

I was reviewing the spec yesterday and I found some additions: functions
(3) and datatypes (2). I'll send an email to the public list about some
inconsistences in the document, because the functions and data types
have different names in different parts of the document. :S 
What do you think about functions that apply to any type <type>-equal,
<type>-greater-than, <type>-greater-than-or-equal, etc (section 7.5). In
the spec they, are preceded by "urn:oasis:names:tc:xacml:2.0:function",
it means the name of the funtions of the previous version are not valid
anymore? It means V2 policies can't have V1 functions? Is any typo error
in the spec, because the function list in 1.2.8 and the function
description in A.3 uses the names preceded by
"urn:oasis:names:tc:xacml:1.0:function" ?

I also found that some resource attributes described in 1.1 are not
described in 2.0, what do you think about it, the old ones are not

I have not reviewed the complete spec, but I'll like to start discussing
about this issues.

Thank you,
Diego Gonzalez
Lagash Systems SA

-----Original Message-----
From: Seth.Proctor@Sun.COM [mailto:Seth.Proctor@Sun.COM] 
Sent: Wednesday, September 22, 2004 1:20 AM
To: Diego M. Gonzalez
Cc: xacml-dev@lists.oasis-open.org
Subject: Re: [xacml-dev] XACML 2

Diego M. Gonzalez wrote:
> Seems the scenario you are proposing about references between versions

> is covered with the elements that extends IdReferenceType 
> (PolicySetIdReference and PolicyIdReference) now the references must 
> add some information about versioning: Version, EarliestVersion and 
> LatestVersion. The section 5.21 defines the matching behavior.

Actually that's a little different. The new feature in 2.0 is about
revision numbers on policies, not which version of XACML is acceptable
(which is what I raised). The new version feature has two components: it
lets me put a version number in a Policy or PolicySet (eg, this is
version 2.3.7 of this policy) and then lets me put a required version or
range of versions in a reference (so, for instance, I can reference any
versions of the policy later than 2.3). If more than one version is
available, you're supposed to use the latest version available. Note
that these are optional attributes, so you can ignore them in your
policies and references, and you get the same behavior as in 1.x. I
suggested this feature for 2.0, so if you don't like it complaints go to
me :)

The original issue I raised had to do with the version of XACML a policy
uses. So for instance, let's say we have an XACML 2.0 policy with a
reference to an XACML 1.1 policy. How should we handle this? My instinct
is to allow the engine to process the 2.0 policy using the 2.0 spec, but
process the referenced policy using the 1.1 spec, since the result that
comes back means the same in 1.1 and 2.0. I suspect, however, that I'll
discover some corner cases when I actually try doing this. Dunno. We'll


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