MACE Call 12-September-2011

**MACE Call 12-September-2011**

**Attending**
RL "Bob" Morgan, U. Washington (chair)
Ken Klingenstein, Internet2
Scott Cantor, The Ohio State U.
Keith Hazelton, U. Wisconsin - Madison
Michael Gettes, CMU
Neils van Dijk, SURFnet
Jimmy Vuccolo, Penn State U.
Heather Flanagan, Internet2
Rob Carter, Duke
Tom Barton, U. Chicago
Jim Jokl, U. Virginia
Steven Carmody, Brown U.
Nick Roy, U. Iowa
Jacob Farmer, Indiana U.
Renee Shuey, Penn State U.
David Wasley, independent
Steve Olshansky, Internet2 (scribe)

NEXT CALL: 26- September-2011

**Carryover Action Items**
[AI] (Keith) will invite a Fluid rep for dinner theater at the Fall 2011 I2MM.
[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 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] (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] (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: account linking
Further work on this area will take place in the FedApp wiki:
https://spaces.internet2.edu/display/fedapp/Home

The notion of account linking has been around since at least the origins of federation: the act of linking an existing local account to a new federated identity, usually via user action. Now in our somewhat more mature federated world it happens all the time, and is usually the first step when an existing site tiptoes into federation. Yet it's still often hard to grok for such sites, and is often done poorly. And there are new scenarios: linking many different federated ids, moving from one to another, handling social ids too, linking as part of introductions, connections to email, etc. New apps where linking happens are pretty visible: Educause, NSF Fastlane, NIH apps, etc. Box.net and AdmitMe are potential new ones. E-Science VOs are likely part of the picture too. Campus IdM systems may have a role to play.

So the hope is to draft a doc listing some of the issues and perhaps making some recommendations. This would no doubt fall into the work that was supposed to happen under the "federated app" banner, but that alas has never progressed. So this may be a start.

Not a cutting-edge theme, instead nuts and bolts, but the plumbing has to work, no?

Starter issues list:
* Simple vs multi-faceted
* UI considerations
* Impact on LOA
* Linkage cardinality (one-way, two-way, omnidirectional)

Niels noted 2 basic SURFnet use cases:
- Collaboration - reusing groups defined in other systems, wherein the users have different identifiers than those used in the federation, and these need to be mapped.

Challenging issues here include LoA.

- Campus - e.g. several universities sharing a LMS. The challenge is the various campus administrative systems connected, e.g. recording grades. Typically this has been handled by creating new accounts and identifiers for a "foreign" student.

A variety of other use cases:
- authenticating to various resources (aka "the system") with their choice of IdPs, including both social and institutional. When a user has a hiatus between campus affiliations, it would be useful to use a social identity in the interim to remain engaged with the activity.

- account linking so a 3rd party could assert permissions to a SP. E.g. a VO asserting permission for a user, when the SP would not trust the campus to assert it.

- account linking across transitions in a user's relationship with an institution, e.g. applicants using AdmitMe or social identities for the applicant portal, and then later enrolling and gaining an institution-assigned identity.

- a staff member separating from the campus, which has outsourced payroll, and the departing staffer needs to access to access various documents.

- for an outsourced campus service, when a user has an pre-existing account that needs to be transformed to an enterprise account when an aggregate deal is reached. Which attribute(s) can a user modify on his/her own? Which attributes would be linked?

- account linking in response to an invitation, e.g. adding a user to a VO using an e-mail address, who does not already have an identity in the system. The user logs in via their IdP of choice, into a "stub" account.

- invitation to participate in a workflow, for a user not already in the system, linking an e-mail address to a new or existing id.

- Google's experiences with its account system migration, merging previously silod account spaces into one, is a high-profile large scale example in the wild.

- Linking an institution's own identities back together, e.g. various e-mail addresses (or different domain names used by the same institution) for individual users.

- Academic med center with separate IdM system from the main campus, needing to provision user access to campus common systems.

Educause and NSF FastLane asks a user for existing username/passwd, then links it to the federated account upon the user first appearing from an IdP. This raises its own set of issues, including whether the old username/password still works.

Privacy issues often arise as a complication, e.g. in keeping a user's identities separate when the systems are trying to link them. Linking and attribute aggregation scenarios often pit usability and privacy against each other.

For an outsourced service for which a user can pre-register, and which uses multiple sources of identity for a user, when the institution later tries to merge the account into an enterprise account things can get sticky. Which identity becomes THE identity? Can the parties choose whether to connect the relationships?

It was observed that e-mail address is a very weak and unreliable method for linking accounts, although it is widely used. Who "owns" a particular address, and what is it used for?

Who is authoritative to assert an account identifier for a user? E.g. should a university be able to assert that a social identifier is a valid identifier for user john.doe@foo.edu?