Subject Re: use of eduPersonEntitlement
From Niels van Dijk <niels.vandijk@xxxxxxxxxx>
Date Thu, 16 May 2013 00:46:21 +0200

On 05/15/2013 06:43 PM, Vries, Ale de (ELS-NYC) wrote:
> I copied those formats from an e-mail thread between our engineers and the SURFconext operator, so it may very well be that they are not properly stated. My SAML knowledge doesn't go that level of detail :)
>> -----Original Message-----
>> From: Peter Schober [mailto:peter.schober@xxxxxxxxxxxx]
>> Sent: Wednesday, May 15, 2013 12:39
>> To: REFeds
>> Subject: Re: [refeds] use of eduPersonEntitlement
>> * Vries, Ale de (ELS-NYC) <ale@xxxxxxxxxxxx> [2013-05-15 18:02]:
>>> Actually, in the specific case of SURFconext we encountered this issue
>>> not because of multiple values being released, but because of the same
>>> value being released in two different formats - urn:mace:<name> and
>>> urn:mace:<oid>. Our access management system choked on that - and it's
>>> currently being worked around by the SURFconext hub, IIRC.
>> Assuming SAML2 both of these forms would be wrong.
>> Assuming SAML1 second one would be wrong the first one might be correct
>> (depending on what <name> really is).
>> Maybe you're mistaken and the second one is in fact of the form
>> urn:oid:<oid> (which is fine and prederred for most SAML2 attributes in this
>> community)?
>> -peter

I can confirm that it is urn:mace:etc and urn:oid:etc.
No need to worry Peter, we did not invent another attribute schema ;)

And we are indeed patching so we also allow to *only* release either
urn:mace or urn:oid attributes towards an SP