Shibboleth Developers

[Chad La Joie <>]

David L. Wasley wrote:
> Chad,
> -----
> At 7:48 AM -0400 on 8/1/05, Chad La Joie wrote:
>
> > 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.
> Which entity needs the audit trail - the IdP or the SP?  Or is the IdP 
> supposed to support the SP in this way?  Or ...?

I was just talking from an IdP standpoint.  I think an IdP owner needs 
to be able to resolve past ePTIDs to their owner.  It's the only way to 
bridge the IdP<->SP gap if you're trying to reconstruct past 
transactions.  The reasons for needing to do that are varied and some 
are ones we'd cringe at (e.g. FBI coming and knocking on your door 
looking for info about Person X).

> I think that any SP that cares what physical person is doing what should 
> ensure that they have a persistent representation of that person.  For 
> example, a permanent ID (not only never reassigned but that will always 
> be actively associated with the individual).  By the same token, I think 
> that one reason for a person to change ePTIDs occasionally is to break 
> that association, for whatever personal reason.  Thus I don't like the 
> idea that the IdP might try to keep a complete dossier of ePTIDs used by 
> each IdP Subject.
>
> Take the case of a researcher using on-line licensed resources with 
> "sensitive" information.  S/he might use ePTIDs to dissociate searches 
> to avoid sequential association of one search session with a subsequent 
> one.  S/he wants and expects anonymity.

I think the expectations for anonymity need to be set correctly.  At 
least for me, I never viewed the ePTID as a way for a person to hide who 
they were and what they were doing from their own home organization, so 
the dossier of ePTIDs by the IdP would be moot in that case.  I DO think 
the ePTID provides anonymity in the way you describe on the service 
provider side.  If you allow the user to de-federate an ID and recreate 
it for each search they do then you do get the anonymity you're talking 
about.  As a side note, if that's what you want what you should really 
do is just not create/release you ePTID and just make the SP use the 
handle since you're basically doing the same thing (assuming the SP can 
support methods).

> I think the burden of "audit trail" belongs on the service provider (and 
> in a sense the IdP is also a SP to its users).  If there is a reason to 
> know a particular person's actions, and the person is aware of that 
> need, then a changeable ePTID is not an appropriate identifier to use 
> with that SP.

I guess I see the need for audit trails on both sides so that when I go 
to an SP, trying to diagnose a problem a user was having (but now 
they've changed their ePTID because they had the option and surely 
wildly clicking all available options will fix the problem) I want to be 
able to say, "User <insert ePTID> tried to log in and got this error.  Why?"

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