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

=praveen.alavilli =john.panzer