Attribute definition type for eduPersonTargetedID?
Peter Schober
peter.schober at univie.ac.at
Mon Jul 26 15:40:02 UTC 2021
* Cantor, Scott <cantor.2 at osu.edu> [2021-07-26 16:13]:
> On 7/26/21, 10:04 AM, "users on behalf of Wessel, Keith" <users-bounces at shibboleth.net on behalf of kwessel at illinois.edu> wrote:
>
> > I didn't actually say they only support eptid. I said they need it, and I say need because it's what they're
> > currently using as a unique identifier.
>
> Persistent ID is the *same* identifier. This is not about identifier
> migration, which is hard, it's just about syntax.
My point exactly when I raised this on the REFEDS list,
https://lists.refeds.org/sympa/arc/refeds/2021-07/msg00010.html
(cf. "no re-keying of subjects required")
> > We can certainly start migrating them to a new attribute, but that's obviously not a trivial process
>
> If the value is the same, it should be very trivial.
Well, given the case-folding issue I'd not recommend to carry forward
the existing (case-sensitive, base64-encoded) persistent NameID values
as pairwise-id values and instead move to (case-insensitive,
base32-encoded) different pairwise-id attribute values instead.
(I also don't believe that most SPs will be automating the migration
based on value comparison, esp. if there's no community consensus that
keeping the values "the same"[1] is the way to go and that such a
strategy is therefore worthwile for the SP to implement.)
-peter
[1] Minus case-folding them into a case-insensitive attribute and
hoping for the best.
More information about the users
mailing list