Higgins active clients and personal data stores v2

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

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

Why is this?
3

Our user agents don’t know us
Silo A
Silo B
Silo C
Browser
Browser
Browser
4

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

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

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

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

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

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

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

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

Multiple, partial identities
Verified Claims
Loyalty
Payment
eGov
13

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
14

Card-based login UX
Click
15

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

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

Interoperability demo at RSA 2008
18

Interoperability demo at RSA 2008
19

Infocard actors
P
R
Identity Provider (Card Issuer)
Relying Party
(Card Accepter)
B
Browser
S
Selector (Active Cient)
User
20

Personal card data flow
P
R
B
S
Personal
Card
21

Managed card data flow
P
R
points to security token service
B
S
has
Managed
Card
22

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

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

Higgins 2.0 and next gen Active Clients

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

Interests
Searches
Purchases
Passwords
Addresses
Payment cards
Location
Social graph
Active client as “digital me”
27

Even tighter (and lower latency) integration with browsers & apps
Browser or Appr
Browser or App
Browser
Form fill
Data capture
Active Client
28

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

Rich Personal Data Store(s)
30

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

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

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

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

App-card admin UI mockup
35

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

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

Appendix AHow managed cards work

Managed Card:Alice goes to site
P
R
B
S
39

Managed Card: Selector retrieves policy
P
R
Required and Optional Claims
B
S
40

Managed Card: Display cards that match policy
P
R
B
S
41

B
S
Managed Card: Alice selects a card
P
R
42

Managed Card: Auth to IdP
P
R
B
S
43

Managed Card: Generate token
P
R
B
S
44

Managed Card: Browser sends token
P
R
Set of Claims
B
S
45

Managed Card: Validate token
P
R
B
S
46

Managed Card: Alice accesses resource
P
R
B
S
47

Appendix BHow relationship cards work

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

Personal r-card steady state
A
Continuous connection (RDF, XDI, etc.)
R
P
B
S
50

Managed r-card initial flow
A
R
P
Set of Claims & Ptr
B
S
has
Managed
R-Card
51

Managed r-card steady state
Kantara UMA Authorization Manager
A
control
control
control
Continuous connection
R
P
B
S
has
Managed
R-Card
52

Appendix CExample PDS Client API

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

http://www.incontextblog.com	1289
http://translate.googleusercontent.com	4
http://webcache.googleusercontent.com	1
http://dashboard.bloglines.com	1

Higgins active clients and personal data stores v2

by Paul Trevithick

Accessibility

Categories

Upload Details

Usage Rights

4 Embeds 1,295

Statistics

Higgins active clients and personal data stores v2 Presentation Transcript