[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Updated working drafts posted
All, After a couple of days of work, I have finally updated all the specs with the decisions we made at the F2F. My thanks to all participants at the F2F. The drafts should have appeared on the list a few moments ago. I have attached the updated issues list to this email. I have had to make some tweaks and decisions on details as I edited in all this. The important issues you should be especially aware of are described below. => I have not fixed cross references or updated the profiles which have not changed. I don’t think it is worth the effort to update all cross references for the working drafts. I will make right for the committee draft (and later). It is getting a bit late tonight, so I will make a full list of all cross references tomorrow for the CD vote. I have not updated acknowledgments yet either for the same reason. => I fixed a small inconsistency in the text about the multiply functions, noted by Ludwig here at Axiomatics, so this issue has not been tracked by the TC. The text in section A.3.2. said “However, the “add” functions MAY take more than two arguments”. I updated it to “However, the “add” and “multiply” functions MAY take more than two arguments” since the multiply function can also take multiple arguments. => Issue #57 was about ambiguous use of the term “xpath-expression”, and I was to update the section so the use of the xpath expression data type identifier is spelled out in full. When I was about to do this change, I saw that there is no ambiguity and that the identifier is already spelled out in full. So did not do anything on this issue, and I am marking it as “pending review” in the issues list. => I made some minor corrections in Jan’s proposal for generalized higher order functions. I have specified bounds for the “n+1” arguments since none were specified at the F2F. I put that n must by one or greater. Note that this actually generalizes the function a bit more than Jan maybe thought. Jan wanted to generalize the functions to functions with three or more arguments. This new specification also allows for one argument functions. Note also that we decided at the F2F to allow any number of bags for the any-of-any function, so it works on the full cross product. I also did not see any reason why primitive values should not be allowed as well, so I allow them in the text. (In any case the same effect could have been achieved with a singelton bag, but this is more convenient to use.) With this definition the any-of function actually becomes a special case of any-of-any, with one primitive type argument and one bag argument. I don’t think this is a problem, and for backwards compatibility reasons I think we should keep both functions, rather than dropping the any-of. Let me know if you think we should drop the any-of function. I wouldn't mind too much. => I am putting issue #25 into “pending review” without any action since I think this issue is resolved by the refactoring of the multiple schemes. I think I misunderstood this issue originally, so the text in the issues list doesn’t make sense to me anymore. What I think Jan meant is that he wanted “scope = descendants” for XML resources, but we all agreed that scope is not needed for the XML case since the original xpath expression can do any kind of scope directly. So there is nothing to do in this case. => Regarding the XPath node match, equal and count functions, I cannot think of any simple general transformation into an equivalent attribute selector and I have not received any proposal from other TC members, so I am leaving the xpath node functions as they are. => We decided to change the multiple XML scheme so it no longer uses the resource-id attribute. Instead we defined a new attribute called “content-selector”. I made the same change in the hierarchical profile as well since otherwise the output produced by the multiple “pre-processor” would not match the specification for individual requests in the hierarchical profile. => I have not seen any proposals for names for the new XML attributes in attribute selector, so I am going with this: The old RequestContextPath is renamed to simply “Path” and the new attribute is called “ContextSelectorId”. => Paul’s original proposal contained multiple-content-selectors for all the different categories (resource, subject, action, and so on), so I have allowed the use of the XPath based multiple scheme also for other categories than the resource. I think it may be useful to be able to ask for decisions for multiple subjects where the subjects may be described with XML content. => I tried to clarify the conformance section of the multiple profile. I added some identifiers there and I removed the reference to section 4 (now section 5 in the updated document), which I think is not required. Since the conformance section is so important, it is good if everybody reviews this section carefully. => It is unclear to me what should happen with obligations in combined decisions. I thought about it and it doesn’t quite make sense to combine the obligations since each obligation is associated with a single decision on a particular resource (and subject, action, etc). For instance, an obligation such as “log-access-to-the-resource” does not make sense for a combined decision since it is not clear how the combined decision relates to the use of any specific resource. So, I made the specification so a combined decision never includes any obligations. If obligations are important, then the PEP has to request the full list of individual decisions with the obligations. => I have added a new section to the multiple profile which specifies the overall order in which the different schemes combine. I took and tweaked the text which I made on the list based on Paul’s original proposal. => I did not add the URI scheme to the multiple profile since it does not fit in. The ancestor scheme is not referenced either as the spec was already. The hierarchical schemes are really about what an individual request looks like for a hierarchical resource. It is not about how to generate multiple requests from a hierarchy. The multiple profile will work for any kind of hierarchical scheme, including the URI scheme, as it is. => I added references to the normative sections in the spec from the conformance section. I say “The implementation MUST follow sections 5, 6, 7, A, B and C where they apply to implemented items in the following tables” just to be sure explicit. Please review the conformance section. => Mary complained when we went CD-1 that references to OASIS specs are not in the right format. One of the references is a reference to SAML. It occurs in the following text in the section about defined identifiers: --8<-- The following identifiers indicate the location where authentication credentials were activated. They are intended to support the corresponding entities from the SAML authentication statement [SAML]. This identifier indicates that the location is expressed as an IP address. urn:oasis:names:tc:xacml:1.0:subject:authn-locality:ip-address The corresponding attribute SHALL be of data-type "http://www.w3.org/2001/XMLSchema#string". This identifier indicates that the location is expressed as a DNS name. urn:oasis:names:tc:xacml:1.0:subject:authn-locality:dns-name The corresponding attribute SHALL be of data-type "http://www.w3.org/2001/XMLSchema#string". --8<-- The reference itself was listed as [SAML] Security Assertion Markup Language, available from http://www.oasis-open.org/committees/security/#documents This reference is not enough for me to be able to locate the intended SAML specification. Do you know what was intended? For now, I removed the reference and the sentence “They are intended to support the corresponding entities from the SAML authentication statement [SAML]” since I did not think this was very important since it the attributes are defined even without the reference and I can see how other modes of authentication could be used to get the attributes. If you want me to put it back in, just send me a clear reference to the correct section in the SAML spec, and I will put it in again. => Paul posted examples of some clever use of an AttributeSelector. See here for instance: http://wiki.oasis-open.org/xacml/XpathDiscussion?action=recall&rev=10 I think that kind of use is not allowed by the current definition of AttributeSelector since it requires that the xpath selects textual content from a node. See the following piece from the spec: --8<-- Each node selected by the specified XPath expression MUST be a text node, an attribute node, an element node, a processing instruction node or a comment node. The string representation of the value of each node MUST be converted to an attribute value of the specified data-type, and the result of the AttributeSelector is the bag of the attribute values generated from all the selected nodes. If the node selected by the specified XPath expression is not one of those listed above (i.e. a text node, an attribute node, a processing instruction node or a comment node), then the result of the AttributeSelector SHALL be "Indeterminate" with a StatusCode value of "urn:oasis:names:tc:xacml:1.0:status:syntax-error". --8<-- Paul’s xpath expression on the other hand evaluate to Boolean or integer data types within the xpath language, rather than selecting nodes, so they don’t conform to this specification and are not allowed. I thought about dropping this restriction, but when I look at for instance the Java 5 XPath API, it is unclear to me how the more generalized selector could be implemented. The API requires that the Xpath evaluation method is invoked with a parameter which specifies the return type of the xpath expression. There are a couple of supported data types such as node set, string and Boolean. In other words, if the XACML implementation evaluates the xpath expression, it must know beforehand whether it expects a Boolean or a string, which would depend on the form of the expression. I haven’t tested, but when I read documentation on the web, it says that the XPath API will throw an exception if the conversion between the actual and expected return type cannot be made. So it seems unclear to me how to fix this, so I am leaving it as it is. => I added the xs:any to the SAML authzq request to solve David Chadwick's issue. I had to wrap the “any” within an <Extensions> element since putting the “any” next to the other elements in the scheme violates one of the conditions for a valid schema. (The so called "unique particle attribution rule", that the parser must be able to tell whether an element it parses matches the “any” or one of the other declared elements.) Best regards, Erik
xacml-3.0-cd-1-comments-upd-15Dec2009-B.xls
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]