IdPv3 and generating persistent NameID

[Cantor, Scott]

On 5/1/15, 11:12 AM, "Sara Hopkins" <sara.hopkins at ed.ac.uk> wrote:
>
>> 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?

No, it's more or less similar to V2, you have metadata from the SP, you have the SP requesting a Format in a NameIDPolicy element in its request, and you have the nameIDFormatPrecedence relying party property.

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

It's not really relevant to the question of why the IdP will include a particular Format in the assertion Subject. That's basically identical in both versions.

The impact of the deprecation on functionality is what I mentioned to Kaspar, there's no non-deprecated way to send this construct as an *Attribute* value. The main use case for that is SAML 1 (since there's no way to send it in the Subject in SAML 1). I realize there are people using it with SAML 2, but that was never necessary.

The point being that because that's actually a feature difference as opposed to "it works the same but is configured differently", actually removing those deprecated AttributeEncoders will be a longer conversation, not something we do on a whim. But they're still deprecated. By which I mean, their use shouldn't be encouraged in any default material, and any existing use should be looked at as a thing to remediate.

>eduPersonTargetedID/urn:oid:1.3.6.1.4.1.5923.1.1.1.10 is a core UK 
>federation attribute,

It's not meant to be an attribute though except in SAML 1, which ought to be fading out of use anyway.

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

For use as a NameID, you use the new generators, which work exactly the same way. To support it as an Attribute, you have to use the deprecated feature.

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

The latter.

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

There's no current proposal to remove it, but deprecating it now is a signal that we want to.

-- Scott