Shibboleth Developers

["Scott Cantor" <>]

> The profile seems to be "best practice" for attribute handling, said 
> best practice having come from Shibboleth in the field. It's a snapshot 
> of part of the Shibboleth profile? (duck!)

I am not going to characterize this as "best practice". Personally, I think
readable names and the Scope attribute approach have their advantages, but I
also know that others don't like them. I absolutely dislike
AttributeNamespace, so I'm going to argue that picking *any* value and
ignoring it is better than using it for something. So in that vein, I will
defend the use of a Shibboleth URN is simply being an example of how to not
use the field.

But what this is is "the current practice" for use of these attributes in
the I2MI community (as RLBob just explained").

As I alluded to, this is actually the cleanest set of rules we can document.
There's at least one other piece on the wire that we discussed yesterday
(the current xsi:type the software uses to deal with an old XML parser bug).
That bug is gone now. The intent is for Shibboleth 1.3 to be "compliant"
both with the Shibboleth specs and with this profile. The fact that it will
support various other modes for compatbility with older versions of itself
will be documented, but not raised to the level of a profile that others
would have to implement to interoperate with the compliant versions of
Shibboleth.

> well, it's not really a problem per se. When I first came across it, I 
> was slightly surprised but you're correct in thinking along those 
> lines. I did think whether this was actually allowed. There are a load 
> of LDAP attributes not contained in the eduPerson spec but the move to 
> OID is a welcome one, IMHO.

Well, some people agree, some don't. The problem is that people (including
myself) have already deployed a number of installations that exchange the
older names. We can't just dump them. Aliasing things doesn't help because
the problem is knowing when to send old names to older installs that don't 
support the aliases. The burden on IdP admins to configure custom rules is
not justified simply to make a few URNs consistent.

> The profile is specific to eduPerson but eduPerson is just a subset of 
> many different LDAP schemas. Would it be possible to make the profile a 
> more wide ranging LDAP specific? Then it would provide a way for 
> federations to transmit any LDAP attribute, rather than just 
> eduPerson.

For SAML 1.1, I believe the language is intended to do that (for this
community) by grandfathering in the old stuff and alluding to a modified
version of the SAML 2.0 LDAP profile for anything else. The exception is
scoped attributes, but if people are up in arms over the XML syntax of
those, I think they need to step back a little, it simply doesn't matter
that much. It's also unlikely of course that any non-eduPerson attribute is
going to be "scoped" at this point.

But the profile is not intended to force the entire planet to do things this
way, it's for attributes profiled by this community.

> The logical way would be to separate eduPerson into it's own schema and 
> rely on the OID in SAML2 - is that the future? All the other non 
> eduPerson attributes that are contained in the eduPerson spec have 
> their own OIDs anyway. As well as those other LDAP attributes that 
> aren't in the eduPerson spec.

The proposal is that for 2.0, all the attributes profiled by the eduPerson
specification, whether they are in the objectclass or not, follow the same
conventions laid out by SAML 2.0. The exception is targetedID because it
doesn't have an LDAP directory syntax (at least not now). Therefore it can't
be addressed directly by the attribute profile in the SAML 2.0 spec.

> Of course, there are cases where IdPs are spitting out non LDAP 
> attributes - we have some here but another profile could be developed 
> for that. In fact, we'd be more than happy to do one.

All of us have done this. The question of whether to do a profile depends on
who you're interoperating with. This document doesn't dictate any rules to
those profiles. Naturally, having implemented this profile, those of us
using this software are predisposed to create profiles that resemble it.
That doesn't mean the software can't implement others. Naturally, the more
"out there" your attribute syntax gets, the more code you'll have to write.
That certainly applies to the targetedID proposal.

Where naming is concerned, anything goes. The software is intended to be
SAML compliant, which means that it recognizes that names have two parts and
both can be specified anywhere an attribute is identified.

You could think of the Shibboleth URN as a way for the software to let you
skip that and use a single unique name (whether it's an OID or not). It's
perfectly legal and possible for any SAML implementation to use it (though
it obviously wouldn't be built-in), so using it does not make your
attributes Shibboleth-specific, merely easier to reference by Shibboleth.

-- Scott