*MACE-Dir Conference Call* April 16, 2001 *Attendees* Brett Didier - Pacific Northwest National Laboratories Todd Piket - MTU Keith Hazelton - Wisconsin Tom Jordan - Wisconsin Michael Gettes - Georgetown Bob Morgan - Washington Steven Carmody - Brown Tom Dopirak - CMU Dave Stevens - CMU David Wasley - UCOP Renee Frost - Michigan/Internet2 Ellen Vaughan - Internet2 Ken Klingenstein - Colorado/Internet2 Ben Chinowsky (scribe) - Internet2 *Discussion* - DoDHE - Michael: I've been concentrating on getting the server up -- Solaris 8 multiprocessing, issues with both version and multiprocessing; everything was working earlier today, but now it's not. Will be using basic web interface at first -- "not sexy". Anon.: did code problem moving to new box have to do with LDAP libraries not being thread-safe? Michael: yes. I think the Netscape libraries are thread-safe; I've hacked old perl so that it works, need to rewrite with new libraries Todd: [AI] Todd will help Michael with the code on the new DoDHE server. Michael: do you know Metamerge? Todd: no Michael: This is a great opportunity to learn -- we should talk Keith: I'm talking to the Metamerge CEO tomorrow. [AI] Keith will ask the Metamerge CEO about putting in an include function. Michael: e.g. data owners might want to define functions to clean up date Keith: brainstorming? Michael: much planning to do Ken: we've identified schools that want to be involved in a user-interface bake-off this fall -- classes will compete against each other to define searches Steven: these classes might be good pilot users of Shibboleth Ken, Michael: yes Keith: Michael, could you write up what work needs to be delegated? Michael: I have to deal with this bug first, but yes Keith: could you have something ready to start assigning tasks on the next MACE-Dir call? Michael: [AI] Michael will make a list of the DoDHE tasks that need to be delegated, aiming to get it sent out before the next call. - GridPerson - Brett: eduPerson and GridPerson seem to be very similar -- would like to see what we can do to merge them or combine them in some fashion -- pressure in Grid Forum to get this wrapped up -- authentication is a major concern -- would like to define an attribute for a generic security credential -- much in common between the different definitions Michael: what Grid-specific attributes have been added? Brett: really none -- we at PNNL have only added 3, and 2 (country and org name) are in line with eduPerson. we've also added city; generic security credential needs to be added also Michael: sounds like you've come up with a better definition of the standard object classes ... Brett: password was not included in your 1.0 -- only exception I saw compared to what we're doing Ken: do you want to store password in the directory? which one? Brett: some people may have a use for that, others may use PKI and not have a use for it Michael: we left it out so as not to get involved in authentication Keith: we're starting down the security rathole. the new thing we put in was EPPN -- is that not generic enough, or would you feel like you were in danger of overloading it? Brett: for completely generic, you'd need two attributes, one to hold the type and one to hold the credential. Keith: may be a philosophical difference -- Shibboleth-like approach in eduPerson vs. broader range of approaches in GridPerson Brett: sounds right. one of the problems in the Grid security working group is that there's no specific architecture in mind yet. "makes some of these jobs very difficult where you try to be everything to everyone" Steven: taking a practical approach -- only 1000 IDs, could be from anywhere, don't want to constrain what they could do, pre-dates Shibboleth. would be worthwhile to invest some time and energy into looking at how Grid infrastructure might evolve if it had Shibboleth enabling impersonation Ken: Ian suggested that it might be worth developing "middleware lite" to support the Grid -- halfway between not using enterprise at all, and the enterprise being everything. Ties in with recent DoE/NASA discussion -- tried to convince them they should take the approach of distributions to campuses, including DoE/NASA-enabling object classes; they were enthusiastic. If we identify attributes useful for the Grid, how hard is it for campuses to include and populate those attributes? Michael: what about linking to enterprise directory so all this stuff doesn't have to be stored in it? Ken: worth pursuing, yes Steven: allows a Grid site to build a directory; if many of the people come from sites that have enterprise directories, that saves work for the Grid site Michael: but there's a security issue... Keith: issues with e.g. linking to Condor... Anon.: Eric has suggested several exotic solutions... Keith: the point is that we have people here who care about the privacy angle, which is going to complicate things. "this is the hardest aspect in policy...in affiliated directories"...under what circumstances do we allow a link into our eduPerson-friendly directory? The whole pitch about the value of middleware is that it's a shared service. [AI] Keith will put affiliated-directories privacy issues on the agenda for the next MACE-Dir call. [AI] Eric Norman will write up his ideas on affiliated-directories privacy. ... Keith: Brett, differences in Grid due to smaller scale? Do people expect the size to remain relatively small? Brett: right now, yes -- not likely to be more than 10,000 users in the next few years, but could grow beyond that eventually Ken: we probably can't use eduPerson as base, as eduPerson is US-centric and Grid isn't Brett: surprisingly, this didn't come up at all at the Global Grid Forum meeting, not even in the discussions with CERN Michael: Paul Hill did an internationalized version of eduPerson; I'm trying to get feedback on it from the TERENA folks, but no luck...is this really necessary? Keith: [AI] Keith will add eduPerson internationalization issues -- at a deeper level than just character sets -- to the agenda for the next MACE-Dir call. Brett: it would be good to involve e.g. Michael Helm from directory-of-directories work. Keith: We'll do our best to get him on the call Bob: He'd be happy to join, I think Brett: [AI] Brett will contact Michael Helm about joining the next MACE-Dir call, and cc Bob Morgan. Steven: it would be good to hear from Michael about his other work as well Bob: distinction between GridPerson stuff and Globus stuff -- Michael Helm would know about that Keith: [AI] Keith will look more closely at Brett's March 26 questions about the relationship between eduPerson and GridPerson. Ken: GriPhyN was very pleased to hear that we're working with the Grid - groups and roles - Michael: I've been talking with Tom Barton a lot lately, and it boils down to Todd having the right idea -- performance problems with static groups can be dealt with -- going after dynamic groups was a worthwhile idea, but we should use static groups, and deal with the performance problems via indexing. How does an app efficiently determine that Keith is a member of a group? indexed search that just gives you back what you're looking for. we think group math works out fine -- don't nest groups; use group math and AND-ing, OR-ing and NOT-ing. March 19 email from Todd describes the approach (Keith is resending it right now.) Keith: Tom J., comments? Tom J.: we're looking at grouping as it relates to our Epicentric portal deployment. Epicentric is very poorly written, e.g. it wants to enumerate all groups every 5 minutes. I was pursuing composite group object -- dynamic base with static includes and excludes Michael: use AND-ing, OR-ing and NOT-ing to include and exclude ... Keith: let's not have an official MACE-Dir position yet. Michael: one good thing about the approach I'm suggesting is that it's easy to explain to vendors. But, I agree with Keith's caution, let's not call it settled yet. Steven: It would be good for people to document what kind of groups they're trying to support. doesn't need to be formal scenarios. [AI] Steven will document how each cluster at Brown handles groups, and the factors informing their decisions; in particular he will address the issue of what should and what should not be centralized, and why. Tom J.: [AI] Tom J. will write up Wisconsin's issues with groups. Bob: another level of context -- thinking about affiliations (e.g. "student") as vs. ad-hoc groups and app-specific privileges -- three different kinds of groups that might need to be dealt with differently Keith: [AI] Tom D. and Dave S. will write up their thoughts on groups. Steven: if the Brown community is one group, can I create friends.carmody.brown and sell it? ... Michael: if the Brown-community group isn't access-controlled, you have an access-control problem. Anon.: any testing benchmarks yet? Michael: no. *Action Items* [AI] Todd will help Michael with the code on the new DoDHE server. [AI] Keith will ask the Metamerge CEO about putting in an include function. [AI] Michael will make a list of the DoDHE tasks that need to be delegated, aiming to get it sent out before the next call. [AI] Keith will put affiliated-directories privacy issues on the agenda for the next MACE-Dir call. [AI] Eric Norman will write up his ideas on affiliated-directories privacy. [AI] Keith will add eduPerson internationalization issues -- at a deeper level than just character sets -- to the agenda for the next MACE-Dir call. [AI] Brett will contact Michael Helm about joining the next MACE-Dir call, and cc Bob Morgan. [AI] Keith will look more closely at Brett's March 26 questions about the relationship between eduPerson and GridPerson. [AI] Steven will document how each cluster at Brown handles groups, and the factors informing their decisions; in particular he will address the issue of what should and what should not be centralized, and why. [AI] Tom J. will write up Wisconsin's issues with groups. [AI] Tom D. and Dave S. will write up their thoughts on groups.