Shibboleth Developers

["Spencer W. Thomas" <>]

Here's a "counter" use case:

JSTOR expects that its participating institutions (IdP's in this 
context) will generally have the capability to identify the individuals 
who are engaging in practices that violate the terms of the JSTOR 
license agreement. A specific example of such violation is downloading a 
complete issue of a journal. If we detect such activity, then we expect 
that we will have information that we can provide back to the 
institution, such that they can identify the individual and discourage 
them from repeating the prohibited activity. We do not expect that they 
will tell us who the individual is, just that they have taken steps to 
prevent that person from engaging in such activity in the future.

In the case of Shibboleth authentication, the information that we could 
provide back might be the ePTID (assuming there is no other personal 
information in the original SAML assertion). We would expect that the 
institution would keep a reasonable history of user<->ePTID associations 
so that they can (internally) identify the transgressor.

Actually, the license text does not explicitly say that the institution 
should be able to identify the transgressor. What it does say is the 
following:

   3.3 Licensee shall use all reasonable efforts to protect the Archive
   from any use that is not
   permitted under this Agreement, and shall notify JSTOR of any such
   use of which it learns or is notified.
   In the event of violation of the User Rules, Licensee agrees to
   consider the imposition of further
   restrictions on access to, and downloading and printing from, the
   Archive. JSTOR and Licensee shall from
   time to time consult on the establishment of further measures to
   inform Authorized Users of the availability
   of the Archive and of the User Rules.
   3.4 In the event of any unauthorized use of the Archive by an
   Authorized User, (a) JSTOR
   may suspend or terminate such Authorized User’s access to the
   Archive, (b) upon notice to Licensee
   except in exigent circumstances, JSTOR may suspend or terminate the
   access of the Internet Protocol
   (“IP”) address(es) from which such unauthorized use occurred, and/or
   (c) Licensee shall suspend or
   terminate such Authorized User’s access to the Archive upon JSTOR’s
   request.

Note the alternatives in paragraph 3.4. If the institution cannot "fix" 
the problem internally, we reserve the right to terminate access by IP 
address. If, as has been the case a few times, the IP address in 
question is a proxy server, a group of innocent users are also affected. 
So it's in the institution's interest to be able to identify the 
particular user and get them to stop.

The privacy concern can still be met, if we (both SP and IdP) share the 
minimal information necessary. In this case, we would say "we have noted 
actions in violation of our license by individual with ePTID X", without 
saying anything about what their activity was. The institution can 
identify the individual, but doesn't know what they were doing 
(exactly). We "know" what they were doing, but don't know who they are. 
Thus, the record of activity is never associated directly with the 
individual (unless the activity persists, and we need to take some legal 
action, I suppose.)

Taking the example a bit further, we might notice sequential downloads 
of articles, constituting in the aggregate several complete issues, from 
many ePTIDs but from the same institution. (or we might not. :-) We 
could send the list of ePTIDs to the institution and they could identify 
the individual. Taking it a bit too far, if a user changes the ePTID for 
a particular SP many times in a short time period, the IdP might suspect 
nefarious activity. (Big Brother is watching you.)

=S

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 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 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.
>
> David