persistent-id as an attribute

[Cantor, Scott]

> My hope is that any SPs we have vended eduPersonTargetedId to that are
> actually using it could just be replaced with a persistent Subject
> NameID. The concern is identifying them ahead of upgrade.

I think you'll find that to be the case the majority of the time. As far as identifying them goes, that's the beauty of no back channel, testing is always possible unilaterally.

> This would be to use the old ComputedId Dataconnector to generate an
> attribute to be used by newer CustomNameIDGenerators?

Computed or Stored, I'm just saying there's no need to generate it in two places if you need it in both, just layer a simple NameID generator on the value already coming out of the resolver to get it into a NameID. I'm doing that anyway because the standard way to do this now is a the pairwise-id Attribute.

The resolver connectors are not being deprecated. The weird AttributeEncoders are the only ones on the potential chopping block and they're probably not going to be yanked, just left undocumented.

-- Scott