[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Profile updates for 3.0
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]