**MACE Call 2-August-2010**

**Attending**

RL "Bob" Morgan, U. Washington (chair)

Renee Shuey, Penn State (call leader)

Ken Klingenstein, Internet2

Jim Jokl, U. Virginia

Scott Cantor, The Ohio State U.

Paul Hill, independent

Michael Gettes, independent

Tom Barton, U. Chicago

Keith Hazelton, U. Wisc - Madison

Steven Carmody, Brown U.

Leif Johansson, SUNET/NORDUnet

Renee Frost, Internet2

Scotty Logan, Stanford

David Wasley, independent

Ann West, Internet2

Nate Klingenstein, Internet2

Neal McBurnett, Internet2

Steve Olshansky, Internet2 (scribe)

NEXT CALL: 16-August

*Carryover Action Items*

[AI] (All) if interested in supporting MoonShot activities, send mail to Ken and subscribe to appropriate lists TBD. There may be some funding available to support travel, e.g. to IETF meetings...

[AI] (Ken) will distribute a draft requirements framework for VO support engagement

[AI] (David) will contact GSA for an update on the approval process for InCommon Silver.

[AI] (ReneeS) will revisit the list of potential new MACE members on the list.

[AI] (All) Send input to Ken about how the InCommon cert service ought to be packaged - i.e. amendment to existing InCommon contract, or other.

[AI] (Ken) will revise the mission statement based upon feedback received on the call.

[AI] (Ken) will send out info on DHS secure online transactions

[AI] (Ken) will follow up on a MACE/AMSAC call.

[AI] (Ken) will follow up with Kuali/Rice about I2MI collaboration.

[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] (Leif) will discuss the IDTrust meeting on the PKNG list, seeking feedback.

[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.

[AI] (Ken) will circulate some meeting notes from the last TERENA/ REFEDS meetings.

**Discussion**

What is (or isn't) a VO? Is everything, in some sense? E.g. LIGO took a while to work out what a VO means in their context.

- A centralized administrative entity managing and assigning attributes to users from other domains? Wouldn't this also apply to a campus assigning attributes to a researcher from another campus?

- Collections of people trying to accomplish common goals, but lacking their own resources to do so -- and thus needing resources from others. Many of the large NSF VOs are not lacking in resources (e.g. LIGO, which has structure, staffing, and IT wherewithal).

- Is defining a VO (or CO) really necessary? Wouldn't it make more sense for MACE to spend its energies determining generalizable functional specs and how to support them in a technical sense?

- Attribute aggregation and requirement was mentioned as one aspect, but not a defining one...

- Sources of authority for identities and attributes can be something of a challenge, since each PI could be viewed as a separate realm...

- A good crisp list of use cases would be immensely helpful...

- Recent conversations with LIGO and iPlant have been very instructive. Each is very interested in learning more about what other VOs are doing, to learn lessons and avoid reinventing the wheel.

- What else besides COmanage would be required to support VOs? Ken's list is fairly developmentally-oriented. Perhaps a separate list of implementation-focused needs would be useful. Information to assist developers in utilizing existing tools would be useful.

- To the extent that conspicuous middleware tools have governing institutes, how can we best work with them to influence their direction in a positive way, and keep them informed of our progress? Offering a service for them to evaluate might be a good step, as would demonstrating utility among a small subset of their key users to start. Periodic symposia to update?

- What proportion of VO activities are interrealm? What are the metadata needs for interrealm work, and how would this be managed? Or is the question really determining what the use cases are for sharing between instances?

- For science workflow systems, with internal security mechanisms, how could they work within am interrealm infrastructure? E.g. who owns the clusters being utilized, and how well do they play with others?

- For volatile trust relationships within a VO, would a common PKI root even be viable?

- How do differing privacy and LoA requirements affect the deployment of interrealm tools. E.g. privacy issues could prove to be a real challenge to attribute aggregation efforts.

- Note that the action items stemming from the recent AdvanceCAMP address many pertinent issues:

https://spaces.internet2.edu/display/ACAMPActionItems/Home

- Provisioning: federated groups, v. groups with federated members v. federated instances of group management tools -- would this sort of distinction also apply to provisioning systems? How would group objects be replicated between access management systems?

- Should we be working with standards organizations, e.g. SPML/OASIS? It would seem to be incumbent upon us to do a gap analysis and determine whether the relevant vendors consider them to be relevant...

- Should MACE spin up an activity (i.e. working group) around provisioning? The activity stemming from AdvanceCAMP would seem to be the right level of activity for now, and see how that develops. OTOH provisioning could be considered core to a useful set of middleware activities, and thus deserving of more formal support - e.g. to develop best practices and white papers etc. as a start.