OpenSAML user discussion

["Scott Cantor" <>]

> Sorry, I don't see why an equivalence relation on SAMLNameIdentifier
> objects (and SAMLObjects in general) is such a bad idea.  In fact, I
> think I've given ample reasons to show the opposite is true.

There is no single definition of "equivalence". Therefore, any such
definition is application-specific (SAML matching rules *are* specific to
certain use cases) and designing algorithms that can't accommodate more than
one is just wrong, assuming the algorithm itself doesn't impose one. That's
why C++ containers and algorithms don't require the use of operator==.

> Without it, the following unit test fails:

You can't make up a unit test and then assume that something is broken
because the test doesn't work. Not even if it makes intuitive sense. I said
over and over that equals() doesn't mean what you want it to mean, so why
would your unit test be correct?

> This fails because String equivalence is inappropriate in this case. 

I agree. Yet you specifically said in an earlier message "why not wrap
string equivalence inside an equals() method?" Yet that would NOT do what
you want it do. What about somebody else that wants equals() to mean string
equivalence? Define it as semantic equivalence and their code won't work.

I don't know how else to say this...don't use equals(). Define code that
either directly implements the rules required or accommodate a Comparator
that can implement exactly the rules you want for the situation. That is a
superior design.

> I tried to explain this in another thread.  The spec says that the
> absence of a specific format URI implies the 'unspecified' format, so
> this must be taken into account when equating formats.  This should be
> done in the SAMLNameIdentifier class itself.

That's an opinion, and one I don't particularly feel strongly about one way
or the other, but it doesn't matter...you don't *need* access to the
internals of that class to define a matching method that recognizes the
equivalence of an empty format and something else. But you can define it
there just as easily too. And I don't care what it's called, but I would go
to the mat over making the mistake of calling it equals() *because* Java
makes use of that method.

I'm more than willing to admit that this is useful behavior for the library
to expose. Nobody asked for it, so it's not currently there. But there is
nothing "broken" right now, and certainly nothing that's going to justify
another release of that codebase. This is more of a debate about 2.0, which
is being developed mostly by and for other people, and I'm not a dictator.

I personally believe strongly that if something breaks because of how
equals() is defined, that something is broken. I also think it's a mistake
to implement equals() in an inconsistent way across the system. Any
single/uniform definition of it is superior to that, including the current
default.

That said, if others think I'm wrong, I'll listen. But if you want to argue
that "semantic equivalence" should be the definition for NameID, then you'd
better be prepared to define it for the entire library or you're violating
what I see as a basic requirement.

-- Scott