Shibboleth plan for 'unspecified' type nameID

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Shibboleth plan for 'unspecified' type nameID

Zico
Hello, 

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

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. 

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. 

--
Best,
Zico

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Shibboleth plan for 'unspecified' type nameID

Peter Schober
* Zico <[hidden email]> [2018-07-12 18:06]:
> 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.

What is it you're missing? The recommendation from this community was
to avoid specifically asking for the "unspecified" format unless
you're OK with getting anyting at all.
I.e., if you have expectations about its content don't use unspecified.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: Shibboleth plan for 'unspecified' type nameID

Cantor, Scott E.
In reply to this post by Zico
> 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 [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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 [hidden email]


--
Best,
Zico

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]