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

[Erik Rissanen <erik@axiomatics.com>]

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