Shibboleth plan for 'unspecified' type nameID

[Zico]

Thanks, Scott.
Seems like my customer rejected SP's requirement of 'unspecified' and
hopefully SP will configure their configurations for better type of
attributes.

On Thu, Jul 12, 2018 at 11:43 AM Cantor, Scott <cantor.2 at osu.edu> wrote:

> > 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
>
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>


-- 
Best,
Zico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20180719/719f422f/attachment.html>