the open, social web workshop
DESCRIPTION
Presented by Chris Messina (OpenID Foundation), David Recordon (Six Apart), Joseph Smarr (Plaxo). As evidenced by Barack Obama’s successful presidential campaign, we have clearly entered the age of the social web. This developer-oriented workshop will emphasize the use and application of free, open building blocks for enabling social networking features on your site or service, and provide illuminating insights from some of the key figures creating these technologies.http://en.oreilly.com/oscon2009/public/schedule/detail/8575TRANSCRIPT
THE OPEN, SOCIAL WORKSHOP
Chris Messina • David Recordon • Joseph Smarr • OSCON • July 20, 2009 • San Jose, CA
Who are we?
chrismessina daveman692 jsmarr
*Photo by termie
Who are you?
WELCOME TO THE SOCIAL WEB
It begins with Web 2.0
Photo by Dan Farber
“Web 2.0 is the network as platform, spanning all connected devices; Web 2.0 applications are those that make the most of the intrinsic advantages of that platform:
delivering software as a continually-updated service
that gets better the more people use it, consuming and remixing data from multiple sources, including individual users, while providing their own data and services in a form that allows remixing by others, creating network
effects through an “architecture of participation,” and
going beyond the page metaphor of Web 1.0 to deliver
rich user experiences.”
— Tim O’Reilly, Web 2.0: Compact Definition?
“Web 2.0 is the business revolution in the computer industry
caused by the move to the internet as platform, and an attempt to understand the rules for success on that new
platform. Chief among those rules is this: Build applications
that harness network effects to get better the more people
use them. (This is what I’ve elsewhere called ‘harnessing
collective intelligence.’)”
— Tim O’Reilly
Photo by Dan Farber
The perpetual beta becomes a process for engaging customers.
Share and share-alike data, reusing others’ and providing APIs to your own.
Ignore the distinction between client and server.
On the net, open APIs and standard protocols win.
Lock-in comes from data accrual, owning a namespace or non-standard formats.
Tim O’Reilly’s five rules
Bullshit.
“So what’s the seminal development that’s ushering in the era of
Web 3.0? It’s the real arrival, after years of false predictions,
of the thin client, running clean, simple software, against
cloud-based data and services. The poster children for this new era have been the Apple iPhone and iPod Touch, which have sold 37 million units in less than two years and attracted 35,000 apps and one billion app downloads in just nine months.”
— Walt Mossberg and Kara Swisher, Welcome to Web 3.0
Bullshit.
“After all, Web 2.0 was not a new version of the web, but a name that tried to capture what distinguished the companies that survived the dotcom bust from those that survived, and point
the way forward for new companies entering the market.”
— Tim O’Reilly, responding to Mossberg and Swisher
Photo by Dan Farber
Building blocks of the social web
Who I am
Who I know
What’s going on
Identity
Relationships
Activities
Identity
Relationships
Activities
Trends
The rise of social networking
Photo by Mike Wooldridge
WWW
WWW
icons by iconaholic.com
WWW???
?
??
?
?
icons by iconaholic.com
The iPhone era
Everyware computing
Everyware computing
Photo by Sathish J
“It’s like flying on an iPhone!”
DATA INSIDE!
Growing comfort with real identity
Growing comfort with real identity
Developer tools focusing on social
The perpetual beta becomes a process for engaging customers.
Share and share-alike data, reusing others’ and providing APIs to your own.
Ignore the distinction between client and server.
On the net, open APIs and standard protocols win.
Lock-in comes from data accrual, owning a namespace or non-standard formats.
Tim O’Reilly’s five rules
Photo by Dan Farber
The perpetual beta becomes a process for engaging customers.
Share and share-alike data, reusing others’ and providing APIs to your own.
Ignore the distinction between client and server.
On the net, open APIs and standard protocols win.
Lock-in comes from data accrual, owning a namespace or non-standard formats.
Tim O’Reilly’s five rules
Photo by Dan Farber
• facebook.com/chrismessina
• friendfeed.com/chrismessina
• google.com/profiles/chrismessina
• twitter.com/chrismessina
• facebook.com/chrismessina
• friendfeed.com/chrismessina
• google.com/profiles/chrismessina
• twitter.com/chrismessina
@chrismessina
/chrismessina
Etc.
Mazlow’s Hierarchy of Needs
Esteem
Safety
Self-actualization
Love/belonging
Physiological
self-esteem, confidence, achievement, respect of others,
respect by others
friendship, family, sexual intimacy
security of: body, employment, resources, morality, the family, health, property
breathing, food, water, sex, sleep, homeostasis, excretion
morality, creativity,
spontaneity, problem solving, lack of prejudice,
acceptance of facts
People want to share and be connected
“Of the 1.1 billion people age 15 and older worldwide who accessed the Internet from a home or work location in May 2009, 734.2 million visited at least one social networking site during the month, representing a
penetration of 65 percent of the worldwide Internet audience. [...]
“Social networking has become a popular online pastime not only in mature Internet markets like North America, but also in developing, high-growth Internet markets such as Russia,” said Mike Read, SVP & managing director, comScore Europe. “In a country as geographically large as Russia, social networking represents a way of connecting people from one corner of the country to the other. The highly engaged behavior of social networkers in Russia offers significant opportunity for marketers and advertisers seeking to reach these audiences.”
— comScore, July 2, 2009
*Source: comScore
BUILDING ON THE SOCIAL WEB
How is building today different?
Patterns
On-ramps for new users
Photo by Bridget AMES
Client: OpenID Foundation Prepared by: Randy Reddig ShaderlabOpenID Logo - Revision 3 2007-11-26
Demo!
Large US OpenID Providers
• AOL
• Microsoft (in “developer preview”)
• MySpace
• Yahoo!
Creating your own OpenID Provider
factoryjoe.com +
Using the WordPress OpenID plugin
<html><head>
<link rel="openid2.provider" href="http://factoryjoe.com/openid/server" /><link rel="openid2.local_id" href="http://factoryjoe.com /author/admin/" /><link rel="openid.server" href="http://factoryjoe.com/openid/server" /><link rel="openid.delegate" href="http://factoryjoe.com /author/admin/" />
</head><body>...</body></html>
Delegating to MyOpenID
<html><head>
<link rel="openid2.provider" href="https://www.myopenid.com/server" /><link rel="openid2.local_id" href="https://factoryjoe.myopenid.com/" /><link rel="openid.server" href="https://www.myopenid.com/server" /><link rel="openid.delegate" href="https://factoryjoe.myopenid.com/" />
</head><body>...</body></html>
OpenID Usability
factoryjoe
friendster
Hotmail
elderly
I HATE YOU!!!!!!!!!!!!!!!!!!!!!!!!LADY GAAAGGG
Previous attempts
Emerging work: pop-up flow(shipped by Facebook, Google and JanRain)
http://boogle.com
http://boogle.com/signin
Photo by Timothy Vogel
The NASCAR Problem
• What’s your address?
• What’s your address?
• What’s your phone number?
• What’s your address?
• What’s your phone number?
• What’s your AOL screenname?
• What’s your address?
• What’s your phone number?
• What’s your AOL screenname?
• What’s your email address?
• What’s your address?
• What’s your phone number?
• What’s your AOL screenname?
• What’s your email address?
• What’s your MySpace?
• What’s your address?
• What’s your phone number?
• What’s your AOL screenname?
• What’s your email address?
• What’s your MySpace?
• Twitter?
• What’s your address?
• What’s your phone number?
• What’s your AOL screenname?
• What’s your email address?
• What’s your MySpace?
• Twitter?
• Are you on Facebook?
• What’s your address?
• What’s your phone number?
• What’s your AOL screenname?
• What’s your email address?
• What’s your MySpace?
• Twitter?
• Are you on Facebook?
• What’s your OpenID?
Break
Adding teh social
The Password Anti-pattern
Stopping ReFriend Madness
As Simple as JavaScript
Increasing engagement by *connecting
• Profile (identity, accounts, profiles)
• Relationships (followers, friends, contacts)
• Content (posts, photos, videos, links)
• Activity (poked, bought, shared, blogged)
• Goal: Discovery of people and content
Anatomy of “Connect”
Viewing
Sharing
Virtuous Cycle of Sharing
Portable Contacts API
• Simple JSON API for sharing, filtering and searching contacts between social web sites.
• Implemented as a part of OpenSocial and thus deployed on large sites such as MySpace.
• Integrated with OpenID and OAuth in Gmail.
{ "startIndex": 10, "itemsPerPage": 10, "totalResults": 12, { "id": "703887", "displayName": "Mark Hashimoto", "name": { "familyName": "Hashimoto", "givenName": "Mark" }, "birthday": "0000-01-16", "gender": "male", "drinker": "heavily", "tags": [ "plaxo guy" ], "emails": [ { "value": "[email protected]", "type": "work", "primary": "true" }, { "value": "[email protected]", "type": "home" } ],
"value": "http://sample.site.org/photos/12345.jpg", "type": "thumbnail" } ], "ims": [ { "value": "plaxodev8", "type": "aim" } ], "addresses": [ { "type": "home", "streetAddress": "742 Evergreen Terrace\nSuite 123", "locality": "Springfield", "region": "VT", "postalCode": "12345", "country": "USA", "formatted": "742 Evergreen Terrace\nSuite 123\nSpringfield, VT 12345 USA" } ], "accounts": [ { "domain": "plaxo.com", "userid": "2706" } ] } ]}
filterBy=name&filterOp=startswith&filterValue=Chr
{ "id": "1", "name": "Chris Messina", "urls": [ { "value": "http://factoryjoe.com/blog", "type": "blog" } ] }, { "id": "2", "name": "Joseph Smarr", "emails": [ { "value": "[email protected]", "type": "work", "primary": "true" }, { "value": "[email protected]", "type": "home" } ], }}
filterBy=name&filterOp=startswith&filterValue=Chr
{ "id": "1", "name": "Chris Messina", "urls": [ { "value": "http://factoryjoe.com/blog", "type": "blog" } ] } }
filterBy=email&filterOp=contains&filterValue=plaxo.com
{
{ "id": "2", "name": "Joseph Smarr", "emails": [ { "value": "[email protected]", "type": "work", "primary": "true" }, { "value": "[email protected]", "type": "home" } ], } }
Google’s Social Graph API
Discovery in the cloud
c:\
icon by Seedling Design
http://
icon by Seedling Design
icons by Seedling Design and Fast Icon
http://
icons by Seedling Design, etc
http://
icons by Seedling Design
factoryjoe.com
XRD + LRDDEmerging Work!
<?xml version="1.0" encoding="UTF-8"?><xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)"> <XRD> <Service priority="0"> <Type>http://specs.openid.net/auth/2.0/signon</Type> <Type>http://openid.net/sreg/1.0</Type> <Type>http://openid.net/extensions/sreg/1.1</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/multi-factor</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/multi-factor-physical</Type> <URI>https://pip.verisignlabs.com/server</URI> <LocalID>https://recordond.pip.verisignlabs.com/</LocalID> </Service> </XRD></xrds:XRDS>
OpenID
<?xml version="1.0" encoding="UTF-8"?><xrds:XRDS xmlns:xrds="xri://$xrds" xmlns:openid="http://openid.net/xmlns/1.0" xmlns="xri://$xrd*($v*2.0)"> <XRD version="2.0"> <Type>xri://$xrds*simple</Type> <Service> <Type>http://portablecontacts.net/spec/1.0</Type> <URI>http://pulse.plaxo.com/pulse/pdata/contacts</URI> </Service> <Service priority="0"> <Type>http://specs.openid.net/auth/2.0/signon</Type> <Type>http://openid.net/sreg/1.0</Type> <Type>http://openid.net/extensions/sreg/1.1</Type> <Type>http://schemas.openid.net/pape/policies/2007/06/phishing-resistant</Type> <Type>http://openid.net/srv/ax/1.0</Type> <URI>http://www.myopenid.com/server</URI> <LocalID>http://brian.myopenid.com/</LocalID> </Service> </XRD></xrds:XRDS>
Portable Contacts
How it works
Data access with OAuth
A protocol for developing password-less APIs.
Your valet key for the web.
http://www.slideshare.net/kellan/advanced-oauth-wrangling
Advanced OAuth
Wrangling
Kellan Elliott-McCreaXTech 2008: The Web on the Move
On the desktop
4D56
On the phone
••••••••
The OpenID/OAuth Hybrid
+
T O C T O C
T O C T O C
T O C T O C
T O C T O C
T O C T O C
T O C T O C
T O C T O C
T O C T O C
T O C T O C
T O C T O C
T O C T O C
T O C T O C
T O C T O C
T O C T O C
T O C T O C
T O C T O C
draft D. Balfanz
B. de Medeiros
D. Recordon
Six Apart
J. Smarr
Plaxo
A. Tom
Yahoo
January 7, 2009
OpenID OAuth Extension
Abstract
This draft describes a mechanism to combine an OpenID authentication request with the approval of an OAuth request token.
Table of Contents
1. Requirements notation
2. Terminology
3. Purpose of this Specification
4. Overview
5. Extension Namespace
6. Discovery
7. Before Requesting Authentication - Registration
8. Requesting Authentication
9. Authorizing the OAuth Request
10. Responding to Authentication Requests
11. Obtaining the Access Token
12. General Considerations
13. Security Considerations
14. Normative References
§ Authors' Addresses
1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in .
2. Terminology
Terms emphasized are pre-defined in either the or the specifications.
Combined Consumer:
A web service that is simultaneously an OpenID Relying Party (RP) and an OAuth Consumer.
Combined Provider:
A web service that is simultaneously an OpenID Identity Provider (OP) and an OAuth Service Provider (SP).
3. Purpose of this Specification
The OpenID OAuth Extension describes how to make the OpenID Authentication and OAuth Core specifications work well together. In its
current form, it addresses the use case where the OpenID Provider and OAuth Service Provider are the same service. To provide good
user experience, it is important to present, to the user, a combined authentication and authorization screen for the two protocols.
This extension describes how to embed an OAuth approval request into an OpenID authentication request to permit combined user
approval. For security reasons, the OAuth access token is not returned in the OpenID authentication response. Instead a mechanism to
obtain the access token is provided.
4. Overview
Unlike standard OAuth ( ), the OpenID OAuth Extension does not provision request tokens in a server-to-server request from
the Combined Consumer to the request token endpoint at the Combined Provider. Instead, the Combined Provider returns an already-
approved request token to the Combined Consumer as part of the OpenID authentication response.
The Combined Consumer then exchanges the request token for an access token at the access token endpoint of the Combined Provider,
following standard OAuth practice.
5. Extension Namespace
This protocol is an extension as defined by Section 12 of . The namespace URI for this extension is
"http://specs.openid.net/extensions/oauth/1.0".
All OpenID messages that contain an OpenID OAuth Extension element MUST contain the following extension namespace declaration:
openid.ns.<alias>=http://specs.openid.net/extensions/oauth/1.0
The actual extension namespace alias is determined by the party composing the message in such a manner as to avoid conflicts among
multiple extensions. Throughout this document "oauth" is used as an example for the extension namespace alias.
6. Discovery
Discovery of the OpenID OAuth Extension is achieved via the mechanism described in . The OpenID OAuth Extension
namespace "http://specs.openid.net/extensions/oauth/1.0" SHOULD be listed as an <xrd:Type> child element of the <xrd:Service>
element in the XRDS discovery document.
7. Before Requesting Authentication - Registration
The Combined Consumer and the Combined Provider agree on a consumer key and consumer secret (see ).
The Combined Provider SHOULD in addition obtain, from the Combined Consumer, a list of valid OpenID realms that the Combined
Consumer may use in subsequent authentication requests. The Combined Provider SHOULD verify that the Combined Consumer is
authorized to use those realms.
8. Requesting Authentication
When requesting OpenID Authentication via the protocol mode "checkid_setup" or "checkid_immediate", this extension can be used to
request that the end user authorize an OAuth access token at the same time as an OpenID authentication. This is done by sending the
following parameters as part of the OpenID request. (Note that the use of "oauth" as part of the parameter names here and in
subsequent sections is just an example. See for details.)
openid.ns.oauth
REQUIRED. Value: "http://specs.openid.net/extensions/oauth/1.0".
openid.oauth.consumer
REQUIRED. Value: The consumer key agreed upon in .
openid.oauth.scope
OPTIONAL. Value: A string that encodes, in a way possibly specific to the Combined Provider, one or more scopes for the
OAuth token expected in the authentication response.
9. Authorizing the OAuth Request
If the OpenID OAuth Extension is present in the authentication request, the Combined Provider SHOULD verify that the consumer key
passed in the request is authorized to be used for the realm passed in the request. If this verification succeeds, the Combined Provider
SHOULD determine that delegation of access from a user to the Combined Consumer has been requested.
The Combined Provider SHOULD NOT issue an approved request token unless it has user consent to perform such delegation.
10. Responding to Authentication Requests
If the OpenID authentication request cannot be fulfilled (either in failure mode "setup_needed" or "cancel" as in Sections 10.2.1 and
10.2.2 of ) then the OAuth request SHOULD be considered to fail and the Provider MUST NOT send any OpenID OAuth
Extension values in the response.
The remainder of this section specifies how to handle the OAuth request in cases when the OpenID authentication response is a positive
assertion (Section 10.1 of ).
If the end user does wish to delegate access to the Combined Consumer, the Combined Provider MUST include and MUST sign the
following parameters.
openid.ns.oauth
REQUIRED. Identical value as defined in .
openid.oauth.request_token
REQUIRED. A user-approved request token.
openid.oauth.scope
OPTIONAL. A string that encodes, in a way possibly specific to the Combined Provider, one or more scopes that the returned
request token is valid for. This will typically indicate a subset of the scopes requested in .
To note that the OAuth Authorization was declined or not valid, the Combined Provider SHALL only respond with the parameter
"openid.ns.oauth".
11. Obtaining the Access Token
To exchange the request token for an access token, the Combined Consumer follows Section 6.3.1 of , i.e., it sends an access
token request to the access token endpoint of the Combined Provider. It SHALL use the following values to create the OAuth access
token request:
consumer key
Combined Consumers use the consumer key they established with the Combined Provider in .
consumer secret
Combined Consumers use the consumer secret they established with the Combined Provider in .
OAuth token
Combined Consumers use the request token obtained in .
OAuth token secret
Combined Consumers use the empty string.
The Combined Provider follows Section 6.3.2 to verify the request and either issue the access token or send an error response.
12. General Considerations
The proposal takes the approach to insulate each protocol from the other, both for backwards compatibility as well as to enable OpenID
and OAuth to evolve and incorporate additional features without requiring reviews of the combined usage described here. In particular:
OpenID full compatibility
The OpenID identity provider (OP) MAY safely announce the endpoint supporting the OpenID OAuth Extension to all relying
parties, whether or not they support the extension as well. The use of a separate service-type announcement for Combined
Providers endpoints provides a mechanism for auto-discovery of OAuth capabilities by RPs.
OAuth token compatibility
The OAuth tokens approved via this mechanism MAY be used identically as tokens acquired through alternative mechanisms
(e.g., via standard OAuth) without requiring special considerations either because of functionality or security reasons.
13. Security Considerations
This proposal composes protocols that provide security services (authentication in the case of OpenID, authorization in the case of
OAuth) with the intention that the combined protocol provides both services simultaneously. Since security is not a property generally
preserved by composition, the design takes the approach of encapsulating the OAuth flow within OpenID in a modular way, and applies
the general rule-of-thumb of NOT introducing reliance on the security properties of one protocol for the correctness of the other.
Ultimately, only public scrutiny and review can incrementally provide confidence that the approach described here is sound from a
security perspective.
The following security principles are reflected in this design:
No long-term OAuth secrets hit the browser
The OAuth protocol was designed so that browser-mediated communication is not used to transfer long-term secrets or
capabilities to access data.(Instead, server-to-server calls are used to exchange such secrets). Combined Providers can
preserve this property by making the request_token short-lived, since the request token will be exchanged for an access
token and secret over a server-to-server call.
Imposters cannot retrieve the OAuth access token
While it is possible for a malicious party to fake an OpenID request, including an OpenID request that includes the OpenID
OAuth Extension (the request is not signed, and knowledge of the consumer key and realm is sufficient to cause the
Combined Provider to display an authorization page for that realm/consumer), that malicious party would have to have
knowledge of the consumer secret to exchange the request token for an access token. Note that while secure under
reasonable threat models, this is different from standard OAuth: In standard OAuth, one needs knowledge of both the
consumer key and consumer secret (or, alternatively, of a request token obtained through knowledge of the consumer key
and secret) to cause the Service Provider to display an authorization page for that consumer.
14. Normative References
[OAuth] OAuth Core Workgroup, “OAuth Core 1.0,” December 2007 (HTML).
[OpenID] Openid.net, “OpenID Authentication 2.0 - Final,” December 2007 (HTML, TXT).
[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
Authors' Addresses
Dirk Balfanz (editor) Google, Inc.
Email: [email protected]
Breno de Medeiros (editor) Google, Inc.
Email: [email protected]
David Recordon (editor) Six Apart, Ltd.
Email: [email protected]
Joseph Smarr (editor) Plaxo, Inc.
Email: [email protected]
Allen Tom (editor) Yahoo!, Inc.
Email: [email protected]
[RFC2119]
[OpenID] [OAuth]
[OAuth]
[OpenID]
[OpenID]
[OAuth]
Section 5
Section 7
[OpenID]
[OpenID]
Section 8
Section 8
[OAuth]
Section 7
Section 7
Section 10
2 Clicks Demo!
What Plaxo found
• Better for the user: higher success rate with no password anti-pattern
• Better for the provider: Happy users and no automated data scraping
• Better for the site: Higher conversion rate; more informed social graph
An Open Stack is emerging
Mashups OpenSocial
Attributes OpenID/AX Contacts Portable Contacts
Authentication OpenID/Auth Access Control OAuth
Metadata Discovery YADIS, XRDS-Simple, XRD
Unique Identifiers URLs, email addresses
. . .
As proposed by Johannes Ernst
Evolving the Open Stack
Success stories
“We launched OpenID in March 2008 with Highrise. About 15% of the logins are now using OpenID.”
— David Heinemeier Hansson, 37Signals
“Deployments for their customers – Twitter and Songbird – are seeing OpenID utilization of 20% or more.”
— Eirc Eldon, VentureBeat
Mobile retail software
designed for in-store retail tasks. E.g. stock
counting, receiving etc.www.handpoint.com
Dell Business Computers
Business Computer Powered By Intel®
Core™ 2 Duo On Sale Online, At Dellwww.nz.dell.com
New Zealand Site
Features 130,000 Members. Discover Why
It's So Popular!www.smilecity.co.nz
RECENT JOBS
POWERED BY JOBTHREAD
Mobile retail softwaredesigned for in-store
retail tasks. E.g. stock
counting, receiving etc.www.handpoint.com
Dell BusinessComputersBusiness Computer
Powered By Intel®
Core™ 2 Duo On Sale
Online, At Dellwww.nz.dell.com
New Zealand SiteFeatures 130,000
Members. Discover Why
It's So Popular!www.smilecity.co.nz
Original Thinking in ITIT Director Dennis
Stevenson takes on a
new blog series. Read it
here!Blogs.ITtoolbox.com
Rss 2.0RSS Readers for
Individuals & Businesses.
Get A Free RSS Reader.NewsGator.com/RSS_Readers
TEXT LINK ADS
InteractionDesignerSave people's livesand doctors' time.Design software thatimproves healthcare.careers.epicsystems.com
IBM Virtual Event,March 3–4IBM DynamicInfrastructure VirtualForum. Reduce costsand manage risk.ibm.com/virtualforum
RWW SPONSORS
Grab this swicki from eurekster.com
RWW READERS
Written by Marshall Kirkpatrick / February 10, 2009 2:33 PM / 22 Comments « Prior Post Next Post »
« Prior Post Next Post »
Dell Business Computers
Business Computer Powered By Intel® Core™ 2 Duo On
Sale Online, At Dellwww.nz.dell.com
How To Speed Up Your PC
Get A Free Download That Speeds Up Windows XP
Instantly. Your PC Will…www.PcErrorCleaner.com
New Zealand Site
Features 130,000 Members. Discover Why It's So Popular!www.smilecity.co.nz
Original Thinking in IT
IT Director Dennis Stevenson takes on a new blog series.
Read it here!Blogs.ITtoolbox.com
Comcast Property Sees 92% Success Rate With New
OpenID Method
The most-watched geek event of the day has to be the OpenID UX
(User Experience) Summit, hosted at the Facebook headquaters. The
most discussed moment of the day will surely be the presentation by
Comcast's Plaxo team.
Plaxo and Google have collaborated on an OpenID method that may
represent the solution to OpenID's biggest problems: it's too unknown,
it's too complicated and it's too arduous. Today at the User Experience
Summit, Plaxo announced that early tests of its new OpenID login
system had a 92% success rate - unheard of in the industry. OpenID's usability problems appear
closer than ever to being solved for good.
This experimental method refers to big, known brands where users were already logged in, it
requires zero typing - just two clicks - and it takes advantage of the OpenID authentication
opportunity to get quick permission to leverage the well established OAuth data swap to facilitate
immediate personalization - at the same time, with nothing but 2 clicks required of users.
Plaxo, primarily known for the noxious flood of spam emails it delivered in its early days, is now an
online user activity data stream aggregator owned by telecom giant Comcast. The Plaxo team has
been at the forefront of the new Open Web paradigm best known for the OpenID protocol.
The Flow
The method Plaxo has been testing is called an OpenID/OAuth combo, in collaboration with
Google. What does that mean, in regular terms? It means that Plaxo told users they could log in
with their Gmail accounts as OpenID by clicking a link to open a Gmail window, then Google
asked for permission to hand over user contact data using the OAuth standard protocol. Once
login was confirmed, whether contact data access was granted to Plaxo or not, the Gmail window
closed and users were returned to Plaxo all logged in. No new accounts, no disclosure of Gmail
passwords to Plaxo, no risky account scraping and no need to import or find friends on the new
service before immediate personalization could be offered.
This is a very different flow than most OpenID "relying parties" have followed before - but it won't
be for long.
The Success Rate
Plaxo reported today that it has seen a staggering 92% of users who clicked on the "log-in with
Gmail" button come back to Plaxo with permission to authenticate their identities via Gmail
granted. Of those who returned, another 92% also granted permission for Plaxo to access their
contacts list. Only 8% of the people who clicked to log in with a standards based 3rd party
authentication ended up deciding to bail instead. That's the kind of ease-of-use that people
presumed only Facebook Connect could provide.
When Plaxo engineers moved to turn off the short-term experiment, the business team said no
way.
We expect to see this basic flow get iterated on even further. We hope it will ensure that every
OpenID provider has some exposure and not just the big email providers, and we expect the pop-
up action to be made increasingly unobtrusive.
This could be the day when OpenID became a far more realistic prospect than it has seemed
before.
What an "RP" Wants
View more presentations from johnmccrea. (tags: josephsmarr #openidux)
Posted in Features, Identity, NYT, News and tagged with oauth, openID, usability
Comment Subscribe Print Digg Share
Leave a comment
Sign in to comment on this entry. (Optional)
Related Entries
What Are You Looking At? Google Details Results
of Eye Tracking Study
Google and Plaxo Combine OpenID and OAuth
for Improved Usability
Why Twitter's New Security Solution Could Pave
the Way to a Future Web of Mashups
Mozilla's Test Pilot: A Global Usability Lab for
Firefox
0 TrackBacks
TrackBack URL for this entry: http://www.readwriteweb.com/cgi-bin/mt/mt-tb.cgi/10211
Comments
Subscribe to comments for this post OR Subscribe to comments for all Read/WriteWeb posts
1. I don't really see the utility of OpenID. Lately everything with the "Open" prefix sounds cool,
even if there's no use for it =)
Managers Magazine
Posted by: Alberto López | February 10, 2009 3:40 PM
2. Very exciting demonstration of compelling benefits for end users, website operators, and
OpenID providers. Well done to Google and Plaxo.
Posted by: bkkissel.myopenid.com | February 10, 2009 3:52 PM
3. Maybe I don't entirely understand the innovation here, but isn't most of the simplicity in the
user interface being achieved by concentrating on a single OpenID provider? In other words,
isn't this just swapping Facebook for Google, rather than Facebook for OpenID?
Posted by: jeremiah | February 10, 2009 5:02 PM
4. jeremiah, if that's the case then the big news is just the oauth integration. I don't think this
has to be a case of "simple because choice is removed" - I think that multiple known brands
could be offered as choices with room for any provider. The innovation is in the simple
clicks to authorize information, the use of known entities, etc.
Posted by: Marshall Kirkpatrick | February 10, 2009 5:07 PM
5. This presentation -- and some of the comments left above -- feels much more like marketing
than research. Who cares what the protocols under the covers are? The demonstration
could've been done with LDAP.
There's nothing new here. Of course it's possible to improve the user experience by
requiring(or at least, making it exceptionally difficult not to use) a few major providers. That's
been done a thousand times over.
We're no closer to solving truly distributed federated identity than we were, and this if
anything pushes us actively further away. I want to see interface work can serve the world,
not the one or two big players in one sphere.
Posted by: ndk | February 10, 2009 5:20 PM
6. ndk - thanks for putting that out there. I'd like to see what some of the folks involved have to
say about your comment.
Posted by: Marshall Kirkpatrick | February 10, 2009 5:30 PM
7. @jeremiah, while this experiment was done specifically between Plaxo and Google, I agree
with Marshall that multiple known brands could be involved and that the real innovation was
simplifying and combining the steps of logging in and granting access to your data.
This experiment combines 1) creating a new account on Plaxo and entering profile data, 2)
verifying your email address and 3) granting Plaxo access to your address book. Before the
combination of OpenID and OAuth, you would be sent to Google two or three times: first to
login with your Google Account, second (if you didn't use OpenID) to Gmail to verify your
email address and third to grant Plaxo access to your Gmail address book.
Rather, this experiment with a hybrid of OpenID and OAuth combines these steps so that
the creation of a new account always includes the verification of your email address and
you're telling Google that you wish to provide Plaxo with access to your address book.
Posted by: David Recordon | February 10, 2009 5:40 PM
8. @ndk, I'd love to see an example of this being done with LDAP, including the granting
ongoing access to an API resource (the address book). I obviously strongly disagree with
your view that, "we're no closer to solving truly distributed federated identity than we were,"
but doubt that comments are going to be the best way to understand each other's
viewpoints.
Posted by: David Recordon | February 10, 2009 5:45 PM
9. I agree with ndk. Sure this could be done for other well-known brands... but note that caveat
carefully. Now tell me how having a few known brands be the ones that make OpenID easy
to use is a good thing.
OpenID is still a solution in search of a problem for most individuals. We use our browsers'
ability to remember credentials combined with cookies and a limited set of passwords to
address this. If I only have 1 or 2 username/password combinations to remember anyway...
what's the advantage of OpenID again?
Posted by: rick | February 10, 2009 5:49 PM
10. I think this is a really big deal. (But I'm biased, as I'm involved in it.)
This is the first time we're seeing OpenID that is driving our core business metrics. It's good
for users, good for Plaxo, good for Google, and implemented in a way that can be replicated
by any other sites of the web.
Posted by: John McCrea | February 10, 2009 5:51 PM
11. I obviously strongly disagree with your view that, "we're no closer to solving truly distributed
federated identity than we were," but doubt that comments are going to be the best way to
understand each other's viewpoints.
You're probably right, David, but I'll restate my point more fully for posterity here. Because:
1) It's extremely difficult to craft a good UX for N providers, making the button path -- used
by social bookmarks and the demonstration above alike -- very appealing;
2) The data necessary to build a value proposition, like a contact book, is not available
consistently from all providers;
3) There is no trust framework to support a diversity of providers.
Whatever the protocol under the seams, if the three above points are not comprehensively
addressed, I see an inexorable drift towards the "Top 4" that Joseph describes. Discovery is
the toughest and most important.
I'd love to see an example of this being done with LDAP, including the granting ongoing
access to an API resource (the address book).
This is tangential; I'm just pointing out that I'm not emotionally attached to protocols. They
grow, evolve, and die, but in the end aren't always that different from each other.
If you wanted to get imaginative with LDAP, perhaps one would provision a service DN for
each application, do LDAP auth of the user at the login page, change the user's contact list
ACL to permit reading by the service DN, transmit the username + timestamp to the service
in a query string encrypted using the service's public key, and then perform a simple LDAP
query(an API for retrieving data about a username, after all).
Obviously a dirty hack inferior to application of OAuth + OpenID, vulnerable to a few more
attacks by the service, and LDAP isn't viable for inter-realm use, but it'd work.
Posted by: ndk | February 10, 2009 6:26 PM
12. the username + timestamp
Brainfarted the slightly important "signed" word, sorry. :D But I'd rather not let that distract
from the core issue that rick articulated better than I: the UX being demonstrated here
naturally constricts the OP's to a select few, so I really don't think of it as progress.
Posted by: ndk | February 10, 2009 6:37 PM
13. Jeremiah and ndk what you're missing is that the bridge from identity to authorization to use
the contacts was done through a set of open protocols, Being able to go from an email
address to a known OpenID endpoint was a small part of the steps saved here.
If users can pick an identity provider from a list of obvious suspects or a known highly
correlated one for that site, as well as having a type-in box, this flow means that they will be
able to connect to a rich source of profile and contact information in one go, ratehr then the
multiple stage back and forth currently needed.
Posted by: Kevin Marks | February 10, 2009 11:34 PM
14. Oh sure, the meeting at Facebook as massive implications, our identities will finally be in our
control, the companies that attented will make billions more with that hybrid oauth/openid
thingy, yadda, yadda, yadda...
But without a doubt, the best thing to come from the meeting was this pic:
http://www.flickr.com/photos/wnorris/3270176733
Posted by: Todd | February 11, 2009 3:30 AM
15. ...oh yeah, and on the serious tip:
ndk said:
"...If you wanted to get imaginative with LDAP, perhaps one would provision a service DN
for each application, do LDAP auth of the user at the login page, change the user's contact
list ACL to permit reading by the service DN, transmit the username + timestamp to the
service in a query string encrypted using the service's public key, and then perform a simple
LDAP query(an API for retrieving data about a username, after all)."
Exactly! That's what I want to write an Oil Can script to do, for all Android phone's ( address
books in Android phones automatically sync'ed to Gmail BTW ). Decentralized and spread
out out, no single point of failure.
"...A distributed architecture for social networking? Existing social networks usually employ a
"hub and spoke" model, where the website is the hub of all activity within the network, and
where there is a "client" and a "server". Since all traffic must pass through the hub, that site
may become a bottleneck. Furthermore, each transaction must pass up one spoke to the
hub, and then down another spoke, when the people interacting may be much closer to
each other (in network terms) than either is to the hub site...
There is the opportunity to create an architecture that distributes the load to the devices
sitting in our coats and pockets, rather than solely on massively scalable Web sites. Such an
architecture would require better interoperability between social networking sites and mobile
devices than we have today, and should remove any dependence on an "always-on"
network connection."
http://www.w3.org/2008/09/msnws/papers/nokia-mobile-social-networking.html
Posted by: Todd | February 11, 2009 3:49 AM
16. thanks.
Posted by: söve | February 11, 2009 8:55 AM
17. For some reason I seem to get nervous when something is so wonderful that everyone buys
into it. Nothing is perfect. The real question is what are they not telling you about this new
system. We need enough information to decide if we want something or not. If all we get is
the good side, the other side could be worse than we can handle. This is the same mistake
that too many people made when investing with Madoff! Stop trying to hussle us and tell us
the real deal.
Posted by: Phil "Watching How This Goes" | February 11, 2009 8:57 AM
18. Prior to the work I'm currently doing with OpenID, OAuth, et al, I was deeply involved with
LDAP, SAML, and worked with ndk (commenter above) directly for a number of years. He
makes an excellent point based on this article. Unfortunately, this article covers only a small
facet of what was discussed at the UX Summit yesterday.
I think the thing to take away from the Plaxo numbers that Joseph presented is this: if we
can make the user experience as simple as two button clicks (that's really all it is), the ROI
for relying parties is incredible. The beauty of the Plaxo/Google demonstration was made
possible by open protocols (that really could have been anything, including LDAP), but more
importantly intelligent OP discovery. It demonstrated ONE way of doing intelligent discovery
-- that is, assuming that if the user used Google for their email, then there's a decent
chance that they would want to use Google as an authentication provider. As their numbers
show, this was a pretty accurate (although not 100% true) assumption.
The point is, if we can do intelligent discovery, the payback is huge. The true challenge, and
this is what was left out of the article, but was discussed during the rest of the UX Summit,
is how to do this discovery. No one is suggesting that the Plaxo/Google approach, or even
the "big four buttons" approach is the end-all, be-all solution to discovery. No one is saying
that. Plaxo's demonstration only underscores the importance of discovery, and it's problem
we have yet to solve.
Posted by: willnorris.com | February 11, 2009 2:03 PM
19. @willnorris said "if we can make the user experience as simple as two button clicks (that's
really all it is), the ROI for relying parties is incredible"
I think that's the key. Until yesterday, there had been little public discussion about
streamlining the OpenID login process for those not knowledgeable of what "OpenID" is. At
the end of the day, most users won't know that they're interacting with something that is
using the OpenID protocol, which is the way it should be.
Facebook Connect has proven that engagement rises and that there is a higher rate of new
registrations. The Plaxo example confirms this even more. This is great to see and I think
we are on the verge of a breakthrough which will make all registrations as simple as two-
clicks. This is awesome. OpenID ftw
Posted by: Nick O'Neill | February 11, 2009 2:23 PM
20. No one is suggesting that the Plaxo/Google approach, or even the "big four buttons"
approach is the end-all, be-all solution to discovery. No one is saying that. Plaxo's
demonstration only underscores the importance of discovery, and it's problem we have yet
to solve.
Thanks, Will. Your entire message is very much the right one to carry forward here, and
since I wasn't present, I'm glad to hear that more was present at the summit than just the
"Top 4" buttons.
It'd be great to get more earnest communication on innovative techniques being proposed to
prevent OpenID from falling further into the social bookmarking solution. No such details
have leaked out of the inner circles, and when all we see is presentations like this, the
discomfort of commentators not directly invested in the future of this technology is probably
understandable.
Posted by: ndk | February 11, 2009 2:28 PM
21.
Some really interesting comments.
I have long predicted that the next wave of social networking will be ALL sites offering social
elements so "friending" and commenting and the like is available everywhere.
This, to some degree, is already happening (I spend two hours every morning reading and
commenting all over the web) but it typically requires a separate identity on each site. And if
I wish to make my contacts aware of the article I need to drag their butts over to that
specific site first. This is all a pain.
So socialising the web will become a lot easier if a SINGLE existing identity can be used by
me across the whole web. OpenID offers this. What it doesn't do today, and what Facebook
Connect DOES do, is enable me to easily share what I am doing across the whole web with
my friends and contacts. Well, I say FBC does do it, no one is using it yet...
And a key reason is everyone would like to see something more "Open" allowing that so
they aren't tied into Facebook, which doesn't have a great reputation for protecting
investments for its third party developer partners.
What Plaxo and Google are showing is exciting, but is playing functional catch up with FBC
and will only geat REALLY exciting once they issue some code which you and I can
integrate into our sites to offer the same functionality.
By the way, I agree with the view that is arguably leading us down the wrong road
ultimately, as I would prefer to see a trusted, independent, non-profit body holding identity
and social graph information, which we then "lease" to sites we visit with a few clicks.
Although W3C is putting together a team to investigate this, encouragingly, it is still some
way off.
Ian Hendry
CEO, WeCanDo.BIZ
http://www.wecando.biz
Posted by: Ian Hendry | February 12, 2009 1:51 AM
22. Intereting article and exciting developments between Google and Plaxo. But ... I found the
comments more informative.
I agree with Ian Hendry, we need "a trusted, independent, non-profit body holding identity
and social graph information, which we then "lease" to sites we visit with a few clicks."
"The Plaxo/Google approach, or even the "big four buttons" approach" will become the "the
end-all, be-all solution to discovery." and I'll no longer be able to use my blog as a self-
provisioned OpenID.
Sicne the the user experience weill be "as simple as two button clicks (that's really all it is),
the ROI for relying parties is incredible." - @williamnorris
Posted by: Khürt | February 15, 2009 4:54 AM
Jr. Software Application
Analyst /...
Plano, TX
ASAP Staffing LLC
Applications
Programmer
Austin, TX
Team Int
Network Support
Engineer (706 - 38607)
Smyrna, GA
ASAP Staffing LLC
IT Administrator
McLean, VA
ROCS - Responsible
Outgoing College...
HP-UX System
Administrator (844 -
2131)
Chicago, IL
ASAP Staffing LLC
Travel Channel -
Supervising Producer,...
MD, MD
Cox Communications
Senior Front-
End/UI/AJAX Developer
New York, NY
Large Online Marketing
Firm
MORE JOBS >
POST A JOB >
Want to buy textlinks onReadWriteWeb?
Recent Visitors
You! Join Now.
發霉兔子
Inetgate
Adebuche
tempofeng
matthew s
See all 9,725 members...
Grab This! MyBlogLog
ReadWriteTalk Enterprise Jobwire About Subscribe Contact Advertise
RSS RWW Daily by Email
RSS RWW Weekly Wrap-up
Home Products Trends Best of RWW Archives
ReadWriteWeb
Yahoo! Buzz
advertise.php asp.net 2.0 web config best 10 mobile
contact.php Emerging Technologies Web 2.0 etherpad
fring g1 gender how image search Mediaset
Sues Google notebook Professional Widget Developers
semantic semantic google swicki vertical
search wordpress zoho
POPULAR TAGS
google facebook twitter iphone
microsoft search mobile yahoo
social media music video social
networking apple semantic web
myspace trends advertising rss
youtube friendfeed mobile web
amazon blogging enterprise firefox
data portability social networks
politics android digg lifestreaming
apps marketing adobe enterprise 2.0
security privacy app email startups
obama web apps api browsers cloud
computing news chrome open source
photos web office
Your email address
Your email address
Search ReadWriteWeb
Name
Email Address (required)
URL
Cc. this comment to FriendFeed
Remember personal info?
Comments (You may use HTML tags for style)
Preview Submit
Home | Products | Trends | Company Index | Best of RWW | Archives
ReadWriteWeb | ReadWriteTalk | Enterprise | Jobwire
About | Subscribe | Contact | Advertise
© 2003-2008 ReadWriteWeb
OpenID adoption across the web continues to grow
*Source: Janrain
UserVoice Identity ProvidersSource: Janrain - Why Websites Should Accept Multiple Third Party Identity Account Logins
Interscope Identity ProvidersSource: Janrain - Why Websites Should Accept Multiple Third Party Identity Account Logins
sulit.com.ph Identity ProvidersSource: Janrain - Why Websites Should Accept Multiple Third Party Identity Account Logins
GETTING INVOLVED & CONTRIBUTING
Open source in the cloud era
Yoism: the world’s first open source religion
“The price of freedom is eternal vigilance.”—thomas jefferson
“The price of freedom is eternal vigilance.”—thomas jefferson
our^
Patents, trademarks and copyright
Joining communities
• OpenID Foundation
• Open Web Foundation
• OpenSocial Foundation
• Partuza Project/Shindig
• Activity Streams
• Microformats
• Diso Project
Libraries, frameworks & resources
• Partuza.nl
• Shindig
• Diso Project
• oauth.net/code
• Pinax
CONCLUSION
The open, social web is being built on standards that are free to implement and that encourage competition at the layer of service and user experience.
Q & A
