Higgins active clients and personal data stores v2
-
Upload
paul-trevithick -
Category
Technology
-
view
6.483 -
download
0
Transcript of Higgins active clients and personal data stores v2
Higgins, Active Clients, & Personal Data Stores
Paul Trevithick
http://project-higgins.org
September 2010
v2
2Copyright (c) 2010 Paul Trevithick
“On the Internet, nobody knows you’re a dog”
3Copyright (c) 2010 Paul Trevithick
Why is this?
4Copyright (c) 2010 Paul Trevithick
Our user agents don’t know us
Browser
Silo A
Browser
Silo B Silo C
Browser
5Copyright (c) 2010 Paul Trevithick
Browser
Silo A
Browser
Silo B Silo C
Browser
We all experience the result
Type, type, type. Click, click, click. Endless form filling as we populate each silo with descriptions of ourselves
6Copyright (c) 2010 Paul Trevithick
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)
7Copyright (c) 2010 Paul Trevithick
Missing: an agent of the user
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
What goes here?
8Copyright (c) 2010 Paul Trevithick
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
9Copyright (c) 2010 Paul Trevithick
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
10Copyright (c) 2010 Paul Trevithick
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
11Copyright (c) 2010 Paul Trevithick
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
12Copyright (c) 2010 Paul Trevithick
Timeline
CardSpace™ Jan 2007
Information Card Foundation Launched June 2008
Higgins 1.0Feb 2008
2004 2005 2006 2007 2008 2009 2010
Higgins 1.1Q4 2010
13Copyright (c) 2010 Paul Trevithick
Multiple, partial identities
Loyalty
PaymenteGov
Verified Claims
14Copyright (c) 2010 Paul Trevithick
Managed vs. personal
Managed: What another says about you• Name• Address• Date of Birth• License number
Personal: What you say about you• Name• Gender• Like to rock climb, fly fish, mountain bike, play piano• No kids• Profession: Medical doctor
15Copyright (c) 2010 Paul Trevithick
Card-based login UX
Click
16Copyright (c) 2010 Paul Trevithick
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
17Copyright (c) 2010 Paul Trevithick
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)
18Copyright (c) 2010 Paul Trevithick
Interoperability demo at RSA 2008
19Copyright (c) 2010 Paul Trevithick
Interoperability demo at RSA 2008
20Copyright (c) 2010 Paul Trevithick
Infocard actors
B
RIdentity Provider (Card
Issuer)
Relying Party (Card Accepter)
User
S
Browser
Selector (Active Cient)
P
21Copyright (c) 2010 Paul Trevithick
Personal card data flow
PersonalCard
B
S
RP
22Copyright (c) 2010 Paul Trevithick
Managed card data flow
points to security
token service
ManagedCard
has
B
S
RP
23Copyright (c) 2010 Paul Trevithick
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
24Copyright (c) 2010 Paul Trevithick
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…
Higgins 2.0 and next gen Active Clients
26Copyright (c) 2010 Paul Trevithick
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
27Copyright (c) 2010 Paul Trevithick
Interests
Passwords
Addresses
Searches
Social graph
Purchases
Location
Payment cards
Active client as “digital me”
28Copyright (c) 2010 Paul Trevithick
Browser or Appr
Active Client
Browser or App
Browser
Even tighter (and lower latency) integration with browsers & apps
Form fill
Data capture
29Copyright (c) 2010 Paul Trevithick
General purpose Personal Data Store sync & backup; not just a “card roaming” service
Browser or App
Active Client
Active Client
PDS
App
Blinded data
30Copyright (c) 2010 Paul Trevithick
Rich Personal Data Store(s)
31Copyright (c) 2010 Paul Trevithick
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
32Copyright (c) 2010 Paul Trevithick
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
33Copyright (c) 2010 Paul Trevithick
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)
34Copyright (c) 2010 Paul Trevithick
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
35Copyright (c) 2010 Paul Trevithick
App-card admin UI mockup
36Copyright (c) 2010 Paul Trevithick
Active client as platform
PDS
Browser
Javascript from an app-card can be injected into browser can call Client API
Dashboard (UI)
Mobile or Desktop
App
Native call to Client API
Web apps can access PDS via XDI or SPARQL + ActivityStreams + PSHB
PDS Client API
Javascript from an app-cards can be injected into Dashboard can provide “admin UI” via PDS Cient API
PDS Client
37Copyright (c) 2010 Paul Trevithick
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
Appendix AHow managed cards work
39Copyright (c) 2010 Paul Trevithick
Managed Card:
Alice goes to site
B
S
RP
40Copyright (c) 2010 Paul Trevithick
Managed Card:
Selector retrieves policy
Required and
Optional Claims
B
S
RP
41Copyright (c) 2010 Paul Trevithick
Managed Card:
Display cards that match policy
B
S
RP
42Copyright (c) 2010 Paul Trevithick
B
S
Managed Card:
Alice selects a card
RP
43Copyright (c) 2010 Paul Trevithick
Managed Card:
Auth to IdP
B
S
RP
44Copyright (c) 2010 Paul Trevithick
Managed Card:
Generate token
B
S
RP
45Copyright (c) 2010 Paul Trevithick
Managed Card:
Browser sends token
Set of Claims
B
S
RP
46Copyright (c) 2010 Paul Trevithick
Managed Card:
Validate token
B
S
RP
47Copyright (c) 2010 Paul Trevithick
Managed Card:
Alice accesses resource
B
S
RP
Appendix BHow relationship cards
work
49Copyright (c) 2010 Paul Trevithick
Personal r-card: first time flow
A
Set of Claims & Ptr
R
B
S
P
Personal Data Agent/Store(in the cloud)
Personal R-Card
50Copyright (c) 2010 Paul Trevithick
Personal r-card steady state
A
Continuous connection (RDF, XDI, etc.)
R
B
S
P
51Copyright (c) 2010 Paul Trevithick
Managed r-card initial flow
A
Set of Claims & Ptr
has
ManagedR-Card
R
B
S
P
52Copyright (c) 2010 Paul Trevithick
Managed r-card steady state
A
ManagedR-Card
has
Kantara UMA Authorization Manager
control
control
control Continuous connection
R
B
S
P
Appendix CExample PDS Client API
54Copyright (c) 2010 Paul Trevithick
Active client API
• 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
getExAttributes (string rp, string audience, Attribute attributes, Where where, function responseCallback)