InCommon Update FedEd Meeting June 16, 2004 Carrie Regenstein

Why a Federation for the Academic Community?  Scenario #1: Instruction Professor teaches at USC, which has enrolled students from CMU, through an inter-institutional cooperative agreement of universities. During scheduled office hours, the professor works at her workstation, when a pop-up box appears that John Doe from CMU is requesting to initiate a videoconference with her. (authZ #1) Info is also conveyed that CMU asserts that this is, in fact, who he claims to be and further, is an enrolled student in the class. She can make an informed decision about whether to accept the videoconference invitation. (authZ #2) The info is believed because it has been delivered in the context of a trusted federation.

Why a Federation for the Academic Community?  Scenario #2: Research A group of researchers, spread across a number of participating institutions of the federation, want to securely share a web site located on one of the campuses. Each researcher can use his or her own campus identity and login to access the restricted site. Confidence is based on the fact that the institutions belong to a trusted federation.

Why a Federation for the Academic Community?  Scenario #3: Living and learning A content provider (aka “target”) wants to change from IP access controls to better technologies for gating content to an institutional customer, and is therefore willing to accept campus credentials for access to content. This provides better security and enables higher levels of granularity in controlling access if restricted access is desired. The basis for the content provider trusting in the origin is the trusted federation.

What is InCommon?  InCommon is… a formal federation of organizations focused on creating a common framework for trust in support of research and education… whose purpose is to facilitate collaboration through the sharing of protected resources, by means of an agreed-upon, common trust fabric.  The InCommon federation is intended to support production- level end-user access to protected resources by providing the means to allow organizations to make effective decisions about sharing resources, based upon the attributes presented by a requesting user.

Shibboleth Status  Open source, privacy preserving federating software  Being very widely deployed in US and international universities  Target - works with Apache(1.3 and 2.0) and IIS targets; Java origins for a variety of Unix platforms.  V2.0 likely to include portal support, identity linking, non web services (plumbing to GSSAPI,P2P, IM, video) etc.  Work underway on intuitive graphical interfaces for the powerful underlying Attribute Authority and resource protection  Likely to coexist well with Liberty Alliance and may work within the WS framework from Microsoft.  Growing development interest in several countries, providing resource manager tools, digital rights management, listprocs, etc.  Used by several federations today – NSDL, InQueue, SWITCH and several more soon (JISC, Australia, etc.) 

InCommon Federation Overview  Federation operations – Internet2  Federating software – Shibboleth 1.1 and above, though others may be added later  Federation data schema - eduPerson or later and eduOrg or later  Became operational April 2004, with several early entrants to help shape the policy issues.  Precursor federation, InQueue, has been in operation for about six months and will feed into InCommon  and

InCommon Management  Operational services by I2 Participant services Backroom (CA, WAYF service, etc.)  Governance Executive Committee - Carrie Regenstein - chair (Wisconsin-Madison), Jerry Campbell, (USC), Lev Gonick (CWRU), Clair Goldsmith (Texas System), Mark Luker (EDUCAUSE),Tracy Mitrano (Cornell), Susan Perry (Mellon), Mike Teets, (OCLC), David Yakimischak (JSTOR). Project manager – Renée Frost (Internet2)  Participation open to.edu and affiliated business partners (Elsevier, OCLC, Napster, Diebold, etc.)  Contractual and policy issues being defined now. I2 held harmless.  Likely to take 501(c)3 status; starting as a LLC

Exec Committee’s Working Groups  Policy Sub-Committee (Tracy Mitrano, chair) Drafting evolutionary policies and procedures for federation participants. Considering other policy frameworks, e.g., EDUCAUSE Higher Ed Bridge Cert Authority (HEBCA), I2’s US Higher Ed Root (USHER) Cert Authority, GJ’s one pager, etc.  Communications, Membership, Pricing and Packaging Sub-Committee (Susan Perry, chair) Who can join? How? Getting the word out … in English

InCommon Pilot  Phase One participants Cornell, Dartmouth, OSU, Penn State, SUNY-Buffalo, University of Rochester, USC, UT-Health Science Center- Houston, UVa, JSTOR, OCLC  The JSTOR Challenge The Goal: JSTOR will not accept IP authentication. It will only accept Shib. The Invitation: JSTOR is seeking at least one campus to give up its IP authN and only use Shib to access JSTOR. The Guest List: Pilot schools? CSG? Any school that’s ready, willing, and able. The Prize? TBD

Trust in InCommon – participant/federation  Participants trust the federated operations to perform the federation’s activities well InCommon issues component identity credentials for participants’ Shib platforms and collects & distributes necessary operational information among participants. The operator (Internet2) posts its procedures, attempts to execute them faithfully, and makes no warranties InCommon will make a reasonable effort to ensure that it is working with individuals who represent the participant organization. Enterprises read the procedures and decide if they want to participate

Trust in InCommon- participant/participant  Origins and targets trust each other bilaterally in out-of- band or no-band arrangements Participants post a statement of basic information Origins trust targets dispose of attributes properly Targets trust origins to provide attributes accurately Risks and liabilities managed by end enterprises, in separate ways

InCommon Trust - ongoing  Use trust  Build trust cycle  Clearly need consensus levels of I/A  Multiple levels of I/A for different needs Two factor for high-risk Distinctive requirements (campus in Bejing or France, distance ed, mobility)  Standardized data definitions unclear  Audits unclear  International issues

InCommon internal ops  InCommon CA Identity proofing the enterprise Issuing the enterprise signing keys (primary and spare) Signing the metadata  InCommon Federation Aggregating the metadata Supporting campuses in posting their policies

Getting to first base  Alphonse-Gaston: establishing a set of rules to determine criteria for InCommon participation Individual participants may not want to know the details about other participants’ policies. Do they need to? –Trust engendered through optional disclosures. Federation participants use different assumptions, e.g, some University Systems may want to join as a collective system, while others would prefer to join as individual campuses. Is consistency important? Are multiple federation memberships problematic? Should participants be asked to vouch for other potential participants?

Developing an inventory of campus identifiers  What assertions are acceptable for what purposes?  Risk and trust requirements will be determined by the resource holder as well as the user considering their personal privacy risk. Taken together, these requirements will determine the technologies and policies implemented. At the low risk & low trust end of the continuum: public information websites, videoconferencing meeting for the Shib Development Team. –What assertions— if any — should be required? At the mid-level of risk and trust: access to copyrighted materials, course management systems, business services, etc. At the high risk & high trust end of the continuum: access to medical records, data from a bio-terrorism lab, videoconferencing meeting of security experts discussing response to network security emergency.

Developing levels of trust Inventory of Campus Identifiers: Context  The identifier inventory informs the process of determining the requirements for trust, including what assertions are acceptable for what purposes.  The table represents a few sample applications and where they might fall on a risk/trust continuum.  Risk and trust requirements are determined by the resource providers and the users considering their personal privacy risk.

Risk - Trust Matrix

The potential for InCommon  The federation as a networked trust facilitator  Needs to scale in two fundamental ways Policy underpinnings need to move to normative levels among the participants; “post and read” is a starting place… Inter-federation issues need to be engineered; we are trying to align structurally with emerging federal recommendations  Needs to integrate with PKI and with federal and international activities  If it does scale and grow, it could become a most significant component of cyber-infrastructure…

Authenticate locally, Act federally  For general information  For participation information