Shibboleth Developers

At 3:39 PM -0400 7/29/05, Scott Cantor 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.
>
> The relevant property is non-reassignment. Under various circumstances the
> value may change, and of course it's useful to have mechanisms to inform the
> SP of that, as SAML 2 does. But a given value is never recycled.

I've heard a somewhat related use case from commercial info providers 
who work in the medical space -- a significant portion of their 
customer base moves from one site to another, especially during their 
early training days. When Jane moves from hospital A to hospital B, 
the SP would like Jane to be able to associate her new identity (as 
represented by whatever attributes the two hospitals are releasing) 
with her existing profile at the SP --

if it were only the SP that cared about this, perhaps I wouldn't be 
very concerned. But, the SP argues that in fact the doctors (or 
doctors in training) very much want this capability....

I can imagine a number of different ways to do  this -- is there a 
SAML-2 flow that supports this use case?