Shibboleth Developers

["RL 'Bob' Morgan" <>]

The point of the initial question in this thread was to identify the 
requirements for a new implementation of ePTID to replace (or supplement) 
the current on-the-fly implementation that we know people are having 
trouble with.

Jim Fox wrote one for UW use, and documents it at:

  http://staff.washington.edu/fox/notes/tgtid.shtml

So the real question for ePTID durability is that, given that they in 
general are persistent but there are edge cases where they might be 
changed by the IdP (presumably based on user/SP choice), are there any 
implications for that on how they're implemented?  My observation is that 
in person registry space (including so-called "registry ids" that IMHO are 
just instances of ePTIDs that happen to be used globally by the campus 
enterprise) we find a general need to maintain "prior" forms of all 
identifiers for various purposes.  This is because they do change, and 
it's useful to keep the old ones around (not necessarily forever) for help 
in problem resolution, searching etc.  So I suggest that a really good 
ePTID database would support this.

If we thought this happened a lot, we might think that there needs to be a 
UI at the IdP for an IdP user to pick an SP and say "forget my current 
ePTID with this one".  I don't think we need this, though.  I think the 
"de-federation" support that Scott mentions in SAML 2 would be initiated 
by UI at the SP (but I could be wrong about that).

 - RL "Bob"