1. Higgins, Active Clients, & Personal Data Stores Paul Trevithick http://project-higgins.org September 2010 v2

2. “On the Internet, nobody knows you’re a dog” 2 Copyright (c) 2010 Paul Trevithick

3. Why is this? 3 Copyright (c) 2010 Paul Trevithick

4. Our user agents don’t know us Silo A Silo B Silo C Browser Browser Browser 4 Copyright (c) 2010 Paul Trevithick

5. Silo A Silo B Silo C Browser Browser Browser We all experience the result Type, type, type. Click, click, click. Endless form filling as we populate each silo with descriptions of ourselves 5 Copyright (c) 2010 Paul Trevithick

6. Implications Personal information is spread across all these silos No way to control my digital footprint Information about me (esp. my social graph) isn’t portable My personal data is no longer mine (from a rights POV) No way to move verified attributes from A to B Privacy concerns (e.g. tracking cookies, correlatable identifiers) 6 Copyright (c) 2010 Paul Trevithick

7. Missing: an agent of the user What goes here? Something that: Centralizes control (by me) over my data whereever it lives Supports my multiple identities and attribute authorities Moves data (preferences, affiliations, ids, healthcare records, etc.) between the silos and between people Allows me to control who has access to my data 7 Copyright (c) 2010 Paul Trevithick

8. Enter the active client Portability: profile & social networking attributes are made portable by Information Cards Any kind of information: your preferences, friends, favorite songs, employee id numbers, drivers licenses, affiliations, your health plan id, etc., can be on a card. Cards are managed in a local active client “wallet” (aka Selector) such as Microsoft CardSpace™, Higgins, Azigo™, etc. running on your desktop or mobile device and integrated with your browser 8 Copyright (c) 2010 Paul Trevithick

9. Information Cards and first generation active clients 2007: Microsoft CardSpace (built into Windows 7 & Vista) 2008: Higgins and OpenInfocard open source projects 2008: June: Information Card Foundation founded 2009: OASIS IMI Standard 9 Copyright (c) 2010 Paul Trevithick

10. Higgins history Began in 2003 in affiliation with Harvard’s Berkman Center Moved to the Eclipse Foundation in 2004 IBM, Novell, and others contributed developers during 2005-2008 Google and Oracle began contributing in 2007 Higgins 1.0 was released in 2008 Higgins code is part of commercial products from Novell, IBM, Google, Serena, Azigo, and others Higgins 1.1 (Adobe AIR & iPhone) Q4 2010 http://higgins-project.org 10 Copyright (c) 2010 Paul Trevithick

11. Higgins goals User-centered design Shift control to the user over their own digital identity Enhance privacy and security Provide a simple, consistent, card-based user experience Active client-based architecture Data integration Integrate user’s profiles & social networks across data silos and apps Develop a common data model Distributed cross-silo linking of data Extensible architecture based on frameworks & plugins Designed for interoperability Cross-protocol (Infocard, OpenID, SAML, un/pw…) Authentication-technology agnostic Cross-platform (Windows, Mac, Linux, Mobile…) Open source, community-based project Business model friendly EPL license 11 Copyright (c) 2010 Paul Trevithick

12. Timeline Information Card Foundation Launched June 2008 Higgins 1.1 Q4 2010 Higgins 1.0 Feb 2008 CardSpace™Jan 2007 2004 2005 2006 2007 2008 2009 2010 12 Copyright (c) 2010 Paul Trevithick

13. Multiple, partial identities Verified Claims Loyalty Payment eGov 13 Copyright (c) 2010 Paul Trevithick

15. Address

16. Date of Birth

18. Gender

19. Like to rock climb, fly fish, mountain bike, play piano

20. No kids

21. Profession: Medical doctor14 Copyright (c) 2010 Paul Trevithick

22. Card-based login UX Click 15 Copyright (c) 2010 Paul Trevithick

23. Card-based login benefits Per-site passwords are eliminated Anti-phishing protection Site declares what claims (attributes) it needs or desires User reviews and consents to all release Privacy enhancing minimal disclosure 16 Copyright (c) 2010 Paul Trevithick

24. Platform support for Infocard Windows Microsoft CardSpace™, Higgins AIR, OpenInfocard (Firefox) Mac Novell DigitalMe™, Higgins AIR, OpenInfocard (Firefox) iPhone Higgins Browsers Firefox: Higgins, OpenInfocard IE: CardSpace, Higgins Chrome: Higgins (1.1) Safari: Higgins (1.1) 17 Copyright (c) 2010 Paul Trevithick

25. Interoperability demo at RSA 2008 18 Copyright (c) 2010 Paul Trevithick

26. Interoperability demo at RSA 2008 19 Copyright (c) 2010 Paul Trevithick

27. Infocard actors P R Identity Provider (Card Issuer) Relying Party (Card Accepter) B Browser S Selector (Active Cient) User 20 Copyright (c) 2010 Paul Trevithick

28. Personal card data flow P R B S Personal Card 21 Copyright (c) 2010 Paul Trevithick

29. Managed card data flow P R points to security token service B S has Managed Card 22 Copyright (c) 2010 Paul Trevithick

30. Infocard: the good news Infocard IMI protocol is an OASIS specification First gen clients/selectors are available for multiple desktop and mobile platforms and for IE, Firefox, Safari and Chrome Major firms have stood up card issuing sites (Equifax, Acxiom, PayPal, etc.) Infocards adopted as part of the US eGov “ICAM” program Infocard and OpenID foundations worked together to found the OpenIdentityExhange.org and have been instrumental in putting forward the notion of Trust frameworks. Trust frameworks are a key part of the forthcoming US government NSTIC strategy 23 Copyright (c) 2010 Paul Trevithick

31. Infocard: a work in progress There remain great hopes for the emergence of medium-scale “lighthouse” relying party websites (e.g. agencies of the US Federal government) that will demonstrate the business value of infocards and drive understanding and adoption Information Card Foundation is structurally transforming itself to better support its mission in the next phase We’ve learned from our first generation products There’s room for improvement in the UX, the implementations, and working more collaboratively with other identity technologies These learnings are driving the next generation… 24 Copyright (c) 2010 Paul Trevithick

32. Higgins 2.0 and next gen Active Clients

33. Higgins 2.0 UX: A less “in your face” UI WRT privacy & security. Rely more on trust frameworks. Faster, smoother browser add-on UX for download and installation Brokered authentication: Reduce per-IdP (per-card) passwords/challenges Adopt a cross-protocol “better with” strategy Embrace and add value to OpenID, SAML, WebID?, userid-passwords? Track MozillaLabs work on Account Manager Harmonize UX with UX from OpenID, Facebook Connect, etc. (See Kantara ULX WG), and also with “cloud-based identity selection agents” New desktop architecture: browser add-on + OS service + “dashboard” UI iPhone and (hopefully) Android implementations Personal Data Store Blinded data store (using Nigori technology) Interoperability from Persona data model 2.0 Relationship cards: build continuous bi-directional connection App-cards: Javascript-bearing cards; active client as a platform 26 Copyright (c) 2010 Paul Trevithick

34. Interests Searches Purchases Passwords Addresses Payment cards Location Social graph Active client as “digital me” 27 Copyright (c) 2010 Paul Trevithick

35. Even tighter (and lower latency) integration with browsers & apps Browser or Appr Browser or App Browser Form fill Data capture Active Client 28 Copyright (c) 2010 Paul Trevithick

36. General purpose Personal Data Store sync & backup; not just a “card roaming” service Browser or App App Active Client Active Client PDS Blinded data 29 Copyright (c) 2010 Paul Trevithick

37. Rich Personal Data Store(s) 30 Copyright (c) 2010 Paul Trevithick

38. Persona Data Model 2.0 A vocabulary of attributes to describe a person Card metaphor Profiles (e.g. “what amazon knows about you”) Reusable personas/roles (e.g. “work”, “anonymous”) RDF/OWL based. Builds on existing vocabularies: FOAF vCARD geoLocation SKOS http://wiki.eclipse.org/Persona_Data_Model_2.0 31 Copyright (c) 2010 Paul Trevithick

39. PDS API XDI Read/write attributes using OASIS XDI messages RESTful-ish: GET, ADD, MOD, DEL messages tunneled within POST OAuth Authentication/Authorization ActivityStreams (end of 2010) Atom feed to indicate “data update” events PubSubHubBub (end of 2010) Allows client apps to proactively receive notification of “data update” events in the ActivityStream SPARQL/Update (Q2 2011) Proposed alternative to XDI 32 Copyright (c) 2010 Paul Trevithick

40. Relationship-cards What they are Attributes can be “by reference” instead of just “by value” Card conveys a “UDI” (Linked Data or XRI) URI reference UDIs assume dynamic discovery (XRDS or Linked Data 303) Benefits Continuous data feed is established (vs. static one shot) Read/Write (vs. read only, unidirectional) 33 Copyright (c) 2010 Paul Trevithick

41. Javascript bearing app-cards Cards link to a Javascript program Javascript can be injected into the browser to perform Supports client-side mashups, aka “web augmentation”, aka browser overlays Supports Kynetx.com KNS service 34 Copyright (c) 2010 Paul Trevithick

42. App-card admin UI mockup 35 Copyright (c) 2010 Paul Trevithick

43. Active client as platform Javascript from an app-card can be injected into browser can call Client API Browser Mobile or Desktop App Javascript from an app-cards can be injected into Dashboard can provide “admin UI” via PDS Cient API Dashboard (UI) Native call to Client API PDS Client API PDS Client Web apps can access PDS via XDI or SPARQL + ActivityStreams + PSHB PDS 36 Copyright (c) 2010 Paul Trevithick

44. PDS and active clients: related work User-centric identity (2005) Letting people control their own identities, identifiers. OpenID, Infocard, WebID, OAuth 2.0 Data Portability.org (2007) A “borderless experience” VRM (Vendor Relationship Management) (2008) Shifting more control to the customer Mozilla Labs: (2009) Identity in the browser: Weave; Account Manager Federated Social Networks (2010) Distributed Facebook (e.g. Diaspora & many others) David Siegel: Pull: “Personal Data Locker” (2010) World Economic Forum (2010): Personal Data Management Initiative 37 Copyright (c) 2010 Paul Trevithick

45. Appendix AHow managed cards work

46. Managed Card:Alice goes to site P R B S 39 Copyright (c) 2010 Paul Trevithick

47. Managed Card: Selector retrieves policy P R Required and Optional Claims B S 40 Copyright (c) 2010 Paul Trevithick

48. Managed Card: Display cards that match policy P R B S 41 Copyright (c) 2010 Paul Trevithick

49. B S Managed Card: Alice selects a card P R 42 Copyright (c) 2010 Paul Trevithick

50. Managed Card: Auth to IdP P R B S 43 Copyright (c) 2010 Paul Trevithick

51. Managed Card: Generate token P R B S 44 Copyright (c) 2010 Paul Trevithick

52. Managed Card: Browser sends token P R Set of Claims B S 45 Copyright (c) 2010 Paul Trevithick

53. Managed Card: Validate token P R B S 46 Copyright (c) 2010 Paul Trevithick

54. Managed Card: Alice accesses resource P R B S 47 Copyright (c) 2010 Paul Trevithick

55. Appendix BHow relationship cards work

56. Personal r-card: first time flow Personal Data Agent/Store (in the cloud) A R P Set of Claims & Ptr B S Personal R-Card 49 Copyright (c) 2010 Paul Trevithick

57. Personal r-card steady state A Continuous connection (RDF, XDI, etc.) R P B S 50 Copyright (c) 2010 Paul Trevithick

58. Managed r-card initial flow A R P Set of Claims & Ptr B S has Managed R-Card 51 Copyright (c) 2010 Paul Trevithick

59. Managed r-card steady state Kantara UMA Authorization Manager A control control control Continuous connection R P B S has Managed R-Card 52 Copyright (c) 2010 Paul Trevithick

60. Appendix CExample PDS Client API

61. Active client API getExAttributes (string rp, string audience, Attribute attributes, Where where, function responseCallback) rp: string identifier of the "next hop" attribute data sink. It is expressed in as detailed a form as possible. audience: string. Must match either the agent or the rp parameter value or be nil. If not nil, then indicates whether to encrypt tokens for the agent or the rp. attributes: set of (attribute, optional, authorities) tuples where: attribute is a URI indicating the attribute type optional is a boolean (if true then this attribute is desired but not required) authorities is a list of domains that are considered by the caller as authoritative WRT this attribute and thus must be used as the source of the attribute, if this list is nil then self asserted values are acceptable. If authority == dev (where dev is the developer of app-card) then only the "host" card of that app will be allowed as the source of attributes. where: is a set of (attribute, value-expression) tuples where: attribute: is the attribute URI value-expression: regex expression responseCallback: Represents event listener (name of the JS function). If the value of 'onready' is an empty string, then browser extension executes an synchronous query, otherwise extension does an asynchronous query. The result will be passed as a parameter to the function responseCallback 54 Copyright (c) 2010 Paul Trevithick