COmanage Developers List

[Tom Barton <>]

I spent part of the morning Chading, with two outcomes in particular. 
First, he wants to participate in the acamp in June because he believes 
that clarifying functional contracts for identity services is on 
Bamboo's critical path, but he wants someone else (maybe us) to solve 
that problem.

Second, he likes the prospect comanage offers as an appliance 
"platform". I'll not go into why and what exactly just now, but it leads 
me to the second particular outcome. We'll look at running a comanage 
instance at U Chicago, potentially to support a new program funded by 
our president to make it even easier for our faculty to do what they 
already do so much of - collaborate across disciplinary boundaries. 
Basically, the folks running this program have as one of its legs 
providing collaboration systems and technology, but they don't want to 
run systems, and the distributed IT heads have asked central IT to do it 
for them.

Two other takeaways of note for comanage, or at least my own thinking 
about comanage. First, we've (or at least I've) been thinking of 
comanage as integrating whole vertical apps. Maybe it should also supply 
its access management services to other services. Make it easy, for 
example, for people in a VRE to run their own php app on comanage-apache 
that outsources its access management to comanage.

Second, if people ever want to put valuable data on comanage, they'll 
want availability and fault-tolerance. One approach is to only put 
valuable stuff on instances supported by orgs with pockets deep enough 
to make them bullet-proof. Since those aren't the pockets that Humanists 
tend to have at their disposal, another approach could be to replicate 
data and/or services plus access information between comanage instances. 
Grouper anticipated this to an extent with its approach to naming 
things. But there's a whole lot to think about here in your idle time...

Tom

Tom Barton wrote:
> I'll freshen that strand of my conversations with Chad and with Steve 
> Masover.
>
> Although an appliance package is probably right for the early going, 
> Bamboo is looking for a services orientation and composability. Perhaps 
> the comanage roadmap should identify some point at which comanage will 
> sport WS interfaces supplying appropriate identity services to 
> integrated applications. Kinda like OSU BioMed had to make GridGrouper 
> out of grouper, only now we've got more going for us.
>
> Hmm, they also wrote Introduce to integrate apps with caGrid. Maybe 
> comanage should aim to do something like that, but working a bit further 
> up the stack?
>
> Maybe we can figure out what this means in June.
>
> Tom
>
> Ken Klingenstein wrote:
> > All,
> >   I has a call with Chris Mackie of Mellon this afternoon, who is 
> > trying to help a set of learned societies form their own collaboration 
> > environments that exploit "web 2.0" tools, without a dependency on 
> > stodgy academic orgs that don't touch this stuff or campuses that 
> > don't see the grant dollars in such groups.  Very early in their 
> > proposal process, looking for, it turns out, the comanage vm 
> > appliance, likely in a cloud environment. Two things that Chris 
> > pressed me on were the international interfederation peering, since 
> > these societies are very international, and provisioning capability 
> > inside comanage for accounts, in case a large number of users are not 
> > in federated institutions (though all are academics and will soon be 
> > in those federated clutches...). Chris will likely funnel these groups 
> > initially through Bamboo.
> >   The action item on this is for Tom to continue to touch base with 
> > Chad regularly, and for Chad to know such an appliance will be out 
> > there if there is a knock on his door...
> >         Ken