Handling a multi-value attribute question

[Mike Flynn]

Well, I asked them a while back if they were willing to change it and send a single value but they were not.  I do not have much leverage since these are customers and are paying us for our service.  We try to be as accommodating as possible since that is where our bread is buttered....


________________________________
 From: Peter Schober <peter.schober at univie.ac.at>
To: users at shibboleth.net 
Sent: Thursday, December 6, 2012 7:16 AM
Subject: Re: Handling a multi-value attribute question
 
* Michael A Grady <mgrady at unicon.net> [2012-12-06 16:08]:
> At Illinois (my institutional home for many years) givenName was a
> multi-valued attribute (certainly defined as such in the standard
> schema), but we also maintained a local attribute that was the
> singly valued "official first name". And, in the context of all of
> our attribute release for federated partners, we'd encode/release
> that local attribute as the value for the standard givenName field
> -- since no partners actually wanted the multi-valued field. Not
> sure why this particular school would insist on releasing the
> multi-valued form unless they don't have an easy source of a
> singly-valued field, but that is, of course, up to them.

I completely missed that of those 140 institutions only a single one
is causing this issue. Talking to them then becomes the most obvious
choice, I'd say.
My comments were under the assumption that a large percentage of those
140 institutions were doing this.

I also fully agree with Michael (and Scott) that givenName & sn are
just fine as they are and if the institution doesn't like the choice
you've made (first/last/random value) than they should be limiting the
SAML attributes to a single value, no matter what's in their local
systems,
-peter
--
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20121206/8bb4f7b2/attachment-0001.html