Mashing Up with User-Centric Identity

America Online LLC
John Panzer, Praveen Alavilli

Web 2.0
 Data Sharing  Social Collaboration  Perpetual Beta  Incremental Evolution  Web as a Platform, and  Users in Control

Mashup  Wikipedia: "a website or application that combines content from more than one source into an integrated experience."
API[1]

+ API[2] + … +API[N] Netvibes.com, imified.com, etc…

Role of Identity  Well .. to identify the user for ….
Personalization Authorization

/ Access Control Communication Content Publishing Maintaining Public Identity across Providers

But … it is also  A barrier to entry
Registration

== drop off ID fatigue among users

 Expensive to maintain authentication infrastructure

Online Identity
 Lives moving online  Virtual world identity != physical world identity  Fragmentation of identity across services  Limits value of services (network growth slowed)  Not necessary to bind identity and services together

User-Centric Identity
 Providing User Choice  Privacy protecting  Easy to adopt & use  Allowing collaboration  Supporting the Long Tail Applications  Internet scale

Open Protocols  Community driven
OpenID CardSpace Liberty Yahoo!

(SAML)

 Proprietary
BBAuth Google Account API AOL OpenAuth

Challenges w/ Adoption  Platform/OS dependencies  Programming Language Support  Too many APIs/Protocols  Complex message formats

Challenges w/ User Experience
 Sites with existing user base  Same ID/Password every where  Inconsistent login experience  ‘deputization’ of services  Redirects

Challenges w/ Permission Management
 Different ways to manage user permissions (consent)  Implicit Vs Explicit  Client Vs Server  Distributed Consent Management  Managing given Consents

Security Issues
 XSS  Phishing  Authentication Tokens for Sites Vs Users  Managing Sessions (Client side Vs Server side)  Authentication Tokens validation/invalidation

Privacy Issues
 Same Identifier everywhere  Public Vs Private Personas  Anonymous and Randomized Identities

Reputation Services
 Why Reputation ?  Who owns it ?  based on
 Published  Activity  Collaboration

content with other Services (Mail, IM, etc.)

 Actions to take
 Restricted

Usage limits  Block/Deny requests  Report to Reputation Services

next steps…
 User Experience

Consistency is the “Key” Ask User ! Implied consents are bad

 User Permissions
 

 Report and Consume Reputation  Identity and associated data under user’s control
 

Support multiple public/private identities Support switching Identity Providers

 Adopt protocols that support all (most) of the above

AOL Open Authentication API
• Simple API to Authenticate AOL/AIM/ICQ Users • Light-weight “provisioning” and easy integration/use • Well known/understood Technologies

HTTP/TLS/XML/JSON/…

• Permission (Consent) Management • Secure Token exchange for ‘deputization’ of services

Designed for AOL Open Services Consumption

• Supports Redirect, AJAX, and Direct Models • Also …
• • •

OpenID Provider (OP) OpenID Authentication Token Exchange Extension OpenID Consumer/Relying Party - accepts 3rd party OpenIDs

• STS for CardSpace (in the future)

http://dev.aol.com/openauth

Sign In Page

Permission Request Page

User Permission Management Page

https://my.screenname.aol.com

Ficlets

Q&A

http://dev.aol.com

Contact Info Praveen Alavilli
=praveen.alavilli

John Panzer
=john.panzer

Sign up to vote on this title
UsefulNot useful