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 (SAML)
Proprietary
Yahoo! 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 content
 Activity
 Collaboration 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”

 User Permissions
Ask User !

Implied consents are bad

 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 John Panzer
=john.panzer
=praveen.alavilli