Re: [xacml] Possible issue or editorial cleanup item - missing equalitypredicates, etc.

["Rich.Levinson" <rich.levinson@oracle.com>]

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