**MACE Call 3-January-2011**

**Attending**

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

Renee Shuey, Penn State U.

Ken Klingenstein, Internet2

Tom Barton, U. Chicago

Jim Jokl, U. Virginia

Michael Gettes, CMU

Keith Hazelton, U. Wisc. - Madison

Steven Carmody, Brown U.

Scott Cantor, The Ohio State U.

Heather Flanagan, Internet2

Renee Frost, Internet2

Mark Poepping, CMU

Nate Klingenstein, Internet2

Ann West, Internet2

Benn Oshrin, Internet2

Steve Olshansky, Internet2 (scribe)

NEXT CALL: 17-January-2011

*Carryover Action Items*

[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] (All) Volunteers for the ACAMP program committee are encouraged to contact Ann, TomB, or RL "Bob"

[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 Conlin (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] (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] (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**

Theme call on registries, meaning mostly but perhaps not entirely person/user registries.

In conjunction with recent discussions about OpenID, and maintaining information about users (especially across institutions e.g. in VO collaboration contexts), person registries are the topic of more attention and discussion lately in various fora.

What about more lightweight registries, designed for use for an application or a small set of apps in support of a federation infrastructure -- would traditional person registries scale down appropriately? Cf recent discussions about account linking across providers at U. Washington. How many users are we talking about? What does "lightweight" really mean?

In the COmanage context, an example use case could be a grad student who is replaced every couple of years...

An access list of users with authz to have access to certain resources is somewhat unwieldy at scale.

What is the overlap between these examples and what we would call a registry?

Benn noted that as COmanage is progressing it is starting to look more like a registry in significant ways.

Scaling a registry down to embed into an application was discussed, v. having a set of API calls to an external registry. Is it really good to have multiple different registries, v. a centralized entity that apps can call? E.g. is it more logical just to have the apps be LDAP-enabled?

Insulating privilege management infrastructure from the externalization of identity was raised as an issue in need of addressing, in this context.

Source systems v. consuming systems present different contexts in which to discuss registries. Can or should they be conflated? Probably not...

The more general problem -- suites of apps serving multiple user communities -- needs to be considered. Whose problem is this, really?

There are many examples of a researcher working with a small group, without access to significant IT skills. How can these sorts of groups avail themselves of environments like COmanage without running their own registries? A common set of APIs which would enable things like this to be deployed easily would be valuable. The interfaces become very important.

In a way this comes back around to the domestication question - enabling apps to work...

Does this whole thing really come down to preference about how you want to operate your infrastructure? Federated IdM carries you across borders, but then it is up to the organization you are working with to decide how they want to operate.

Without guidance provided to app developers, they will just do what they wish to for their own particular requirements and it is harder later for us as a community to deal with the mixture of approaches. What are the gaps here?

Dealing with the proliferation of federation options, and using them with groups and privilege management, is challenging... Understanding the needs of particular apps, and how to integrate them with the local infrastructure, is becoming more difficult as more of them go their own way.

Lightweight v. heavyweight registries have been discussed for a long time. As IdM has gained traction and vendor support, registries have tended to gain more weight over time.

With the growing proliferation of "satellite systems" containing information that doesn't really belong in the core registry -- e.g. tracking credentials issued and the information provided for identity vetting, which doesn't really belong in the central person registry -- has illuminated an important aspect of this problem space.

Q: How does KIM approach registries?

A: They are more looking at embedded registries for app developers, but this seems to be something of a dead end. Rice doesn't seem inclined to package and support KIM in this way.

As a project with aspirations toward becoming a full-blown IdM system implementation, it will by its nature include some sort of embedded registry. It has separated out the service interfaces from the implementation to allow deployers to have options for integrating with their respective infrastructures.

KIM "out of the box" doesn't include support for reconciliation of records, which is left to deployers to work out. This is one of the defining aspects of registries as the term has traditionally been used in our context.

Q: How do we evaluate risk in apps we run on our campuses? E.g. in users raising their LoA as their status changes. Are there common criteria to use to determine which apps need higher LoA?

A: NIST 800-53 is fairly applicable, but not completely. Also NIH is looking at a developing a compound attribute called "credential" (e.g. used in the DHS and DoD settings) which is the 3-tuple of identity proofing, delivery of credential, and act of authentication

Attribute aggregation was raised as another way of looking at this problem, as was issuing universal persistent identifiers (besides SSN)...

- Jasig OpenRegistry project: https://wiki.jasig.org/display/OR/

SFU presentation about OR: https://wiki.jasig.org/download/.../JeremyRosenbergIT4BC.pdf

Rutgers is still working on this, and Simon Fraser U. is the other major contributor. Active coding is under way, although perhaps not as rapidly as some would like. There is growing interest in this in the community, but that hasn't really translated into offers of development support. There are other minor contributors, but Rutgers and SFU are the main ones.

The project will be visible at the upcoming ACAMP, May 25-27, 2011 in Denver.

http://www.jasig.org/jasigs-spotlight-open-source (see bottom of the page)