Graham Klyne, Research Technology Service Oxford University Computing Services
Rather than respond to the rest of your message in blow-by-blow fashion, I'll
sketch a couple of additional use-cases based on my perception of likely
researcher needs (based in part on my work with researchers in the zoology
department here in Oxford). The common thread in both these use-cases is that
the Sakai system administrator does not have a priori knowledge of all the users
of the system. Both of these use-cases are are modelled loosely on projects
that I'm aware of, so I don't believe they are too contrived.
For the purposes of discussion, both of these scenarios presume a Shibboleth
deployment that can supply (a) an authenticated id (not necessarily personally
identifying; e.g. my Oxford id has the form "zool1234"), (b) an attribute that
indicates status in the university (student/staff/academic/etc), and (c)
attributes that enumerate projects with which the user is associated, (d)
various other things. (We don't currently have (c); I'm using it as an
illustrative idea).
1. Small research project with external institutional collaboration
Background: institution 'A' is running a research project, with occasional
collaboration from researchers at a number of other institutions. Core project
team at institute 'A' is 3 people, with occasional inputs from up to 10
collaborating institutes.
Use-case: All institutions are members of a Shibboleth federation as outlined
above. Institute 'A' maintains a Sakai platform for collaboration. The Sakai
administrator knows the institutes with whom collaboration is planned, but does
not know exactly who at each institute will be participating. An administrator
at each of the collaborating institutes can designate collaborators by having
the project added to their list of projects returned by Shibboleth.
2. Multi-centre research project.
Background: 4 institutions are collaborating on a project. 3-6 people from
each institution are regular participants, and there may be other occasional
participants. Each institution leads one or more work packages within the
project, but all institutions contribute moire or less to all work packages.
Use-case: each institution runs a Sakai instance to manage information about
project elements that they lead, or to provide facilities of particular
relevance to their local researchers. Each institute knows who from the local
institute is working on the project, but not necessarily about those from
collaborating institutes. All institutions are members of a Shibboleth
federation as outlined above. Administrators at each institute can designate
participating researchers by appropriate additions to their profile as exposed
by Shibboleth.
An underlying theme here is that in multi-centre collaborations, a Sakai system
does not in general know about every participating researcher, if only for
reasons of administrative convenience. If an institution needs to add a new
researcher to a project, the administration paths for doing so are shorter.
Similarly, if a researcher's authorization needs to be terminated due to
changing circumstances, their local institution is the body most likely to know
about this.
...
There's a third use-case which has its roots in a true scenario. Some years
ago, I worked for a company building email content filters, and one product we
developed had the purpose of blocking transmission of pornographic images. The
development of machine learning algorithms for this was subcontracted to a
university department, but based on a corpus of data gathered by the company.
Clearly, in such an environment, it was important to ensure that the data was
available only to suitable researchers (adult, of good character, etc.), and
also that the identity of the researchers concerned not be generally known.
3. Anonymous access to sensitive data
Background: a research project involving controlled access to sensitive data,
in which it is important to restrict access to the data to designated
researchers, and also that the identity of researchers with access to the data
is maintained confidential.
Use-case: The corpus of sensitive data is maintained by a Sakai system, with
access controls dependent on Shibboleth attributes. Researchers to whom access
is granted are designated by their local managers, but the identity of these
researchers is not to be disclosed outside of those institutes; specifically,
the Sakai system does not receive information capable of identifying them.
...
And now, yet another scenario occurs to me:
4. Zero-maintenance collaboration platform
Background: a small research project requires a server system that can be used
to maintain a shared information space, but does not have expertise or effort to
maintain or administer a complex system. (Many research projects in Zoology are
like this; the environment actually used in many cases is a bunch of Excel
files on a file server.)
Use-case: a preconfigured Sakai system (possibly a virtual machine "appliance"
system) is installed on a spare computer to provide a shared data space for a
small research project. Data is accessed using Web browsers on individual
researchers' machines. All members of the team are competent and trusted to
deal with the research data, but none are skilled or inclined to perform system
maintenance or administration. Access permission can be determined based on
membership of the appropriate research group as exposed by an institutional
Shibboleth system.
(I can imagine a system like this, capable of version-managing Excel
spreadsheets, might find real acceptance in "wet lab" research environments.)
