1. Interfederation RL “Bob” Morgan University of Washington and Internet2 Digital ID World 2005 San Francisco

2. 2 Topics Federation and Interfederation US E-Authentication Program and Internet2 USperson schema

3. 3 Federations defined created to support community interesting ones are multi-IdP, multi-SP embodies agreements on many levels membership, technology, assurance, key mgt, legal, attributes, privacy, appropriate use, etc facilitates member federated interactions many potential sub-communities and their apps operational support key/config distribution, IdP discovery, etc doesn't preclude non-fed arrangements

4. 4 Federations happening i.e., SAML-based (or similar) federations in Europe, natural extension of HE NREN services Switzerland, Finland, Netherlands, UK, Spain, France, etc in US InCommon Federation in higher ed also state-level planning, vertical apps such as student loan management US government E-Authentication Program also much non-fed or pre-fed deployment among fed members

5. 5 Interfederation an immediate consequence of federation brand-new federations don't have well-defined boundaries or service scopes it's the Internet, we're all connected many interesting SPs are global, e.g. Elsevier Interfederation workshop, Oct 2004 Upper Slaughter, UK (a nicer walled garden?) many countries, including CERN many agreements on direction, future work

6. 6... but it's a nice garden

7. 7 Interfederation models parallel universes members simply participate in many if needed consistent with fundamental pairwise nature of app-level relationships scaling, diversity not addressed peering transitive assurance, legal, policy, maybe ops too tight a coupling? league of federations? some historical examples...

8. 8 US E-Authentication http://cio.gov/eauthentication for authoritative info facilitates trusted access to e-government e-auth elements credential providers (CSPs), agency apps (AAs) credential assessment framework (CAF), application risk assessment, defined LoAs approved technologies, products (X.509, SAML) e-auth ops: membership, portal (aka “Fed fed”) agency mandates

9. 9 InCommon E-Auth alignment promote interop for widespread higher-ed access to USG applications grants process, research support, student loans... process project started Oct 2004, thru Sept 2005 compare federation models propose alignment steps validate with federation members, via concrete application trials implement via next e-auth, InCommon phases

10. 10 Alignment points Basic divergence: loose vs tight coupling assurance: facilitated vs guaranteed InCommon participants publish their processes E-auth participants audited, approved by GSA level of assurance is fundamental characteristic membership: IdP-centric vs SP-centric E-auth driven by requirements of e-government AAs InCommon driven by requirements of university CSPs operation: metadata-centric vs portal-centric InCommon-managed metadata supports interaction E-auth portal mediates flow, adds adapation point

11. 11 Alignment points 2 user identity: application-supporting attributes vs fixed identifier set InCommon relies on Internet2-defined eduPerson, promotes attribute-based authorization E-Authentication specifies delivery of identifiers technology: SAML and profiles InCommon specifies Shib profile of SAML 1.1 E-authentication specifies extensive profile on top of SAML 1.0 intend to converge on SAML 2.0

12. 12 Validation steps universities undergo trial by CAF assess whether compliance is likely across HE U Washington, Penn State, Cornell pretty darned close: 50% all-OK, others do-able deploy access to a real USG app summer 2005 requires E-Auth acceptance of univs as CSPs app will modify existing provisioning process practical feedback to alignment recommendations

13. 13 US person motivated by InCommon desire for attribute- based authorization modeled on Internet2 eduPerson spec framework on which agency/app definitions can be built not just SAML generic information model, mapped to LDAP, SAML, XML provisioning ambitious? yes...