persistent-id as an attribute
Cantor, Scott
cantor.2 at osu.edu
Mon Nov 5 13:39:38 EST 2018
> It looks like this is deprecated and will be removed in V4 and was never really a
> recommended approach. We have enough SPs for whom we are vending this
> attribute that there is concern about just removing it.
If the membership decides that this is a feature that can't be removed, then it can communicate that when the time comes, but I deal with enough people claiming to know what SPs "require" that turn out to be wrong not to take anything like that at face value anymore. I can believe "a few" but I have a hard time imagining it's very many, particularly for a US university. I have never encountered one, FWIW. I didn’t even support a pairwise ID until last year. Simply saying "no" gets you a long way.
> Acknowledging that this is not recommended, is there any way to reproduce
> this as an attribute using modern syntax?
No, it's not a NameID.
If you have to produce the data in the resolver, use the original ComputedId or StoredId DataConnector(s) to do it, generate the NameID (if you even have to) using an attribute-sourced generator and comment out or delete the original persistent ID generator.
-- Scott
More information about the users
mailing list