Shibboleth Developers

[Chad La Joie <>]

Here at GU we will need a good audit trail so we'll have to have the 
history of prior IDs kept.  Personally I would like to see them kept in 
the same database (as opposed to a file somewhere) that the ePTIDs are 
maintained in, just makes it easier, I think, to operate on them 
programmatically.

As far as leaving the de-federation support up to SP, I don't agree with 
that.  I think it would be great if they supported this, but in many 
cases it's not going to be in their best interest (i.e. money 
accumulation interest) to do so.  So it'd be nice for the home 
organization to maintain the right to allow it's users this function. 
Plus, from a support aspect, it's a lot easier to train your users to 
use your one tool than to train them how to use the distinct interface 
at each SP.  I also think it's would be more intuitive to a user to do 
it at the home organization, but that one is just sheer speculation on 
my part.

RL 'Bob' Morgan wrote:
> 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"

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