Shibboleth Developers

[Walter Hoehn <>]

Tom,

I don't think the interest here is in "paving the way for widespread 
use" of an eduPerson attribute.

A clear need for an SP-local opaque and persistent identifier has been 
articulated over and over again by shibboleth users.  The current 
eduPersonTargetedID attribute was a first stab at providing this 
functionality.  This attribute as implemented in Shibboleth 1.2 has a 
number of problems, the largest of which is the lack of a clear 
migration path to SAML2 persistent name identifiers, which will be the 
most interoperable way of addressing the relevant use cases in the long 
term.

The current state of real world deployments, as I understand it, is 
that several organizations have plans to make heavy use of this 
attribute, but at most only a couple have actually moved it into 
production use.  Once an SP begins relying on this attribute, 
conversion to an incompatible format is a significant burden.  The 
proposed attribute format will allow SPs to use invariant identifiers 
for both SAML1 and SAML2.  So, the real question is do we go through 
the pain of conversion sooner, when we have fewer production 
deployments... or put it off until later, when the impact is even 
greater.

-Walter


On Apr 19, 2005, at 4:30 PM, Scott Cantor wrote:
> > 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.

Attachment: smime.p7s
Description: S/MIME cryptographic signature