persistent-id as an attribute

[James Oulman]

On 11/5/18 1:39 PM, Cantor, Scott wrote:
> 
> 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.
> 

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.

>> 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.
> 

Thanks, I was afraid of that.

> 
> 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.

This would be to use the old ComputedId Dataconnector to generate an 
attribute to be used by newer CustomNameIDGenerators? We are looking at 
moving away from the StoredID dataconnector to the computed strategy, 
keeping the same sourceAttribute, salt, etc., and remove our write 
dependence on a database.

Thanks for your help.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3980 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://shibboleth.net/pipermail/users/attachments/20181105/4aa45b1b/attachment.p7s>