(We have cases where we'd rather start using those now, the
alternative being to ask our member IDPs to add support for
essentially deprecated persistent NameIDs wrapped in essentially
deprecated eduPersonTargetedId attributes -- something I can't get
myself to do in 2018ce.)
So I'd would like to write that documentation it in a way that once
these attributes may be added to the examples shipped with the new IDP
releases that their internal attribute id will match what I've
documented, so that attribute filters would continue to work, etc.
So any idea or preference how you'd call these in the config?
I note 3.3.3 has "eduPersonUniqueId" in its example
intercept/consent-intercept-config.xml references an (otherwise
unused, AFAICT) "persistentId" attribute.
So following these two examples I'm assuming
"subjectId" and "pairwiseId" would be the most likely internal
attribute id for those two new standard attributes?
To unsubscribe from this list send an email to [hidden email]
> So any idea or preference how you'd call these in the config?
As Rod said, I really haven't dug into it yet to add them, but we probably would follow pre-existing IdP patterns unless people think we should just copy the SP's conventions as a "fresh start" or something.
> So following these two examples I'm assuming
> "subjectId" and "pairwiseId" would be the most likely internal
> attribute id for those two new standard attributes?
From memory that would probably fit the IdP conventions, yes. If that sounds ok, I'd just suggest proposing them in the JIRA issue and then we can make sure to copy those in.