Shibboleth Developers

["Spencer W. Thomas" <>]

As an SP, I would agree that the ePTID should not change unless the 
Principal desires it to do so.

Jim Fox wrote:

> Our different understanding is not whether an ePTID can ever change.
> The causes you mention are valid reasons to change an ePTID.
> However, absent some special agreement or action between the SP
> and IdP, I think an ePTID for a user to a particular SP has to be
> invariant, forever.
>
> Jim
>
>
> On Fri, 29 Jul 2005, Chad La Joie wrote:
>
> > Date: Fri, 29 Jul 2005 14:34:23 -0400
> > From: Chad La Joie 
> > <>
> > To: 
> >
> > Reply-To: 
> >
> > Subject: TargetedID Durability
> >
> > Myself, Jim Fox, and RL Bob have been having a discussion about 
> > targeted IDs (ePTIDs) and Bob suggested that we move it to the list 
> > here.
> >
> > Jim and Bob, correct me if I'm wrong, but I think the current crux of 
> > our discussion is around the durability of a ePTID.
> >
> > Here's how I understood them to work.  An ePTID was specific to a 
> > service provider for a given principal (and implicitly at a given 
> > security domain). These IDs persisted for some period of time. 
> > However, and here's were Jim and I disagree, they need not persist 
> > forever.  A principal MAY, via some mechanism either manual or 
> > programmatic, dump their current ePTID to a service and MAY, at some 
> > future point, get another, different, ePTID for that service 
> > (essentially resulting in a new account on the service provider 
> > side). As a side note, I know that the current Shibboleth support for 
> > ePTID always generates the same ID for a given principal/provider pair.
> >
> > Jim's view was that once you had an ePTID, you had it and it stuck 
> > with you for the lifetime of your account.
> >
> > My initial reason for thinking about dumping and recreating the ePTID 
> > was for privacy concerns (e.g. after so much interaction a user's 
> > identity might be compromised via profiling past interactions).  Bob 
> > pointed out a much less nefarious case where duplicate accounts that 
> > might exist for an individual are detected and need to be merged.
> >
> > Thoughts?  (Or corrections from Jim and Bob if I 
> > misunderstood/misrepresented your views.)
> > --
> > Chad La Joie             315Q St. Mary's Hall
> > Project Sentinel         202.687.0124