**MACE Call 10-October-2011**

**Attending**
Ken Klingenstein, Internet2 (stand-in chair)
Scott Cantor, The Ohio State U.
Keith Hazelton, U. Wisconsin - Madison
Michael Gettes, CMU
Remco Poortinga, SURFnet
Chris Phillips, CANARIE
Andreas Åkre Solberg, Uninett/Feide
Chris Hyzer, U. Penn
Tom Barton, U. Chicago
Leif Johansson, SUNET/NORDUnet
Nick Roy, U. Iowa
Jacob Farmer, Indiana U.
Renee Shuey, Penn State U.
David Wasley, independent
Ann West, Internet2
Steve Olshansky, Internet2 (scribe)

NEXT CALL: 24-October-2011

**Carryover Action Items**
[AI] (All) discuss further ideas on IAM suite collaboration on the mailing list.
[AI] (All) send seedcorn suggestions to Ken.
[AI] (Ken) will distribute the CRU taxonomy of SPs
[AI] (Ken) will send out a link to relevant GENI IdM information.
[AI] (Keith) will write up the current state of the identifier discussion and apparent consensus, and associated explanatory material, for use by REFEDs.
[AI] (Ken) will coordinate a small working group with Heather to look into access control and IdM layer requirements for shared file services, calendaring, and web-conferencing in a federation-centric context.
[AI] (All) with suggestions for other foundations that the Shib Consortium could eventually be embedded in are encouraged to discuss them on the list.
[AI] (Ken) will convene a small subgroup of MACE to consider the seed corn issues in more depth and report back on a forthcoming call, soon.
[AI] (Ken) will invite Mike Conlon (U. Florida), the VIVO PI, to a forthcoming MACE call.
[AI] (Keith) will maintain an issues list to inform a potential new charter for MACE-DirNG, syncing it with the FedApps charter.
[AI] (RLBob, Scott, and SteveO) will proceed with the process of formalizing the FedApps working group, including setting up a list/wiki/website, and advertise it in the appropriate venues.
[AI] (Ken) will draft a one-pager about what MACE does and what questions it has, for review by MACE, as a discussion guide with Internet2 leadership.
[AI] (Ken) will distribute a draft requirements framework for VO support engagement
[AI] (Ken) will send out info on DHS secure online transactions
[AI] (Ken) will follow up on a MACE/AMSAC call.
[AI] (Ken) will draft a catalyst doc, covering the key items to be addressed in advising VOs how to use our infrastructure.
[AI] (Leif) will contact Ken/Steven/Tom about potential overlaps between the SDCI proposal and projects in the EU.
[AI] (Jens) will speak to an Eduroam rep about communicating with Educause.
[AI] (Ken) will draft and circulate a letter to Rice leadership, requesting input to roadmaps and use cases, and to ensure our projects with Kuali projects are aligned with their high-level strategic direction.
[AI] (Nate) will distribute information to the list about upcoming tactical issues facing MACE
[AI] (All) send Bamboo IAM comments to Tom ASAP for coordination.
[AI] (All) interested in participating in the international collaboration activity contact RL "Bob."
[AI] (RL "Bob") will contact a representative of Kuali Rice about coordinating a call.
[AI] (Ken and Mark) will distribute some information on trust anchors in the context of dynamic network configuration in GENI testbed, as well as for general access control.

** Theme **

A: VOOT: https://github.com/andreassolberg/voot/wiki/Protocol

VOOT is a very simple protocol for cross-domain read-access to groups. It is using OAuth, and is on purpose designed to be a small subset of OpenSocial 1.1.

This is a GEANT project, leveraging the increasing interest in, and experience with, OpenSocial.

SURFconext is based on OpenSocial, and this would involve some changes in group membership in their implementation based upon activity streams.

Q: Are there assumptions as to how group membership is expressed, especially in a federated context? Are there assumptions about group naming?
A: Group naming has been discussed, and would be a URL endpoint to retrieve group information.

User information does not presume a shared identifier between provider and consumer, and uses OAuth for bootstrapping eliminates the need to refer to users directly. One proposed use case would use e-mail addresses, and another would use another specific identifier TBD.

Q: Is it necessary that the group name URL resolve to get group info/metadata? If so, what kind?
A: This is just a proposal at this point, still being worked out, either OpenSocial method or alternative. Obtaining group metadata at the URL would be useful, but not necessary.

Q: Does using OpenSocial mean we are dealing only with web portal?
A: No, this is just a container format and API, and also has a REST API.

Q: Apparently 2 pieces to this approach - xferring authority to use the group, then setting up activity stream that will persist until changed, using unidirectional group membership changes -- essentially ongoing provisioning. Can this be viewed as a re-purposable means of reflecting group membership?

A: Yes, that would make sense. A user could authn to an activity stream using keys found in metadata, as an example. You would need to agree on a group naming standard, and OpenSocial would provide a framework for this.

Q: Given current use cases, would you like more? Can we see the ones you have now?
A: Yes to both. Andreas will provide a link, but doesn't expect this solution to solve all group-related problems since the problem is really more complex and would be difficult to apply to the inter-federated use cases they are focusing on.

Q: What does VOOT stand for?
A: Virtual Organization Orthogonal Technology -- i.e. orthogonal to the authn scheme.

Q: Is VOOT going through a standards body?
A: No, it is just an implementation subset of OpenSocial, and thus it may ultimately be proposed to them as an extension in the future. Proof of concept implementations will come first, and if successful they will pursue standardization.

Leif noted that technology developed under this subtask of GEANT JRA3 could be used or included in other specs. Activity stream verbs and payloads for group memberships would be useful in other contexts.

Q: There seem to be 2 themes - a consistency of syntax across group representations, and transport protocols and how they relate to group info. LDAP, SAML, SCIM, and VOOT all seem to be usable transports for group info, how does an app choose?

A: Should apps even be doing this, given the complexity and vagaries of coding? Better for middleware to be handling this, and the info just appears in the container or environment. Chris noted that for group info, it is often tailored for the app, and a loosely coupled API might be a common solution. Scott noted that while this is how it is being done often in the wild, it is not optimum. Federating groups will be challenging if we encourage apps to write to this directly...

Q: Re: SCIM which includes group attributes, has VOOT looked at this?
A: VOOT started before SCIM got started. SCIM supports updates for changes, and an app could be SCIM-enabled and consume the data provided by VOOT. More research is necessary to better understand this... Using groups for access control implies metadata about how it is assembled, and LoA.

Unless the practice has some ways to discover who entered a user into a group, and when, federated groups would be a better solution. Using groups without any of this would be more challenging.

TomB noted that proposing an architecture and implementation for the uses of groups in context would be useful.

Q: What does "federated groups" really mean?
A: There are several use cases and models, e.g. locally managing a group with both local and federated identities. Or, a group maintained across multiple organizations, such that there is no single repository of group membership.

Tom noted that ChrisH has developed a federated groups port in grouper, for sharing group membership between organizations. Scott noted that shared courses (spanning institutions) would be a prime use case.

---
Federated groups was proposed for the next theme call.