Shibboleth Developers

[Chad La Joie <>]

Right.  I wasn't suggesting that an ePTID would be changed capriciously, 
but instead just stating that I thought it COULD be changed.

Now depending on if you let users recreate an ePTID on request (and I'm 
not suggesting this is a good or bad idea), maybe then it appears 
capricious to an SP, but, in theory at least, the user had a reason for 
doing it.

A related question.  What if a user wished to not use a targeted ID and 
always wanted to use a random handle (hopefully understanding that they 
forgo things like maintained customizations between visits).  As a 
service, would you support something like that along side of ePTID support?

Spencer W. Thomas wrote:
> 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

--
Chad La Joie             315Q St. Mary's Hall
Project Sentinel         202.687.0124