IdPv3 and generating persistent NameID

[Sara Hopkins]

On 30/04/2015 21:07, Cantor, Scott wrote:

> If you're sending a persistentID, you want to use a source attribute
> that has no encoders attached to it so that it doesn't leak. I'll be
> changing the defaults to reflect that better. It's not ideal, but
> we'll see how it goes.

I understand; I read another thread about that. I deliberately left the
encoders there for testing purposes to help me verify easily that the
source attribute was being released.

> But as far as what's there, if it's a transient NameID, then nothing
> told it to use a non-default format. Put the format you want in the
> SPs metadata and it should switch.

OK. Is that the only way of overriding it?

I'm looking at this because I'm trying to understand the implications of
the ComputedIdConnector and StoredIdConnector having been deprecated in
favour of "an equivalent NameID "generator"".

https://wiki.shibboleth.net/confluence/display/IDP30/ComputedIdConnector
https://wiki.shibboleth.net/confluence/display/IDP30/StoredIdConnector

eduPersonTargetedID/urn:oid:1.3.6.1.4.1.5923.1.1.1.10 is a core UK 
federation attribute, it's used by many UK SPs to key to registration 
data; if we aren't supposed to use ComputedIdConnector or 
StoredIdConnector to generate it then I'm not sure what we should do 
instead. Can we use a NameID generator to generate it and release it as 
an attribute the way we have been doing, or will we have to look at 
moving to a persistent NameID instead?

(I know that ComputedIdConnector still works at present; it's working 
fine for me. I'm trying to understand implications for the future)

Cheers,

Sara
-- 
Sara Hopkins
Support Team
UK Access Management Federation for Education and Research
web:    http://www.ukfederation.org.uk/

The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.