Opening Up User-Centric Identity


Published on

A presentation by Nate Klingenstein at the Eduserv Symposium 2009 in London.

Published in: Education, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Opening Up User-Centric Identity

    1. 1. Opening Up User-Centric Identity <ul><li>Nate Klingenstein </li></ul><ul><li>[email_address] </li></ul><ul><li>Internet2 </li></ul><ul><li>Shibboleth Project </li></ul>Royal College of Physicians Eduserv Symposium 2009 21 st May, 2009: London
    2. 2. Identity is Totally Forked <ul><li>Federated identity has diverged </li></ul><ul><ul><li>Enterprise-centric </li></ul></ul><ul><ul><li>User-centric </li></ul></ul><ul><ul><li>Nothing matters but users and applications </li></ul></ul><ul><li>Is divergence desirable, feasible, neither? </li></ul><ul><li>“When you come to a fork in the road, take it” – Yogi Berra </li></ul>
    3. 3. Enterprise-Centric Federated Identity <ul><li>Enterprise asserts identity data on behalf of an individual for which it is authoritative </li></ul><ul><ul><li>Attributes </li></ul></ul><ul><ul><li>Identity </li></ul></ul><ul><li>Trust relationships and integrated applications defined by the enterprise </li></ul><ul><ul><li>Federations </li></ul></ul><ul><li>SAML is the primary protocol </li></ul>
    4. 4. User-Centric Federated Identity <ul><li>Self-asserted or unverified </li></ul><ul><li>User-mediated trust establishment </li></ul><ul><ul><li>Opens up worlds of apps </li></ul></ul><ul><li>OpenID </li></ul><ul><ul><li>Yahoo ID, MyspaceID, Google Friend Connect Twitter?, and maybe your provider here </li></ul></ul><ul><li>Facebook Connect </li></ul><ul><ul><li>Federated identity’s largest success by far </li></ul></ul>
    5. 5. Universities and Identity <ul><li>Both services and identities </li></ul><ul><ul><li>The natural “home” for some user data </li></ul></ul><ul><ul><ul><li>Courses, majors, titles, affiliations, grades, HR </li></ul></ul></ul><ul><ul><ul><li>Identity-proofing? </li></ul></ul></ul><ul><ul><li>Also a home to applications </li></ul></ul><ul><li>Many outside applications federated today </li></ul><ul><ul><li>Some are low-risk, consumer-oriented </li></ul></ul>
    6. 6. Students, Identity, and School Services <ul><li>how many email accounts do they have that parents don't know about- do they use same password 4 all #socialmedia ? #teens </li></ul><ul><ul><li>“ They don't use email so it's more a matter of which ones they forgot about. They often forget their passwords so I would guess that they don't use the same password consistently. Of course, they also share certain passwords with their closest &quot;trusted&quot; friends so that gets messy really fast. And they change it when there's a breakup.” </li></ul></ul><ul><li>Do they really care about/use school library websites? </li></ul><ul><ul><li>“ Nope, they don't. All but Twitter [which they don’t use] are categorized as school tools and are only used when absolutely necessary and Google won't suffice.” </li></ul></ul><ul><li> </li></ul>
    7. 7. Natural Pressures <ul><li>Economy </li></ul><ul><li>Discovery </li></ul><ul><li>Trust and Ease of Use </li></ul><ul><li>Users, developers, administrators </li></ul><ul><ul><li>We’re lazy </li></ul></ul>
    8. 8. Economic Pressures <ul><li>User data is extremely valuable </li></ul><ul><ul><li>To both IdP/OP and SP/RP </li></ul></ul><ul><li>User data is extremely expensive </li></ul><ul><ul><li>Password resets, vetting, aging, etc. </li></ul></ul><ul><li>Network externalities </li></ul><ul><li>Security externalities </li></ul><ul><ul><li>Save now, maybe pay later: easy choice? </li></ul></ul>
    9. 9. Discovery Pressures <ul><li>Users are Lazy </li></ul><ul><li>Interface Work is Hard </li></ul><ul><ul><li>Pull-downs? Text boxes? Buttons? Client code? </li></ul></ul><ul><li>Buttons are winning </li></ul><ul><li> </li></ul><ul><ul><li>Social bookmarking syndrome </li></ul></ul><ul><li>Browsers ready to enter the fray? Whither Cardspace? </li></ul>
    10. 10. Trust Pressures <ul><li>Administrator-mediated trust mediation is slow and arduous </li></ul><ul><ul><li>Federations help; could help more in a different world </li></ul></ul><ul><li>Consent-based trust is faster, gives users control </li></ul><ul><ul><li>Will they use it responsibly? Do they care? Do we care? Does it depend? </li></ul></ul>
    11. 11. What to do? <ul><li>Reunification of federated identity? </li></ul><ul><ul><li>Protocols </li></ul></ul><ul><ul><li>Discovery </li></ul></ul><ul><ul><li>Trust </li></ul></ul><ul><ul><li>Attributes </li></ul></ul><ul><li>Ne’er the two shall meet? </li></ul>
    12. 12. Protocols <ul><li>World’s most ridiculous fight </li></ul><ul><ul><li>But there’s bad blood and high stakes </li></ul></ul><ul><li>Most protocols can solve most problems </li></ul><ul><ul><li>Hacks, revisions, kludges </li></ul></ul><ul><li>Identity sources should support many protocols and apps should be agnostic </li></ul><ul><ul><li>Deployed base is large </li></ul></ul>
    13. 13. Discovery <ul><li>If we don’t come up with something good, buttons win </li></ul><ul><ul><li>E-mail? </li></ul></ul><ul><ul><li>Auto-complete with institutional name? </li></ul></ul><ul><ul><li>Client software? Cardspace, Mozilla? </li></ul></ul><ul><li>Remember the economic pressures </li></ul><ul><ul><li>A few providers would also win </li></ul></ul>
    14. 14. Trust <ul><li>One size will never fit all </li></ul><ul><ul><li>Many different user preferences </li></ul></ul><ul><ul><li>Many different application needs </li></ul></ul><ul><ul><li>Many different legal requirements </li></ul></ul><ul><li>The answer must be flexible enough </li></ul><ul><ul><li>Federations, consent, reputation systems, roots, authorities… </li></ul></ul>
    15. 15. Attributes <ul><li>Attributes cannot be divorced from the asserting/attesting entity </li></ul><ul><li>Natural sources of authority exist </li></ul><ul><ul><li>Legal name, course enrollment, music preferences </li></ul></ul><ul><li>Aggregation happens out-of-band today </li></ul><ul><ul><li>Must be automated for tomorrow </li></ul></ul><ul><li>Levels of Assurance </li></ul>
    16. 16. Would a Lack of Unification be Bad? <ul><li>User confusion, particularly with discovery or client software </li></ul><ul><li>Data duplication, distribution </li></ul><ul><li>Additional deployment and software complexity -- maybe </li></ul><ul><li>Nothing new here… </li></ul>
    17. 17. Will Unification Happen? <ul><li>Dunno </li></ul><ul><ul><li>Probably some, particularly aggregation </li></ul></ul><ul><ul><li>Probably not all </li></ul></ul><ul><li>We should endeavor to ensure that the outcome is deliberate and sufficient </li></ul><ul><ul><li>Cooperation </li></ul></ul><ul><ul><li>Economic pressures </li></ul></ul>