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