IdPv3 and Hathitrust: how to resolve and release SAML

[Cantor, Scott]

> There's a misunderstanding here. All three of the identifiers
> mentioned above are *persistent* but that is not the same as
> *permanent*. In fact, NONE of them are defined to be permanent
> identifiers so the SP should not care based on that characteristic
> alone.

There is no such thing in any typical deployment as a permanent identifier, that's not a realistic requirement for most organizations. There's "more stable" and "less stable". Applications that want "more stable" are being perfectly reasonable, but supporting something for its own sake when you can't really supply the desired outcome is just doing a disservice.

I'm not saying not to do it, I'm saying sAMAccountName is  a red flag any time its mentioned. Doesn't have to be a bad choice (there's no specific definition for what's in it), it just often is a bad choice.

If the seed is cantor.2, then the stability of a persistentID based on that, and an EPPN of cantor.2 at osu.edu is identical (identically poor, that is). So the only win is the privacy gain, and while that's not nothing, there are too many services for which that lack of stability is not just a simple loss of search results. So it's not a good choice.

-- Scott