SAML2 attribute names breaking standards

[Peter Schober]

* Michael A Grady <mgrady at unicon.net> [2013-11-22 21:54]:
> And I'm going to be slightly contentious, because I also work a fair
> amount on the side of the vendors/cloud service providers, and say
> that until the latest draft of eduPerson is official, eduPerson is
> missing a key defined identifier -- eduPersonUniqueID. Without that,
> there are use cases where neither ePPN or eduPersonTargetedID are
> sufficient. Once that exists, you have a stronger argument.

That would imply the vendor insists on "basic" or "undefined" *name*
*formats* because it wants to use a "better" *attribute*, one not
available from, say, eduPerson. (Which would be bogus, of course.)
Or you didn't mean to say that, then poining out what the eduPerson
object class misses it's just plain off topic wrt name formats.

On that side note: Personally I don't have anything against defining
new eduPerson attributs (and I pointed out SWITCH's long-standing use
of pretty much the same thing as eduPersonUniqueId) but also agree
with the arguments being brought forward regarding the introduction of
yet another identifier attribute. (Mainly that we have several
already and that discussions about what their properties are --
spec-wise and what is to be expected in the real world -- and which
one to chose already take up a large chunk of the time I spend doing
such integrations.
But eduPerson discussions belong on MACE-Dir lists, not Shibboleth.
-peter