Shibboleth Developers

["Scott Cantor" <>]

> >>> There is no such requirement
> it says in the document:
> "...AttributeNamespace XML attribute in <saml:Attribute> elements
> MUST be set to urn:mace:shibboleth:1.0:attributeNamespace:uri..."
> 
> sorry, I completely misread that - I thought it said MUST!

Alistair, it says MUST only for these attributes. Not for all attributes
that could ever be defined in some other profile. This is a binding of
eduPerson (and some other attributes, I suppose) specifically. That's a
binding that is ultimately dictated by the group responsible for maintaining
that spec.

Now, the reaon why the URN is what it is is because the group responsible
for defining the profile originally was the group working on Shibboleth. At
the time, the URN was not conceived as an eduPerson-specific thing, but
rather as a way to encourage the practice of URI-based naming and emphasize
the problems with AttributeNamespace. So if you're asking me, should all
URI-named attributes use that AttributeNamespace, my answer would be "why
not?" You have to pick something.

But that doesn't make it a requirement.

> The proposal is for SAML profiles, not shibboleth ones when in fact the
> proposed standard urn value is to stop shibboleth breaking.

Sorry, that's simply not true. Shibboleth couldn't care less what the value
is for any given attribute. It defaults that value in a few spots for
brevity, but it can be overridden.

However, the interoperable use of eduPerson and some related attributes was
defined by this community in a specific way. You can disagree with it, but
that doesn't make this profile Shibboleth-specific. It is what it is, as I
keep saying. We did it. There's no going back except to needlessly break
existing applications exchanging these attributes.

Shibboleth itself doesn't care. You just have to go into every configuration
file that references these specific attributes and specify a new name for
things we already named. I don't see how that's justified.

> You say it's not shibboleth but changing the urn would break shibboleth.

That is false. It would break *deployments* of Shibboleth. There is a big
difference.

I'll be honest. There are some messy things the Shibboleth software is doing
right now. Things we'd much rather stop doing. And the really nasty ones
we're not making part of this profile and we want 1.3 to be able to strictly
support this profile.

But this is NOT one of them. It's just a URI. It doesn't mean anything.

> Why can't the URN be owner specific? e.g. for eDirectory attributes, why
> wouldn't you use urn:novell:edir or something, rather than shibboleth?

That leads to complete chaos. The AttributeNamespace has no meaning in SAML,
it is quite simply part of the name. The same attribute has a different name
based on what directory you get it from? How does that interoperate for
anybody? The name just needs to be unique, period.

> The namespace uri is Shibboleth, there's no getting away from that. If a
> non shibboleth implementation wants to transmit givenName, why would it
> even consider using a shibboleth uri?

Well, strictly speaking, you could argue that MACE-Dir (as the caretakers of
eduPerson) had no business assigning names to attributes in inetOrgPerson,
etc. But what were we supposed to do? We had to give them names, because we
wanted to use them. It only made sense to be consistent.

Again, the point of that URI is *not* to tie the attribute name to
Shibboleth, it's to try and convince people not to use AttributeNamespace.

Now, I wanted to get rid of it in SAML 2.0, but I wasn't fully successful.
But we did manage to get it turned into something else, NameFormat. And the
built-in NameFormat for URI-based names looks an awful lot like the
Shibboleth URN that you're concerned about. That's not an accident.

> Why even impose uris on attributes? SAML provides the buckets, the
> profiles provide the way you push the buckets about. What's in the buckets
> has nothing to do with shibboleth or even SAML for that matter.

THIS IS NOT A SHIBBOLETH SPEC.

I don't know how to convince you, but it's not. It is a set of rules for
mapping eduPerson and related LDAP attributes into SAML. It is based on the
way we did that in our deployments. It is not tied to our implementation of
SAML. It is compliant with SAML. It is legal. It may not be optimal, but
last I checked, not everything is.

We have to define the names and syntax for these attributes or deployments
that use them will not interoperate.

> If you want interop, I'll believe decomposition and oids but it smacks of
> too much control when you want to impose deprecated profile signatures on
> actual attributes.

So you'd break all of our deployments just to change a meaningless URI to
some other meaningless value?

Let me ask a question...is the real problem here that MACE-Dir assigned
names to attributes from object classes that aren't defined by us? Because
that's at least an argument I could understand.

-- Scott