New *Action Items*
[AI] {Scott} will propose changes to the attribute profile and/or present issues around changes.
Carry-over *Action Items*
[AI] {Brendan} will review archives related to eduAccount and search for interested folks, eventually arranging a call focused on formulating the right questions to target a solution. (26-Mar-07)
[AI] {Etan, Bob, and Victoriano} will begin to draft ideas surrounding the use of vocabulary in eduPersonAffiliation and eduPersonEntitlement. (13-Mar-07)
[AI] {Steve C.} will connect the UK folks with the mailing list and ask {Michael Kim) at Ovid-Silver Platter to post there. (12-Dec-06)
[AI] {Keith} will post a thread with discussion on members, and {Scott} will pass this on to folks in the UK. (12-Dec-06)
[AI] {Keith} will draft a document covering registered MACE entitlement values. (11-Sep-06)
Future *Agenda Topic*
- c (country) attribute (c.f Tom Scavo's email, 22-Jan-07)
*Agenda*
1. Upcoming Meeting: Spring 2007 Internet2 Member Meeting
2. Issues around commercial SAML and ADFS interop - SAML attribute profiles
3. Groups within Groups at U. Washington
4. Recent European meetings report
1. MACE-Dir & EDUCAUSE – how might/should we work together on IdM issues?
2. eduAccount (c.f. Quanah Gibson-Mount's email, 20-Feb-07)
*Discussion*
-Upcoming Event: MACE-Dir BoF at I2 Spring meeting-
The next face-to-face opportunity for the MACE-Dir Working Group will be at the Spring 2007 Internet2 Member Meeting <http://events.internet2.edu/2007/spring-mm/>. In particular, there will be MACE-Dir BoF on Monday morning, 23-April, at 8:30am EDT. Stay current with meeting room location and detailed meeting abstract at the following link <http://events.internet2.edu/2007/spring-mm/sessionDetails.cfm?session=3218&event=267>.
-Issues around commercial SAML and ADFS interop - SAML attribute profiles-
{Scott} led the discussion around SAML attribute profiles and commercial SAML and ADFS interoperability; so far, all discussion around this work has been under the umbrella of MACE-Directory. In anticipation of SAML v2.0, he wanted to reopen the profile documents and offer additional profile options that people could adopt, with the understanding that people will be working with various vendors. This could entail additional work; the Shibboleth community should consider what they are or are not willing to do.
Addressing scope would touch on naming standards. Regarding the implications of nameIdentifiers, it brings into question the commercial interoperability. Recent discussions have touched on collaborative applications. {Michael} asked if MACE-Dir was the right place to address this area of discussion, or if there is a better venue. {Scott} saw two questions: 1) Does MACE-Dir want its name on such a draft, and 2) Does MACE-Dir have a desire to be the venue for discussion of profiles. {Michael and Bob} agreed that it does fall inline with the kind of work that MACE-Dir is and should be involved in.
{Bob} asked about world-wide directory coordination, considering all the work going on in Europe. If it is not obvious that it is being handled by SCHAC, perhaps it ought to be handled here by MACE-Dir. {Michael and Paul} agreed with the direction of {Bob's} thought. {Steve C.} advised that it still may be fruitful to bring Europe into the picture, to gain their insight and ideas.
[AI] {Scott} will propose changes to the attribute profile and/or present issues around changes.
-Groups within Groups at U. Washington-
{Bob} shared the group management scheme at U. Washington, which he termed as "simple". They are now looking at Grouper, and looking at how to integrate with their instance of Confluence. People were interested in receiving a flat list of the groups, for ease, even though it creates more tasks in the directory. This led to a great deal of discussion about being able to do groups by reference as opposed to by value.
They are working to switch over to Active Directory, and with Grouper, the tangent usage is that its output in provisioning and directory would flatten the groups, such that all effective members are represented directly. {Steve C.} shared a bit of their experience with Brown Grouper, which supports nested groups and other operators (e.g., intersections.) He expressed having a similar problem as what {Bob} described, where some products (like Confluence) doesn't handle the idea of nested groups. Confluence does have an add-on, Crowd, which does support this. However, given that there is an add-on, it is unlikely that the main product will ever support such a capability. {Steve C.} noted that flattening groups introduces room for bizarre problems, one being a volume of data issue.
The Group discussed how (MACE) Grouper would handle the flattening of groups, and that the LDAPPC would do such a thing <https://wiki.internet2.edu/confluence/display/i2miCommon/Ldappc+v1.0 >. However, {Steve C.} was unsure that there is a way to run it so that if a certain group X changes, it would be able to detect which groups depended on it and replicate only those. How many products are running today that do not service nested groups?
{Michael} suggested a potential solution that would allow you to create one group to house all nested groups, which would rest in a different part of the directory tree. Those applications that do not understand groups within groups would be pointed to the flattened groups. He imagined that a derivative of LDAPPC would resolve this effectively.
{Brendan} mentioned another Active Directory feature where group memberships are available in the entry itself. Flattened groups would be easy to build dynamically if products being used to add people/objects to groups were smart enough to maintain forward reference, not only for one being added, but also groups elsewhere would also be inherited. For example, it could be used for anyone having the isMemberOf attribute.
Many, if not most, applications are not addressing the need for representing groups which are members of groups. There seemed to be much interest in having a nested groups capability, and it was agreed that matured features of a 2-part directory would benefit many.
{Bob} raised the point that it might give way to an argument around access control, especially regarding those applications that do not have a nested groups feature. The Group discussed policy issues that might surface, regarding who would or would not be allowed to update their group memberships; university policy may dictate this and return a value denying a request, perhaps accompanied by an explanation that the request is demanding too many resources, etc.
{Brendan} pointed out that a document has not been published which advises how a campus should manage or even allow groups within groups. How has the common practice evolved to date? {Michael} commented that if people are to make use of centralized data, there is no option right now other than doing flattened groups. {Steve C.} asked if there were things that MACE-Dir can do in terms of writing up current practices (or recipes, etc.) that campuses could point vendors to, in order to maintain forward momentum. {Michael} said he'd rather focus on an immediate fix to flatten groups, such that a tool could get an application on board, rather than looking to fix the application itself. {Bob} noted that if a tool was developed, the applications would then have no reason to change and accommodate such a fix.
{Michael} reminded the Group that it is likely to fall back into a policy decision. If the cost of doing groups is excessive on LDAP servers and the applications themselves, then a nested groups solution will eventually prevail. Of course, such limits will be tested first by larger schools that may have a need to replicate 80-100K users.
After listening to the recurrent idea of using groups for authorization, {Paul} suggested that people may prefer to do authorization management within Signet. He stressed a need for understanding how to manage and also how to scale; knowing how to steer this work with better long-term management. {Steve C.} looked forward to exploring use cases with Confluence, as an example of giving access to different sets of spaces. {Paul} shared an example of MyWork, where the idea is that people are in projects, each of which is supported by a number of various applications that support collaboration. It would allow for a project leader, and provision use of these leaders, which would build on Signet. By allowing people to create a mailing list, etc., without having to go into each of the separate applications, it is to abstract the management out of the application and into a common environment, i.e., an easy-to-use comprehensive application. Approaching this as an Identity Management problem before applications and services, as opposed to user accounts, then it is closer to the model that MACE-Dir speaks of.
-Recent European meetings report-
{Bob} gave a brief update on several recent meetings in Europe; there are many European federations deploying SCHAC v1.3, focusing on a particular attribute. He also mentioned an interesting approach involving an experimental branch at TERENA that is looking at items related to eduGAIN; attributes define for a particular application or project. There was lack of consensus on whether these were capable of being generalized. He also mentioned a desire to make progress on opening eduPersonAffiliation values.
-MACE-Directory & EDUCAUSE-
Tom provided a report via the mailing list on his action item to mention the MACE-Directory & EDUCAUSE discussion and issues from the 12-Mar conference call. This report can be found in the mailing list archives and also below [0].
Due to the upcoming Internet2 Member Meeting, the following MACE-Dir Working Group call will be canceled. Therefore, the next MACE-Dir Working Group call will be held in four weeks, on Monday, May 7, 2007 at 4:30pm EDT.
"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
[0] c.f. Tom's email from 5-Apr-07, re: MACE-Dir & EDUCAUSE
The IdM WG steering cmte discussed this last Friday… Like mace-dir, the educause idm WG is also interested in advancing our thinking about how the two groups should work together. I.e., all agree that working together is a Good Thing. It's just the usual matter of figuring out how to productively allocate time to impactful coordinated work activities.
The IdM steering cmte likes the suggestion of an audio bridge to give voice to idm wg members. This might dovetail with an idea under discussion about a potential educause "IdM Live!" series, a spin-off of the original hosted by SteveW. This could lead to a format in which each month's IdM Live! topic is used to levelset and focus the discussion of an ensuing audio bridge.
There is also general recognition that the MACE IdM model is useful and valuable for improving general understanding of this topic and coherence of related conversations. Arranging for the availability of mace-directory members to act as MACE IdM model resources on those audio bridges was thought to be another Good Idea.