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: Updated working drafts posted


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 

=> 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:

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.
The corresponding attribute SHALL be of data-type 
This identifier indicates that the location is expressed as a DNS name.
The corresponding attribute SHALL be of data-type 

The reference itself was listed as

[SAML] Security Assertion Markup Language, available from 

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:


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:

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 

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,


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