Profile updates for 3.0

[Erik Rissanen <erik@axiomatics.com>]

All,

I have updated all the 2.0 profiles to 3.0, except the RBAC profile 
which I haven’t got to yet. (BTW, some of the profiles have not been 
assigned editors yet by the TC, but I hope nobody minds me fixing them.) 
And I haven’t touched the SAML profile, which Anne pretty much finished 
before she left.

I have not yet converted them to the new OASIS template since I wanted 
to make diffs with the technical changes first. Also, I have not changed 
references, layout and other details. I will do that when I convert them 
to the new template since I need to redo all bookmarks anyway then. The 
following summarizes the changes:

- Hierarchical -

I have updated the identifiers used to identify the profile 
functionality to ”3.0”, but I have kept attribute identifiers and 
datatypes as they are since there mostly is no need to change their 
functionality.

One exception is the xpath-expression data type. Its definition refers 
to the <ResourceContent> element, which has been replaced with 
potentially several <Content> elements. We have discussed this datatype 
earlier, and I proposed that it is replaced it with a general mechanism 
for use of xpaths. However when I started to do this change, it seems to 
me that this datatype is not needed at all. The wording of section 5.1 
makes it sound like the datatype is a special construct which also acts 
as a function and the datatype value is not the string itself, rather 
the nodeset selected by the string interpreted as an xpath expression. 
However, it is intended to be passed to the xpath-node-match function, 
which takes strings as a parameter. As far as I understand, everything 
would work even if it was just a string, except for the namespace prefix 
binding issues we have discussed previously and which were fixed by the 
new xpath data type in 3.0. So, I have removed section 5 and used the 
new xpath datatype instead.

Could everyone verify that I have not missed anything important here?

Also, while doing this, I saw that the definitions of the xpath 
functions in the latest 3.0 core draft was missing a specification of 
the context node for evaluating the xpath expressions. I have added text 
for the next core draft which specifies the <Request> element as the 
context node.

BTW, there is an error in the 2.0 version of the hierarchical profile. 
Section 4.2 refers to a function called 
urn:oasis:names:tc:xacml:2.0:function:xpath-node-match in the 2.0 core. 
However, there is no such function in the core (or at least I didn’t 
find one). There is a function with almost the same name, just with a 
“1.0” instead of “2.0”, but this doesn’t take the right types of. It 
takes strings with xpath expressions, but in the hierarchical profile 
the relevant attributes have the “custom” xpath-expression data type.

Finally, the 2.0 hierarchical and multiple resources profiles talk only 
about resources. The same approach could of course be generalized to 
other categories, such as hierarchical subjects. I am not sure whether 
we should do so. I suggest that we don’t. I don’t see the use cases.


- Multiple -

I have updated the profile specification to reflect the new core schema 
and to use the new xpath datatype. As was discussed earlier, I have also 
allowed multiple <Attributes> elements of other categories than the 
former <Resource> element. However, since I did not generalize the 
hierarchical profile to other categories, the methods to specify 
multiple resources based on hierarchies only apply to resources, not 
subjects, etc.


- Privacy -

Only minor changes were required to the privacy profile. I have changed 
the title and updated the example to the new schema. The example 
contained an “xsi:schemaLocation” attribute at the <Rule> element, which 
I removed since it didn’t have a correct value and I didn’t see the need 
of it in the example.


- Digital signature -

This didn’t require any changes in the technical content as far as I 
could tell. Just fixed the title. :-)

Best regards,
Erik