EPPN and eduPersonTargetedID

[Ken Weiss]

As usual, some really great responses from the community. Thanks!

1) Tom Scavo said, "To protect ourselves against reassignment (which is
important in our case), we bind the ePPN to the user's mobile device." I
assume by 'mobile device' you mean a single-use password token, like a
SecurID? You're not talking about a phone, are you? And, since you are
concerned about reassignment, I assume you must be using EPPN as a key for
something. What do you do when an individual's EPPN changes? Do you
consider them a new user? Do you make any effort to re-associate them with
data stored under their previous EPPN? If so, how do you connect the old
identity to the new one?

2) Eric Goodman: Yes, I encountered this issue within the UC system. UC
Merced's IDP returns the authenticated user's email address as the EPPN.
So, whenever the email address changes, so does the EPPN. Our application
stores datasets for the user, and (currently) uses the EPPN as the primary
key to associate users with their datasets. So if the EPPN changes, any
datasets stored under the old EPPN will become orphans. John Kamminga at
Merced offered the EPTID as a persistent alternative, but as far as I
know, Merced is the only campus that delivers EPTID. I do think that some
coordination among the UC IDPs would be useful here, and your survey is
probably a good idea. I don't expect to arrive at an attribute that
identifies an individual if they move from one campus to another, but it
would be nice to have  a single attribute we can all rely on to remain
consistent and unique as long as the individual remains at a given campus.
If that value can be persistent across multiple stints at the same campus,
that would be even better.

Those last two sentences apply more generally than just within the
University of California system. It would be nice if every institution
that's part of the InCommon federation agreed on an identifying attribute
and assured that the value for that attribute would be stable for the
duration of an individual's association with the institution and never
re-assigned to a different individual. I thought that was EPPN, but
clearly, I thought wrong.

--Ken




------------------------------------------------------------
Ken Weiss                                 ken.weiss at ucop.edu
UC Office of the President              510-587-6311 (office)
California Digital Library              916-905-6933 (mobile)
UC Curation Center
415 20th Street, 4th Floor
Oakland, CA 94612






On 8/29/14 4:46 PM, "Eric Goodman" <Eric.Goodman at ucop.edu> wrote:

>Fair enough on all points.
>
>May still merit a survey though... :)
>
>--- Eric
>
>-----Original Message-----
>From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net]
>On Behalf Of Cantor, Scott
>Sent: Friday, August 29, 2014 4:40 PM
>To: Shib Users
>Subject: Re: EPPN and eduPersonTargetedID
>
>On 8/29/14, 7:32 PM, "Eric Goodman" <Eric.Goodman at ucop.edu> wrote:
>>
>>Within the UC System, I know that at least some of the IdPs generate
>>ePTIDs based on a dynamic hash of some attribute and the SP name. What
>>that means is that if the "some attribute" changes then the presumption
>>of persistence -- and possibly non-reassignability -- is lost.
>
>If you violate non-reassignment, you are grossly violating the standard.
>That should not be something SPs give any consideration to in their
>designs, particularly given that most of them don't even address the fact
>that EPPN doesn't have this property.
>
>>[For longtime readers, this post is basically my ongoing "ForceAuthn
>>issues" commentary translated to ePTID values... :)]
>
>There's no gray here though, the spec is 100% clear and explicit on it.
>This is why supporting persistent IDs is a very deliberate decision and
>is not an out of the box feature, and thus also much less widely deployed
>than simpler username attributes.
>
>-- Scott
>
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net
>-- 
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net