computedID in idpv3

[NATHAN KLINGENSTEIN]

> In v3 this data connector is deprecated?

It nearly got deprecated in v2.  There were long, running conversations about whether it should ever be used or not.  I personally thought it was usable if inferior to a database-backed approach and that the feature was crucial enough that its use should have been promoted.  Others disagreed, mostly on the basis of the disaster movie you describe.  I can easily see both perspectives, personally.

> But given the caveat that it may be removed in a future version, is there something else I should be doing or working on migrating towards?

StoredID is arguably better in basically all cases.

> I have a number of SP's who are using eduPersonTargetedID as a unique identifier so things would break somewhat horribly if it just suddenly started returning different values one day 8-/.

You may be in luck, because this is one of the degrees of freedom that keeping these values in a database grants you.

"A default feature of the stored strategy is that it uses the computed strategy to produce the initial identifier for each subject, to help with migration. If you don't need that to happen, you can set the idp.persistentId.computed property to an empty value and ignore that feature entirely."

https://wiki.shibboleth.net/confluence/display/IDP30/PersistentNameIDGenerationConfiguration#PersistentNameIDGenerationConfiguration-StoredIDs