Shibboleth Developers

["Scott Cantor" <>]

> The thing that makes me uncomfortable is the requirement for a 
> Shibboleth URN for all attributes. givenName is nothing to do with 
> Shibboleth, so why should I have to use a shibboleth URN?

If you're talking about the AttributeNamespace, there's nothing we can do
about this. We long ago decided to insist on URI-based naming, and we had to
pick a value to use as an indicator. AttributeNamespace is a required, but
completely ill-defined attribute. It creates problems and the best of a bad
set of options was "pick one value and stick with it".

It happens to be a urn:mace:shibboleth URN. That doesn't matter. It doesn't
mean "shibboleth", it means the AttributeName is a URI.

Changing this now is simply not an option for us because the eduPerson
attributes have already been bound to these names and this software is in
use. What would you propose we do?

> So, whereas we've got rid of one hard coding scenario for SPs, 
> eduPersonTargetedID, we've introduced another - the requirement for 
> IdPs that talk to shibboleth SPs to use a shibboleth URN. Guanxi 
> IdP/SPs use whatever URN you want and I think this is the way 
> it should be.

There is no such requirement. The requirement is that we've already bound a
large set of attributes to this syntax. Changing this for no good reason is
not an option that I can see pursuing.

> Shibboleth (the implementation) is a filter that matches rules against 
> incoming attributes. You can specify whatever URN you like for an 
> attribute. Now it seems that is not allowed and you must use the 
> shibboleth URN.

Huh? You've lost me. There is no such requirement being imposed. This is
*not* a Shibboleth profile in any way. It is a SAML profile of the eduPerson
and related attributes.

> I welcome the decomposition and OID but I'd like some reassurance on 
> the URN that perhaps I'm reading this wrong way.

Completely.

-- Scott