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

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

Hi Erik,

I see from the references you gave that you essentially raised a very similar issue a few months ago, and that it was apparently decided (I realize I was on the call and wrote the minutes :) ) to leave things as is. So, I agree, there is no point now trying to rush something through, and presumably, when the changes for dnsName and ipAddress were added that the requirements at the time were met. The essential information appears to be there if you really look for it.

Maybe we can carry this forward for another release - we should probably have a bucket for things we think should probably be addressed down the road but don't make the cut on this train.

    Thanks,
    Rich


Erik Rissanen wrote:

49D72CA1.60908@axiomatics.com" type="cite">

Hi Rich,

I was referring to this thread:

http://lists.oasis-open.org/archives/xacml/200807/msg00021.html

The minutes of the TC call where we discussed the issue are here:

http://lists.oasis-open.org/archives/xacml/200807/msg00026.html

I'm not sure how to read that, but I recall that we decided to not
introduce these equality functions. And since the set functions are
defined in terms of the equality functions, the set functions are also
undefined. I am pretty sure I pointed out this in the discussion, though
it's not recorded in the minutes. So the spec is right now as the TC has
decided.

Best regards,
Erik

Rich.Levinson wrote:
  

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