Shibboleth Developers

[Tom Scavo <>]

On Mon, Sep 27, 2010 at 8:40 AM, Scott Cantor 
<>
 wrote:
>
>> - the fact that persistent name IDs need to be redundantly asserted as
>> attributes
>
> Not much we can do about it, other than hold the line where possible against
> using anything but transient and persistent. That limits the problems.

Yes, I was talking about SAML V2.0 persistent name ID. That needs to
be redundantly asserted as an attribute for consent to work, right?

>> Speaking of persistent identifiers, how does the SP ask for a
>> "persistent, non-reassigned identifier"? There are a number of
>> attributes that satisfy that requirement, so how does the SP encode
>> its requirement for one of them?
>
> Many services can't be convinced to care about the things we might think are
> important. If they're willing to live with OpenID, then we have to stop
> boiling the ocean to satisfy them.

I'm not sure what you mean. This is a real requirement articulated
clearly by Federation SPs (well, at least one Federation SP :)

> But if I was trying to address this within the constraints that exist, I'd
> list the possible identifier attributes as optional alternatives and just do
> the error checking at the application.

I don't think that helps much. A specific example is ePTID vs EPPN. If
an institution does not reassign EPPNs, the SP probably wouldn't care
which it receives. How does the SP communicate that to the IdP (short
of defining a new, abstract attribute)?

Tom