EPPN Case Sensitivity?

[Cantor, Scott]

On 7/27/22, 10:47 AM, "users on behalf of Peter Smith" <users-bounces at shibboleth.net on behalf of Peter.Smith at UTSouthwestern.edu> wrote:

>    Our Shibboleth IDP in my experience has always lower-cased our EPPN
> attribute.  Are there any documented requirements for case sensitivity (or
> insensitivity) of EPPN for IDPs and for SPs?

Officially it's a case-insensitive attribute because at the time the determination was (unwisely) based on the LDAP string matching rules in the attribute type.

That was dumb because identifier matching should not be based on the search rules in a directory when it comes to treating a directory like a phone book, which is the historical origin of lots of this.

But that's what it was based on.

In parallel, it was thought (mistakenly) that case-sensitive identifiers were a better idea for ease of matching (it's very, very hard to correctly compare Unicode data case insensitively), but in practice the misuse of email addresses (and the botched way people compare *those*) has led to a realization that apps are broken, and the only safe thing to do is assume case insensitive matching.

So in a roundabout way we ended back where we started for different reasons.

>I believe EPPN is already required to be unique within an organization, so I
> don't see case sensitivity being useful at all.

These decisions aren't really about what's useful from an identifier assignment perpsective, but about how matching should, or will, be done by applications and databases. Which in turn has not been assessed correctly in a lot of cases historically (I'm guilty of a lot of those mistakes).

None of this changes the fact that if you allow non-ASCII, you make it effectively impractical to correctly compare case-insensive data. Which is why more recent work on identifiers was very much designed around controlling the character sets.

-- Scott