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”


Why is this?


Our user agents don’t know us

Browser

Silo A

Browser

Silo B Silo C

Browser


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


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)


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?


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


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


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


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


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

http://www.oracle.com/index.html


Multiple, partial identities

Loyalty

PaymenteGov

Verified Claims


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


Card-based login UX

Click


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


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)


Interoperability demo at RSA 2008


Infocard actors

B

RIdentity Provider (Card

Issuer)

Relying Party (Card Accepter)

User

S

Browser

Selector (Active Cient)

P


Personal card data flow

PersonalCard

B

S

RP


Managed card data flow

points to security

token service

ManagedCard

has

B

S

RP


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


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


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


Interests

Passwords

Addresses

Searches

Social graph

Purchases

Location

Payment cards

Active client as “digital me”


Browser or Appr

Active Client

Browser or App

Browser

Even tighter (and lower latency) integration with browsers & apps

Form fill

Data capture


General purpose Personal Data Store sync & backup; not just a “card roaming” service

Browser or App

Active Client

Active Client

PDS

App

Blinded data


Rich Personal Data Store(s)


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


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


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)


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


App-card admin UI mockup


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


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


Managed Card:

Alice goes to site

B

S

RP


Managed Card:

Selector retrieves policy

Required and

Optional Claims

B

S

RP


Managed Card:

Display cards that match policy

B

S

RP


B

S

Managed Card:

Alice selects a card

RP


Managed Card:

Auth to IdP

B

S

RP


Managed Card:

Generate token

B

S

RP


Managed Card:

Browser sends token

Set of Claims

B

S

RP


Managed Card:

Validate token

B

S

RP


Managed Card:

Alice accesses resource

B

S

RP

Appendix BHow relationship cards

work


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


Personal r-card steady state

A

Continuous connection (RDF, XDI, etc.)

R

B

S

P


Managed r-card initial flow

A

Set of Claims & Ptr

has

ManagedR-Card

R

B

S

P


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


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)

higgins active clients and personal data stores v2

Technology