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 multiple resource profile and hierarchical

Rich and TC,

I have reviewed the draft you have posted (wd 05-02) as well as the 
recent discussion on the list, and I think the draft needs some more work.

I agree with you that the old profile had lots of ambiguities and small 
errors in it, and I think you have done a good job at spotting them and 
you have improved the text in many places.

However, I also think that the new work you have added in there 
complicates matters needlessly. There are two reasons for that:

1. You try to write the profile so it works with multiple intersecting 
hieararchies. I think that is the wrong way to do it. It should be 
specified for a single hierarchy only. If you need to apply it on 
multiple hierarchies, the way to do it is to preprocess the hierarchies 
by merging them into a single hierarchy. This joint hierarchy also needs 
to meet some consistency criteria, or the whole thing becomes 
meaningless and inconsistent. See more about that below.

2. You use the "root" concept. That is actually not required at all. As 
you have realized, the concept of a root in a DAG becomes messy to 
define and handle. I think we should just drop any reference to a "root" 
in the whole profile. All we need are "ancestors", and those are found 
by following the edges upwards. Not down from the root, so the root 
doesn't have to be defined. (In fact, in a DAG, there is not necessarily 
a unique root anyway.)

Finally, I think we should write the normative sections so they target a 
DAG only. Trees and forests follow as special cases. We can add 
explanatory text to make this clear, but the normative parts become much 
simpler if we don't define many different types of hierarchies.

I propose the following changes:

- First, a small nitpick. ;-) I don't like "Working draft 05-02". I 
think working drafts should progress 5, 6, 7, 8 and so on. It's 
confusing that there are several documents, all called working draft 5.

- Remove all the new definitions of "polyarchy", etc. They are not 
needed. Use only the term "DAG".

- Define a hierarchy as a DAG, where the nodes correspond to resources 
and the edges correspond to child-parent relationships.

- Define that each node in the hierarchy has one or more "normative 
representations" (names). A normative representations is defined as an 
XACML datatype value instance, which is provided in the request (through 
the context handler or the PEP). A representation which is not provided 
in the request is not normative, and may not be referenced in policies.

- This is actually already implied, but maybe worth stating: if one 
merges a number of hierarchies in the pre-processing step, the merged 
hiearchy must be consistent with respect to node representation/naming 
and the parent-child relationship. That is, if A and B are two 
representations of a node and C and D are representations of another 
node, and there is a relationship between the nodes, the same 
relationship applies to all representations/names. So all of the 
following would apply, not just some of them: A-C, A-D, B-C and B-D. I 
think the complexities in what you have done Rich is much due to that 
you have tried to cover hierarchies where this is not true. But those 
hierarchies are not internally consistent, so we cannot make them work.

- The ancestors of a node are defined as simply the transitive closure 
of the parent-child relationship.

Note that the above points imply that there is a single hierarchy which 
is a DAG. Also note that I don't make use of the term "root". It's not 

- Add in a couple of examples with illustrations showing a simple tree 
formed DAG and a more complex DAG which is not a tree and show how the 
ancestors are found.

- Remove section 1.1.1. It's not needed if we specify the algorithms on 
a sigle DAG only.

- Make a separate section about the URI-only scheme, saying that "in 
some cases when the resources are represented as URIs, it may be 
possible to simply do matching on portions of the resource 
representations". Also make it clear that the PEP and PDP must agree on 
which scheme is used, or the policies won't work.

- I think that a node may be represented by any XACML data type, like a 
string for instance, not just URIs. This is what the user posted to the 
comments list and requested that we change.

- I think there are some problems with section 2.2. In particular, it 
should not say anything about UTF-8 encoding. That's already defined by 
the core schema and it's unicode consistency requirements. I think 
actually that we can drop the whole of section 2.2 and allow any form on 
the normative representations of nodes. There is no reason to restrict 
it to a particular form of a URI. (The section on the URI-based schema 
should of course contain some restrictions for how that scheme is made 
to work.)

- We should not define a new identifier for a functionality named 

- There is no need to various subsections on multi-rooted hierarchies or 
polyarchies. See for instance 3.2.1 and 3.2.2.

In short, I think we need very few changes compared to the original 
profile. We just need to clarify the terminology and definitions, put in 
a couple of illustrations, relax the data type restrictions and add a 
section of a URI matching based scheme as an alternative to the other 
two schemes.

Best regards,

Rich.Levinson wrote:
> Hi Erik,
> The hierarchical profile is ready for review as is. There are no more 
> changes planned.
>     Note: The two added identifiers in section 2.2,
>     "...hierarchical:forest:non-xml-node-id" and 3.2.2,
>     "...hierarchical:forest:non-xml-node-req" are for convenience only
>     and the spec could be rephrased without them, if necessary.
> The profile is located at:
> http://www.oasis-open.org/committees/document.php?document_id=31407&wg_abbrev=xacml
> The example that Hal requested, which provides further motivation for 
> the changes, as well as detailed explanatory technical structure, is at:
> http://lists.oasis-open.org/archives/xacml/200902/msg00058.html
> A fresh example of application of the profile using URIs that came up 
> yesterday on the xacml-users list is at:
> http://lists.oasis-open.org/archives/xacml-users/200903/msg00001.html
>     Thanks,
>     Rich
> Erik Rissanen wrote:
>> All,
>> I have posted new drafts of the core and the multiple resource 
>> profile. See the change logs and tracked changes for details.
>> As far as I can tell, we don't have any open issues on the following 
>> specs:
>> - Core
>> - Multiple resource
>> - Administration
>> - Privacy
>> - SAML
>> - Dsig
>> The hierarchical profile is being discussed currently and there was 
>> discussion about improving the RBAC profile.
>> The proposed work on the RBAC profile seems in very early stages and 
>> the issue (policies about management of roles) is a major topic, so I 
>> propose that we don't bring this in 3.0.
>> So, could we agree on a feature freeze on the above mentioned 
>> profiles? If so, all of the expect hierarchical are ready for review 
>> before going to committee draft.
>> I also propose that if we don't get resolutions on the issues in the 
>> hierarchical profile soon and it would appear that there are major 
>> changes required, then we use the old version of that profile. 
>> However, my understanding is that Rich has pretty much completed the 
>> work on that. I haven't had the time to review it myself yet, but I 
>> will do so now.
>> So, given the above, can we agree on the following?
>> - everybody reviews the above mentioned profiles
>> - We correct any mistakes
>> - I will fix the metadata, references, namespaces, etc,
>> - Go CD with the above
>> One final issue: we need to update the acknowledgements section of 
>> the core. What goes in there? My name is not in there, and I would 
>> like to include it. :-) I presume that we keep all the old names, 
>> right? John Tolbert has requested to be added. Anybody else?
>> Best regards,
>> Erik
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  Follow this link to all your TCs in OASIS at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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