Hi Erik,
I looked up to find discussion on this and didn't quite get a match,
although there was a ref in the Nov 6 minutes:
http://lists.oasis-open.org/archives/xacml/200811/msg00027.html
possibly related to this exchange on xacml-comment:
http://lists.oasis-open.org/archives/xacml-comment/200811/msg00001.html
Those were regarding details. I understand that one might consider
regexp-match an alternative to <type>-equals, however, what I
don't understand is why regexp-match is used for all of 4 xacml-defined
datatypes for identifiers or resources:
dnsName - A.3.13 line 4843 ->
ipAddress - A.3.13 line 4835 ->
rfc822Name - A.3.13 line 4851 ->
x500Name - A.3.13 line 4859 ->
while for <type>-equals there is only:
rfc822Name - A.3.1 line 3982 ->
x500Name - A.3.1 line 3968 ->
These 4 datatypes are discussed in section A.2 starting on line 3850.
There is additional detailed info as ref'd above for rfc822, x500 under
A.3.1 <type>-equals.
As I look at it some more, it is beginning to appear that the
comparable detail that is listed in A.2 for ipAddress and dnsName is in
section A.3.1 for rfc822 and x500 under <type>-equals.
There is something out of balance here at a cursory look. It would seem
that either ipAddress and x500Name should also be in section A.3.1 or
there should be an explanation as to why they are not. As it stands
now, it looks like an editing error to me - not a serious error, but
one that causes some confusion. And also, it looks like it might have
occurred because ipAddress and dnsName were added later, which is why I
suggested it was likely an oversight.
Another possibility is that the info in section A.3.1 should be
removed, put in section A.2 with the others and all of them should use
regexp-match. i.e. the explanation of how to do rfc822Name-equal and
x500Name-equal appears to be a stretch for a "-equal" function, esp. if
the other two are done w regexp-match.
It's not of earth-shattering importance, I admit, but this is a
suggestion for the "clean-up" and on the surface, at least, it appears
to me to be more of a cleanup than a correction of any specific error
task, except that if the original update was inadvertent, it may
effectively be introducing an error of imbalance, unless, of course,
there is a reason, in which case it would be desirable to put the
reason in section A.2.
Thanks,
Rich
Rich.Levinson wrote:
Hi Erik,
That's fine. It would be useful to dig up the rationale, and possibly
put it in the doc somewhere, such as section A.2 where these items are
discussed in some detail.
Also, my last question was simply if there is any relation between the
dns-name of the Subject attribute and the dnsName of the datatype. Same
for ip-address. i.e.would it be reasonable to expect that these
datatypes would apply to AttributeValues associated with those subject
attribute ids? I suppose the answer is obvious - that there could be
but doesn't have to be. But I was also wondering what motivated the
addition of these datatypes. Possibly it was related to the remark I
just noticed on line 5098-99 which preceded the subject attributes:
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].
i.e. there was some SAML activity with these, which appears to have
raised their visibility to the point where they were late additions to
the xacml datatypes.
Thanks,
Rich
Erik Rissanen wrote:
Hi Rich,
I think we discussed this some time ago. It's intentional since there
are pattern matching functions instead. And, yes, I also pointed out
that this means that the set functions are not defined for those data
types because of this, but I think this was not seen as a problem. I
don't recall the details of the discussion though, so I might be
mistaken.
I don't understand your last question.
Best regards,
Erik
Rich.Levinson wrote:
There are no equality predicates in section
A.3.1 for the following datatypes:
* urn:oasis:names:tc:xacml:2.0:data-type:ipAddress
* urn:oasis:names:tc:xacml:2.0:data-type:dnsName
* urn:oasis:names:tc:xacml:3.0:data-type:xpathExpression
I don't know if this was intentional, but suspect it was just an
oversight as these 3 data types were added after XACML 1.1.
Also, it appears some or all of them may be missing from some
functions:
* intersection
* at-least-one-member-of
* union
* subset
* set-equal
Also, I am curious what, if any, association might or might not be
intended between the first two above and the Subject identifiers:
* urn:oasis:names:tc:xacml:1.0:subject:authn-locality:ip-address
* urn:oasis:names:tc:xacml:2.0:data-type:dnsName
Thanks,
Rich
