During January and February 2014, we’ve met with a number of different e-infrastructures. Based on those meetings I’ve summarised what appears to be a common user journey in the headings below; at each stage I’ve noted where it seems to me that there may be common features that the Working Group might consider for further study. These ideas were presented at the e-Infrastructure Project Directors' Group and at our March 2014 Working Group meeting: slides are attached.

1. Application: the user applies to use an e-infrastructure

Each e-infrastructure appears likely to have its own policy on who may use it, and under what conditions. It seems unlikely that the policies for different e-infrastructures will have the same content but there may be benefits in them having the same structure. This might help users identify which e-infrastructures are most likely to suit their application, and also help infrastructure operators to identify similar systems with which there might be opportunities to collaborate.

2. Identity Linking: successful applicants provide, or are issued with, an online identity

Many infrastructures seem to share a desire to delegate the management and validation of user credentials to another organisation. Federated authentication schemes already exist whereby users in educational organisations can use their home usernames and passwords to authenticate for network access at other sites (eduroam) and for web-based services (UK Access Management Federation); Janet is currently piloting a new standards-based federation technology, Moonshot, which aims to bring similar benefits to a wider range of protocols. Both the Access Management Federation and Moonshot allow service providers to maintain a separate account for each user, with access to that account being granted on the basis of authentication provided by the user’s employer or place of study.

Using federated authentication would require e-infrastructure providers to agree with education organisations the technologies that will be used to securely exchange authentication decisions as well as policies on questions such as credential strength, revocation and the enforcement of infrastructure policies. It seems likely that many infrastructures will share similar requirements in these areas, so a common bundle (or bundles) of authentication policies and technologies could make authentication delegation much simpler.

3. Group Management: applicants identify those other users with whom they wish to collaborate

E-infrastructure collaboration groups appear to be based around research projects, so the membership of each group is most likely to be managed by a principal investigator or equivalent. Current e-infrastructures appear to provide their own group management systems, either as software interfaces that PIs can use or by an exchange of e-mails. These systems may also include the ability to invite other users, known to the PI, to link their own identities to accounts on the infrastructure service. The group management system might also be a natural place to manage users whose home organisation is not part of the authentication federation, either by issuing local credentials or by linking to other authentication providers such as social networks or research services (e.g. Umbrella). This may be particularly relevant to e-infrastructures offered to citizen scientists who may have no organisation able to agree to a policy on their behalf.

Group management appears to be a common requirement, where at least an exchange of experience and expertise could be useful. This might extend to identifying a common specification or even common software. Some access management federations provide standalone group management services that allow groups to be managed and their membership exported to a number of different service providers. This does not appear to be an immediate requirement for e-infrastructures, but benefits and costs of this approach might be worth reviewing.

4. Service Use

The data and services available through e-infrastructures are subject to a wide range of policies: some datasets may be usable without restriction while others will be subject to strict legal, ethical or commercial rules. If there is commonality between these, it seems more likely to be within research disciplines than between e-infrastructures.

Some aspects of service provision do seem to be common to multiple infrastructures, including secure operations (probably at a number of different security levels) and workflow functions that allow a user to request a sequence of operations be applied to their data, perhaps across different e-infrastructure components.