A discussion on the enrollment process for a Bamboo Workspace

• a workspace starts with a small group of researchers and their grad students and expands to add more people (more researchers, students) - the more skilled people are involved, the more text of appropriate quality to be processed by analytical tools will become available
• they may ask for a new workspace OR, more likely, they will ask to join an existing workspace
  • they will ask either the manager of the workspace they wish to join or ask a central authority (campus?) to create a new workspace
• expect to see both invitation as well as open registration; access to all material will be in part restricted by LoA of authN party, by affiliation
  • people coming in via an OpenID model will only have the most basic access to material; people coming in with a higher LoA will be able to receive and delegate more permissions
• researchers will to manage access within their workgroup, and may be able to create new workgroups
  • researchers will also expect to be able to delegate that authority to a TA or admin assistant
• Bamboo currently no use cases around reporting, at least not use reporting back to a granting agency
  • they do have individuals interested in reporting data, more from a sociological research point of view
• they will be building collection adapters to make data repositories like Google Books, commonly accessible by tools in the Bamboo Workspace
  • a different form of domestication, outside the scope of COmanage
• the Bamboo project is willing to require federated, higher LoA for access to material (though this may cause issues with the community - that will have to be resolved within Bamboo)
  *the biggest concern Bamboo has is about scale, particularly with the quantity of data and the distributed nature of the researchers; this is an HPC data analysis problem
  

Roles Examples

Other notes

1. If the invitation is sent to a gmail account and the person attempts to register with their gmail/openID identifier, what happens? Does Bamboo expect them to still be limited in what they can access because of where they are registering from?

• Yes. In some use cases, we will need to restrict access based on the mode of authentication used in the current session, irrespective of invitations, prior account-linking activity, etc. These cases will require proof of current affiliation with a trusted IdP, such as an InCommon university.
  

2. Do you expect it to be a common request from a scholar to have all students in his/her class to be automatically given access to the Workspace?

• No. This is not an LMS, it is a research environment. Some scholars will involve some of their students, some will involve all their students, some will involve none.
  

3. Will individuals listed as "faculty" be automatically granted any extra priv's when they come in to a workspace, or are all automatic privileges based on their LoA (federated ID versus social ID)?

• Currently our thinking is a variant of the latter – LoA plus the institutional owner of the IdP. That is, the IdP will be asserting affiliation with an institution that may itself be an affiliate of Project Bamboo. Moreover, the institutional affiliation may confer access privileges to remote content based on an institution's subscription access to a content provider's materials. The mechanics by which access policy would be applied, and whether by Bamboo or by the content owner, is a bit murky still. Not all institutions affiliated with Project Bamboo will be InCommon members, or even U.S. institutions; some may not run Shibboleth; so the question of how to trust an IdP from an institution that is part of Bamboo but not part of InCommon, etc., is not straightforward (or, at least, I don't understand how to solve the problem elegantly). It may be that the out-of-mainstream use cases will go unresolved for a while, if they are too thorny for Bamboo to resolve in a one-off way.
• There is one class of non-InCommon federated IdP usage scenarios for which there are solutions, or at least development projects working toward solutions. Many UK, European and Asian institutions belong to their own national SAML-based federations. For them, interfederation approaches being defined in the European EduGain project may point the way. I know there have been proofs of concept between European federations. Alternatively, it is possible to configure an SP with multiple metadata files (I believe). One metadata file could contain entity descriptors for non-InCommon IdPs whose members want to work within the Bamboo ecosystem.