Shibboleth Developers

["Scott Cantor" <>]

> It's a Shibboleth profile in the sense that a non-Shibboleth
> implementation would find the profile mostly unusable.

That's a completely unjustified statement. You may not like it, that's your
right, but it doesn't make it "unusable". If it's unusable, it would be
unusable for this SAML implementation as much as by anyone else. And it's
not. It works fine, with one exception that we are intentionally not making
part of the profile.

> Looking ahead
> to the SAML 2 attribute profile (in section 3), why would I want to
> incorporate any of the deprecated elements in section 2?

Because three years ago we had to decide what eduPerson looks like in SAML
1.1, so we did. Clearly you object, but to be frank about it, you weren't
here. It's not at all clear to me that there's anything fundamentally wrong
with it. Some of it I like, and some of it I don't.

But all of it is done, and deployed on at least a limited basis. If we start
breaking people's applications, they get understandably upset. That doesn't
play well if you're trying to send the message that you will support people.

> I wouldn't go that far either, but it lessens the urgency of having to
> deal with eduPersonTargetedID right now.  In fact, until
> eduPersonTargetedID is reconciled with the new SAML2 persistent name
> identifier, it would seem best to do nothing.

Unfortunately, I think the core team disagrees. It's appearing to us that we
have some people that may be moving forward with this attribute, and it's
the one specific case that we have deep enough concerns about that I believe
justifies forking the profile.

My proposal to use the <NameID> element is an attempt to reconcile it in one
step instead of creating yet another wire representation. The only thing
that would give me pause is if there were a likely profile from somewhere
else for putting any SAML name identifier in an attribute. But I haven't
heard of any, and I'm not really all that interested in one, most of the
other formats already map well to attributes directly.

> I'm not sure what all the hoopla is about.  If what you're trying to
> do is pave the way for more widespread use of eduPersonTargetedID,
> it's not clear why you want to do that right now.  You're just digging
> yourself deeper into a hole.

We don't "control" whether there's widespread use. We can't necessariily
stop it, and most of us are not comfortable saying outright not to use it.
The question is whether we have some consensus on a representation that
would span both profiles consistently. I don't see anything fundamentally
flawed about my proposal for that.

I can see your argument for leaving it alone or saying not to use it, but I
don't think we have that luxury.

-- Scott