Shibboleth Developers

[Tom Scavo <>]

On 4/19/05, Scott Cantor 
<>
 wrote:
> > 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.

Shibboleth has its fingerprint on other portions of section 2, as
well.  For example, the Scope attribute is a Shib addition, isn't it? 
Consequently, I think it's fair to say that section 2 is an outline
for Shibboleth's use of eduPerson, and unfortunately that profile does
not appear to extend to SAML in general.

> 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?

Of course you have to support this namespace URI for backward
compatibility.  The only point I wanted to make (and I believethis is
what Alistair was saying, too) is that it's primarily a Shibboleth
thing and should be presented as such.

If you buy that, now you're faced with the question of how to sell
eduPerson to the SAML community at large, specifically SAML 1.x.  Now
if this isn't within the scope of what you're trying to do with this
profile, that's fine, you're done.  Otherwise there's more work to do.
;-)
 
> > 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 don't think so, and that's a major point of disagreement.  Section 2
is indeed a Shibboleth profile.  Even though Shibboleth isn't
mentioned (except indirectly in the namespace URI) you couldn't and
wouldn't want to use what's there as a SAML 1.x profile.  Something is
needed.

Tom