By “non-published” material in the repository, we mean material that is only accessible to an individual or to an identified group of people. Examples are: (i) “work in progress”, where the author may only wish a small group of users to have access; (ii) research data that is stored in a repository while it is still being worked with, and where access is restricted to the members of the research group; (iii) research funding bodies that want access to project outputs for management and reporting purposes; (iv) external examiners requiring access to material in a local repository; (v) e-portfolio use cases, where an external assessor needs to access repository material (e.g. for a job application). In all these examples the access may cross institutional boundaries.
In examples (iii)-(v), a number of external individuals are granted access to certain resources held in the repository. These individuals are in general all independent of one another. Assuming that their home institutions belong to the federation, and that they are employed by the hosting institution on a relatively regular basis, the simplest solution appears to be an eduPersonEntitlement provided by their home IdPs.
The situation in examples (i) and (ii) is more complex; here, a repository forms (part of) a working environment, or “virtual research environment”. Some people may deny repositories that such a role is appropriate; however, such systems are being developed and are likely to become more common in the future. A more specific example is collaborative word processing, such as Scribd and GoogleDocs; although the outputs are not at present stored in repositories, this may change – indeed, a JISC-funded project is already doing this for GoogleDocs . The research data scenario is common in grid environments, which are frequently used to manage data from large scientific projects. In some cases different data environments are used in parallel for different roles (raw data, derived data, associated material, backup, etc.), for example in the LHC model.
Role-based access management, and delegation rights for access management, are of relevance here. Much technical work in this area has been done – for example, the PERMIS and DyVOSE (Dynamic Virtual Organisations for e-Science Education) projects. This approach requires some actor in the scenario to look after the policies –
in the “research group” scenarios (examples (i)-(ii) above) this might be the PI, in the “assessment” scenarios (examples (iii)-(v)) this might be the head of assessment.
A closely related issue is group management, and “virtual organisations”, in which access rights are given to groups of individuals (e.g. in VREs). In principle, groups could be defined by using eduPersonEntitlement to encode this information, but this would require the IdPs to be involved in group management, by setting up bilateral agreements between the SP and each of the IdPs. This is undesirable for a number of reasons: it would require coordination of the IdPs, which are external to the group, and whose managers may not appreciate the additional work; it would require the group to place significant trust in the IdPs, who would have full power to add the entitlement to individuals in their organisation. Another approach is to
An alternative is a system like VOMS (Virtual Organisation Management System), which is being used in the SARoNGS (Shibboleth Access to Resources on the NGS) project for grid access management . However, this is a heavyweight mechanism that may not be flexible enough to support all these use cases. It takes a significant amount of work to set up groups in this way (perhaps a week to set up a new VO). Although this is not too onerous for long-term research projects, in many cases it is necessary to set up ad hoc groups quickly from the bottom up. The VPMAN project has made some progress here, by bridging role-based privileges and VOMS, and this may be integrated into SARoNGS. The GFIV0 project is addressing these issues using Grouper. Note: this also relevant to Scenario 10.
Commision some early adopter projects piloting approaches to collaborative work in IRs. These projects should involve real users (teachers, learners and researchers) and should use existing collaborative tools. The projects could look either at collaborative authoring (e.g. of documents) or at collaborative work on research data.
In the case of research data, important issues to address are: (i) the granularity of the access decisions that need to be made; (ii) the need for lightweight group/VO management. These projects should build on previous work such as Grouper and GFIV0.
It would also be useful to produce a summary of relevant use cases and technologies, and to produce a synthesis.
Voting on Ideas
Vote for your favorite ideas by clicking on the up arrow.To undo an upvote, simply click the arrow again. This second click removes your vote.