Shibboleth Developers

[Ian Young <>]

Tom Scavo wrote:

> > I don't understand why you want to deprecate attribute
> > eduPersonTargetedID?

Scott Cantor replied:

> I don't, but I don't see a reason to use it much either (apart from non SSO
> use cases).

One practical issue would be related to services that provide different 
levels of functionality, such as optional personalisation, depending on 
whether a persistent identifier is available for the subject.

This isn't so much a problem at the SP side, where a persistent 
identifier may arrive as an attribute or as the authentication subject, 
and the differences can be resolved silently by the application code.

On the IdP side, at present such things are controlled by the ARP, which 
is purely a filtering mechanism.  Releasing or not releasing an ePTI 
would, if that were deprecated, become a *choice* of name identifier 
formats.  If we think the release filtering should be under the user's 
control, we'd presumably want that choice to be made by the user as 
well.  That has implications for tools like SHARPE (even just the name!) 
as well as user education.

> >  If the value of ePTID is identical to a
> > persistent identifier (for a given SP and principal), why not expose
> > both?  From the SP's point of view, attributes are (slightly) more
> > flexible than name identifiers, I think.  For instance, how do you
> > pass a name identifier in an HTTP header?
>
> We do this now. You can map based on the Format string to any header you
> want, or filter based on site, as with an attribute. The flexibility in the
> SP that's missing is the handling of the serialization to a string. Once
> that's added/unified, they should be roughly the same. It's a matter of
> code, not any special magic attributes have.

This sounded really interesting, so I tried to figure out how it worked. 
 I couldn't find any documentation or glean anything from the 1.3 SP 
configuration schema.  Can you give an example?

        -- Ian