COmanage Developers List

[Emily Eisbruch <>]

COmanage Working Group Minutes

Monday, April 18, 2011

Internet2 Spring Member Meeting

Note: Thank you to Dean Woodbeck for preparing these minutes.

----------

VO Activity

Scott Koranda (LIGO) discussed his experience from a science VO perspective. VOs will know little about identity management and there was a learning curve about onboarding and other IdM concepts. 

From a technical point of view, LIGO can now contribute back to the data model and API. LIGO has two projects moving forward to leverage COmanage directly. One is MyLIGO and the other is related to LIGO’s role as an identity provider of last resort for some projects (for which the VO will leverage COmanage).

Heather also mentioned discussions with LIGO – spending a lot of time talking about how people enroll, how they come into the VO, and how to assign attributes. 

Heather reported on discussions with both Project Bamboo and GENI. As a general comment, it seems that the more technical the VO, the more the interest in the identity management piece. Less technical VOs seem more concerned about the applications and how the collaboration will work, and less about managing the people portion. Some want a portal and some want a platform. There is a lot of data in the COmanage wiki at https://spaces.internet2.edu/display/COmanage/Home

----------

Intake and Enrollment

Benn Oshrin reported on his work mapping the business processes to technical onCMPboarding. He has developed the flows for the three methods people could use to get from their home organization to the CMP. The graphics for these flows are available on the COmanage wiki at:

https://spaces.internet2.edu/display/COmanage/CMP+Identity+Intake+and+CO+Enrollment

The lack of a common set of attributes makes it challenging – we have to ask each institution, one by one. 

----------

Default Attribute Set

Nick Roy said the the CIC has been working on a common set of attributes, as well as a default attribute release policy that the institutions would agree to and release this set of attributes to one-another. He mentioned that it would be beneficial if InCommon recommended a common set of attributes, but understanding that policy development is still very sticky.

There was a question about how applications would be identified as qualifying for the default set of attributes. It is appealing to have a knob to turn and release the set to “those guys,” but who decides who “those guys” are? 

Nick responded that there has been discussion about asking InCommon to include something in the metadata. But on the policy level, there would be a need to define the requirements an application would need to meet to qualify to receive this default attribute set.

Beyond that, there is a range of SPs in the federation, some of which do not need any personally identifiable information (PII) (like some library services), to some that do (like COmanage). Is there a need for some sort of policing function (perhaps by the federation) to make sure that some SPs don’t ask for PII, but allow the release for those with a legitimate need. One model may be to have, say, five ARPs, then categorizing the SPs and identifying which ARP is appropriate. 

In discussions with VOs, there is a concern about the process of negotiating the release of attributes with participating institutions. VOs typically are not staffed to do this and the process quickly become too time consuming. 

Another issue is one VO federating with another VO – what is the taxonomy regarding attribute exchange?

----------

Roadmap

1. Demo/proof of concept releases between now and the 2011 Fall Member Meeting

2. Early adopter release sometime between the 2011 Fall Member Meeting and the 2012 Spring Member Meeting

3. General Release in time for the 2012 Spring Member Meeting

The plan is to cover a lot of use cases, while ensuring ease of use for VOs.

The project is not working on domesticating applications, but there are others who are. Some institutions reported on applications they are working to domesticate (including REDCap, a home-grown student portfolio application, Fedora, and Redmine. SURFnet has a list of applications that are domesticated or are in process.

https://wiki.surfnetlabs.nl/display/domestication/Overview

Emily Eisbruch, Technology Transfer Analyst

Internet2

office: +1-734-352-4996 | mobile +1-734-730-5749

Visit our website: www.internet2.edu
Follow us on Twitter: www.twitter.com/internet2
Become a Fan on Facebook: www.internet2.edu/facebook