Shibboleth plan for 'unspecified' type nameID

[Cantor, Scott]

> I have a quick question.. what's the future plan of you guys for supporting
> 'unspecified' type nameID format?

We support it as much as it's possible to support it without violating the bounds of common sense.

> I have done some overriding to support 'unspecified type' nameID format (
> thanks to your doc ) for couple of my customers because their SP made it a
> 'mandatory' item.

I'm happy to learn which SP that might be and either prove them wrong through personal experience, or document that it exists. Enumerating them is useful (as is shaming them).

To be clear, "I don't care" is a common cloud perspective, no matter how misguided it is. That's not the same as "requiring unspecified", and virtually all cases where people claim it's required are the former, not the latter.
 
> Pardon me if I miss any doc/wiki on 'future plan of Shibboleth for unspecified
> type nameID format' but if anyone of you can just share a hint, will be helpful
> for me to request my customer to move for a proper nameID format ( i.e.
> emailAddress ) instead of unspecified type.

There is no reason to use it. It should never have been in the standard. Would you define an LDAP attribute called "unspecified"? Of course not. It was, plainly, a mistake and I'm not far from filing an errata on it, honestly, because of the outrageous amount of time it costs everybody, particularly me.

If you want to know what we think in general, NameIDs should be omitted, or transient, only and never used for persistent identification of users. Our proposed approach is now drafted [1] and waiting (and waiting and waiting) for final approval.

-- Scott

[1] https://wiki.oasis-open.org/security/SAMLSubjectIDAttr