This was a controlled experiment combining 3 technologies (2 of which from the Open Stack but hybridized) under the hood to create a streamlined signup experience that goes like this:

1. Someone at Plaxo invites you to join by entering your Gmail address
2. You get an invitation email from Plaxo
3. You click on the link
4. Plaxo knows that you’re a GMail user (and likely still signed in), so it presents you with the following screen:
   
   I believe that since Plaxo already has your Gmail address, it is already somehow encoded in here to save you from having to type it in, but I haven’t tried it so I’m not sure
5. Clicking “Sign up with my Google Account” brings you over to Google with the following screen:
   
6. Clicking “Continue Sign-in” tells Plaxo that you are indeed the holder of the Gmail address, at the same time authorizing Plaxo to import your address book from Google.
7. That’s it! You’re signed up to Plaxo and your Gmail address book is available in Plaxo.

The result was a staggering 92% return rate (from the Google authorization confirmation screen above), of which 92% continued with the sign up and allowed Plaxo to import their contacts from their Google address book. The results were so impressive that Plaxo’s business folks stopped the tech folks from turning off the experiment!

Indeed these results are impressive by today’s standard of endless signup forms and social networking fatigue. I would whole-heartedly agree that through this clever experiment, Plaxo has met their goals of making it better for the user, the identity provider, as well as the relying site.

The technologies that made these possible were:

• OpenID for proving who you are (to Plaxo that you do indeed own the GMail address.)
• OAuth (implemented as an extension to OpenID) was used to grant Plaxo access to your contacts stored on Google; and
• Google Contacts API for actually importing them into Plaxo (would be nice to see Portable Contacts being adopted by Google)

Individually, those technologies are good at what they’re designed to do but when combined with a simple hint such as “the user is a GMail account holder, and is probably still signed in to the service”, it could be very powerful.

Still, my biggest takeaway from the slides are:

• 17% (of Plaxo signups) come from GMail account holders; and
• 73% come from the top 4 (Yahoo, Microsoft, Google, and AOL)
• all of them being OpenID Providers

This shows that you can already take advantage of the fact that a large percentage of users already own an OpenID, who may be more willing to sign up to your service than they otherwise wouldn’t have if faced with another tedious registration form.

While many (including myself) have criticized OpenID that there are more providers than relying parties, Plaxo has proven (with impressive numbers) that with a little ingenuity and optimization of UX, sites can reap the benefits of being an RP!

No related posts.

Knowing that mobile usability is an important topic for OpenID implementors and users, and the rest of world probably has a lot to learn from the Japanese mobile ecosystem, I decided to exercise my Japanese skills and extract some points out of the slides (no, I’m not going to, nor qualified enough to do a full translation. Try Google for that). Please note that this is merely a best-effort translation and any error you find is likely to come from my ignorance.

Translated version follows the actual presentation:

• Considering Mobile OpenID
  • Taking into account Japan’s unique mobile scenario, explore the feasibility and methods of implementing mobile OpenID
  • Investigate if the protocol needs to be modified
  • Look at ways to make use of mobile characteristics to enhance usability
• Limitations and Characteristics of Mobile (Devices)
  • Technical Limitations
    • maximum URL length
    • Cookies support
    • IP address blocks and individual identification number (are we talking about carrier gateway IPs and identification headers?)
  • Device Limitations
    • manual URL entry – no way
    • manual ID/password input seems too difficult
• Maximum URL Length — Carrier Restrictions
  • DoCoMo
    • According to “NTT DoCoMo’s standard / guide for common device capabilities”…
    • Encoded URL maximum length = 512 bytes
  • au
    • From Open Appli (Java)
      • Maximum 256 bytes and ASCII only
      • Since this is only for “Open Appli (Java)” stuff, this source may not be reliable
  • SoftBank
    • From Web & Network Technical Information / Development Tool -> HTML Chapter – 2.5.8 URI Restrictions
      • Roughly 1024 bytes
      • Since this is only for “Open Appli (Java)” stuff, this source may not be reliable
  • Summary: Assume 256 bytes
    • Surprisingly small – is that ok?
    • As for au, since source code is in Java, should assume at most 512 bytes
• URL Length — Practical Observation
  • Logging in to pibb using myopenid (with SREG)
    • checkid_setup > 567 bytes
    • id_res > 921 bytes
    • checkid_immediate > 430 bytes
• URL Length — Think Harder
  • UA is used for Indirect Communication, so we only need to consider checkid_setup/checkid_immediate, id_res/setup_needed/cancel
  • checkid_* authentication requests can be done using GET or POST. With POST requests, the URL parameters go into the request body.
  • id_res/setup_needed/cancel comes in the form of HTTP redirect, so GET requests only
  • Empirically: id_res parameters requires a combined size of 728 bytes + the URL endpoint itself.
• Content Body Limitation for POST
  • According to ziguzagu: minimum 5KB (for DoCoMo PDC) => should be sufficient
  • we still need to solve the problem of indirect communication: id_res requires a lot of parameters
• Tackling id_res
  • Basics: OP attaches the authentication result as query parameters to the return_to URL and redirects the UA to it. Do we need anything other than the following for signature verification?
    • openid.mode
    • openid.ns
    • openid.response_nonce
    • openid.assoc_handle
    • openid.signed
    • openid.sig
  • According to OpenID Authentication 2.0, Section 11 “Verifying Assertion”:
    • The following steps are taken
      1. Verifying return_to URL
      2. Verifying discovered information
      3. Checking the nonce
      4. Verifying Signatures
    • Are the first two steps absolutely necessary?
    • The basic goal is to verify the data from the OP via indirect communication, it might be good enough to verify signature + nonce in this step?
    • If we had the ability to verify signature in check_authentication, that might work?
  • Therefore, adding mode, signed, sig, response_nonce to the URL, we get 468 bytes!
  • Moreover, if we delegate everything to the OP, we only need response_nonce and op_endpoint => 289 bytes.
  • Conclusion
    • Minimize id_res as much as possible
    • If we have a method to ask the OP via direct communication (keying off response_nonce), that would work.
    • We could also obtain parameters like identity and claimed_id from the OP in the same vein
• Cookie support in Mobile
  • DoCoMo doesn’t support cookies in the first place
  • au has separate secure/non-secure characteristics (?), and there’s a pitfall in using cookies in non-secure mode. (Translator’s note: Not quite sure what this means)
  • For Softbank, one cannot access cookies in SSL realm in non-SSL pages (much like the secure-characteristic operation)
  • Therefore, cookies are not quite useful for us
• The way that mobile web security works (Translator’s note: heavily interpreted)
  • There are published IP blocks that each mobile carrier uses
  • Unique identification number for the device/subscriber can be provided to the sites (via HTTP header). Used with published IP block, this is an effective way to identify a returning user.
  • Generally, it’s better to obtain the subscriber ID rather than device ID
    • imode ID
    • EZ-number
    • x-jphone-uid
  • Instead of cookies, device/subscriber IDs are used for session management
  • The availability of device/subscriber ID also eases the login process considerably at the OP’s end (during checkid_setup/checkid_immediate)
• What’s possible with Mobile OpenID
  • Unified identity for PC and mobile world
  • Possible ways to link the PC and mobile
    • enabling mobile to as your private information store
    • enabling mobile for settling payment
• Summary
  • There are challenges:
    • Maximum URL length problem
      • First, URL length needs to be shortened
      • Still, without fixing the protocol, we could exceed the URL length limit => counting on =nat for OpenID Authentication 2.1
    • Unique identification + IP — increases the convenience of using OpenID on mobile, but one must always remember to update the IP blocks lists.
  • Looking forward to more active discussions on Mobile OpenID next year

No related posts.

The request from Emanuel came almost serendipitously 2 days after =les nonchalantly asked me if I had plans to update it to FF3, to which I answered “one of these days.”

New in this version are 2 patches from Michael Krelin which adds detection of URIs for more OpenID versions, and the handling of append attribute values. Changelog for the patches are available at his git repository.
Thanks, Michael!

Due to what seems like a new security restriction that protocol handlers are not allowed to link to chrome URIs, I can’t seem to get it to load the CSS and icons from the chrome any more. Therefore, those files are now hosted remotely at xrid.net so if you see requests to that host, please don’t be alarmed.

No related posts.

There were some talks about how VRM relates to DataPortability on the DataPortability-Public mailing list. In particular, this excerpt of a blog post from Adriana Lukas sums up the “What’s in it for business” aspect very well:

What’s in it for businesses?

We live in an increasingly decentralized world with more customer choice, yet vendors continue to fiercely collect and control customer data and exploit the opportunities therein. The ultimate goal of VRM is better relationships between customers and vendors, by considering and constructing tools that put the customer in control of their data and ultimately their relationships with other individuals, companies and institutions.

Benefits of ‘letting go’ of customer data:

• Customers share the burden of storing and protecting the data – eases compliance, privacy & security concerns
• Increased access to information about customers – direct benefits to the customer to share more data rather than less.
• New services from previously unavailable access to customer data

The first bullet is a good point that I had never thought about, and is a very practical benefit. The second point is a classic example of “less-is-more”; maintain less control, and gain more in return. The third point being direct consequence of the second.

When will we see the first product that presents a holistic solution with tangible benefits of VRM to companies, as well as integration with / transition from their existing CRM systems?

No related posts.

jchristabelle: OpenID真的很難記，我又忘了我的。

which translates to:

OpenID is really hard to remember, I forgot mine again.

I have shared that sentiment before, when I tried to login to my Plaxo account and couldn’t for the life of me remember which one it was that I first used to associate my account. Granted that, in my case, I have many OpenID URIs because I’ve been so involved in the implementation. However, it is true that the OP:RP ratio is still too high (counting Blogger as a single RP rather than thousands of OpenID-ready spam blogs.)

I think it is inevitable that in future most users will have at least a handful of OpenID URIs. One can easily imagine getting one from each webmail/IM provider, personal i-name or domain name, social networks, etc. It may just be one of those annoyances we have to live with. Or maybe users will just remember the brands that stick, and click on the “Sign in with my Yahoo! ID” button instead.

I don’t have a solution here, just relaying the message.

p.s. Incidentally, geeks are of course still able to use URIs within their control (personal domain) to delegate to another OP (e.g. Yahoo) and switch OP at anytime while keeping the original URIs. For example, here’s what I use.

No related posts.

What I learned from this discussion thread is that James Walker from Bryght has been working on another OpenID module that is intended for inclusion into Drupal 6 core distribution, without using JanRain’s library. There are apparently things that Drupal-heads don’t like about the JanRain’s library, licensing may be one of the issues.

So I pulled the DRUPAL-5 codebase from CVS and installed it, then installed the 5.x-1.x-dev snapshot tarball to test it out. First thing I noticed was that it doesn’t support XRI, and I really didn’t expect it to. Then, when I tried logging in with my dready.org identifier, it wouldn’t work because I delegated it to my myopenid.com account. So, it doesn’t support delegate either.

Then I spent a few hours getting rudimentary XRI support into it, and made it work with delegates. Few days later, I realized that this was only a snapshot and the module is in the Drupal contributions repository. So, I threw away my installation but kept the patch I made of the 5.x-1.x-dev snapshot and started anew. The result is a patch that works with the Drupal CVS trunk as of today.

The changes are:
1. When a first-time user is authenticated, a local account is created but no role was specified. Modified the module to add the ‘authenticated user’ role to the user.
2. XRI support. This is very rudimentary and does not support canonical ID yet, but shouldn’t be hard to implement.
3. Delegate support. In OpenID 2.0, the submitted identifier (URL) is passed to the OP as the openid.claimed_id parameter, while the delegate, if present, is sent as openid.identifier.
4. In the meantime, I noticed that the while the URL normalization conforms to the OpenID Authentication 2.0 implementor’s draft 11 specification, it treats http://dready.org and http://dready.org/ (with trailing slash) as different identifiers. Well, they should really be the same as RFC3986 says that for HTTP, an empty path is equivalent to “/”. This normalization rule was reflected in rev 294 of the spec.

Of course this is only a *very* rough patch (no pun intended). I have never hacked Drupal before, and haven’t read much of its coding styles though I tried to follow the conventions in the original code. I do hope that at least parts of it can be integrated into the module though.

My development environment is here: http://dready.org/drupal/. Feel free to try it out.

No related posts.

idproxy.net, launched today, is my attempt at speeding up the process. It uses Yahoo!’s Browser-Based Authentication API to allow you to sign in with a Yahoo! account, then lets you create one or more OpenIDs (of the form something.idproxy.net) to use with sites that support the OpenID standard.

Basically, it’s an OP that authenticates against Yahoo – call it an intermediate IdP, Proxy OpenID Provider, OpenID-Yahoo bridge, whatever.. it rocks!

No related posts.

1. be user-friendly, i.e. it should pass the mother-in-law test; and
2. work on the web platform without special software or browser plugin

So, why is this suddenly a problem?

Not really, phishing is a perennial problem on the Internet that researchers and developers have been trying to solve for many years now. OpenID just accentuates it because RPs are unregulated. You don’t need any agreement with any OP, essentially anyone can set up a web site and put the OpenID login button. If OpenID takes off, RP sites will grow like ’shrooms and user will get used to the idea that if they see the OpenID logo, they can type their URL to login. This only makes it harder for users to discern the good RPs from the bad ones.

This is really a social problem, and not a fault of the OpenID protocol. Users need only to trust their OP, and not the RPs that they interact with. If a rogue RP sends you to a page the poses as your OP but the URL doesn’t match your OP’s, you bail out. Doesn’t that sound simple? Well, the cold hard fact is that phishing works and there are research¹ to prove that people get tricked very easily.

Numerous ideas to mitigate phishing attacks have been floating around the OpenID list and on the OpenID mini-blogsphere. Ben Laurie argues for a client-side solution:

Authentication on the web is broken, and has been for a long time. The OpenID fanboys want OpenID to work on any old platform using only standard software, and so therefore are doomed to live in the world of broken authentication. This is fine if what you protect with your OpenID is worthless, but it seems clear that these types of protocol are going to be used to authenticate for things of value.

…

This is the root of the problem: if you want to protect anything of value, you have to do better than existing Web solutions. You need better client-side software.

The picture is not so sunny, however, because most users:

• won’t know / bother to install specialized plug-in or upgrade their browsers unless they’re forced to
• won’t know the difference between citibank.com/signon and citibank.com-banking-foobar.com

And even if they installed those anti-phishing toolbars and what not, they still fall for it!

While I can’t decipher the wirings of the mums-and-dads who fall prey for phishing attacks, I know that I get lazy sometimes and just don’t bother. Then I remember this little trick that Firefox introduced to ensure that users get the warning before installing extensions — Introduce a delay in the dialog box before it can be dismissed. That sort of worked for me, at least for that 5 seconds I can’t click so I might as well read a little.

So, here’s an idea for a browser (or plug-in) implementation:

FUNCTION form.onsubmit()
  IF !form.contains-password-field()
    RETURN ok
  END IF

  IF form.action.domain IN trusted-domains
    RETURN ok
  END IF

  SHOW WARNING-DIALOG (delayed-dismissal=5 secs)

  IF continue-button.clicked
    ADD form.action.domain TO trusted-domains
    RETURN ok
  ELSE // cancel-button.clicked
    RETURN not-ok
  END IF
END FUNCTION

The idea is that you should only submit passwords to sites that you have previously added to the trusted-domains list. This idea is not new, and has been proposed by several on the OpenID list.

Where I think could really make a difference is the way in which WARNING-DIALOG is constructed. It should contain the following:

• If the current page and the form target page are on different “effective domain”, emit warning. There are legitimate use cases for this, and we don’t want to overemphasize it, but it should raise suspicion.
• Display the “effective domain” of the form prominently.
• If the form target is not a HTTPS URL, emit warning.
• Warn the user that the target is not known to the browser to be trusted, and that this could be a sign of phishing.
• A continue button that is greyed out for 5 seconds to force the user to read the above information.
• A cancel button that is focused by default so hitting enter will dismiss the dialog and cancel the request.

An “effective domain” as I call it is defined as the DNS name in the URL stripped of insignificant parts. This basically means that we can use Mozilla’s Effective TLD Service that I blogged about earlier to summarize a URL for display to the user so that us.rd.yahoo.com becomes just yahoo.com, and it will correctly work for things like www.netbank.com.au, which returns netbank.com.au instead of com.au.

A sample dialog might look like:

There are a few advantages to this proposal:

• it works on all password forms, not just for OpenID
• it forcefully disrupts the flow of the user and the delay may help the user to be more cautious

The downsides are:

• it only works for password phishing, other information such as credit card numbers will go through without warning
• phisher can replace the password input field with javascript / DHTML / flash to bypass the check

Even with these restrictions, I still think that it brings significant value in terms of mitigating password phishing attacks. This is of course very raw and there is much room for improvement. All comments and suggestions are welcome.

¹ Thanks to Mike Beltzner for the links to these phishing research papers.

UPDATE: Kim Cameron’s latest blog post about Integrating OpenID and CardSpace has some nice pictures of the modal OpenID phishing attack scenario.

Related posts:

1. Optimizing Autocomplete by Utilizing Browser Cache Say you have a snazzy AJAXified autocomplete field that gives instantaneous feedback to the user as she types — perhaps...

Recent discussions about security and phishing on the OpenID list got me thinking about the problem space.

DNS plays a critical role in the security of OpenID because

1. URL is the identifier type used
2. User should only trust the OP with which he/she has an account with.

The “Phishing and OpenID” discussions on the OpenID list actually hinges on point #2 above. Ben Laurie wrote about it here. In short, OpenID opens the door for a malicious RP to send a user to a spoofed OP-lookalike and collect his/her password.

Back to DNS. I have, on numerous occasions in the past, tried to look for a list of domains where registrations are open for public. This varies from TLD to TLD, e.g. .biz accepts registration directly on the second level, .us also does but delegates two-letter subdomains to US states, and .uk only accepts registrations on the third level after .co.uk, .ac.uk, etc.

Well, it turns out that the Mozilla folks needed this list in order to disallow web sites setting cookies for the entire .co.uk or similar domains. Currently, they block just the TLDs so example.com cannot set a cookie for .com, but 2nd level onwards domain cookies are allowed. This could easily cause cookies to be stolen by any site rooted in the same domain.

So, this advisory started this bugzilla entry at Mozilla and it eventually led to the creation of this API and this list (see attachment). They call it the “Effective TLD” list, which is really a misnomer because they are not necessary just TLDs. It was decided in the bug discussions that the term “effective TLD” is easier to digest that anything else, though I’d prefer to call it “Security Restricted Domains”. Whatever, as long as it gives me the content I want.

Many will probably criticize Mozilla for creating yet another list that gets stale the moment it is created. Indeed, TLDs get created and 2LDs within TLDs are introduced and deprecated so often that such a list will be hard to maintain. Moreover, many organizations assign names to registrants at a level that doesn’t involve the TLD registry. Examples include CentralNIC’s .<country-code>.com and *.blogspot.com, and countless others. Add to it the introduction of IDN TLD may well be in less than 2 years. Keeping a definitive list is not feasible. Nevertheless, I would argue that depending on your needs, this list could still be very valuable, as is the case with the cookie problem that they are trying to solve.

So, what has this got to do with OpenID? I shall leave that to a different post.

No related posts.

Recently on the OpenID mailing list, many people are asking for a free i-name to play around with, research and develop software against. Global i-names cost USD20 per year but if you just want to evaluate the technology, you can get a community i-name for free. A community i-name is analogous to subdomains in the DNS world. A global i-name is something like @neustar or =wil. A community i-name has an extra subsegment tagged to the end e.g. @neustar*william.tan.

The i-name / XRI community has awakened to the challenge that we need to provide more support and documentation to the developer community, and our response is the dev.inames.net wiki.

In my little way, I have also created a site (http://xrid.net/) to allow developers to experiment with XRI resolution and Yadis by providing free community i-names under @xrid. The site allows you to have unlimited community i-names (you can even host your own like @xrid*wil*work), and link them to authorities (identities) in any way you like, and most importantly, edit XRDS documents that will be served by the auth.xrid.net authority resolution server.

So, if you’re a developer interested in experimenting with XRI technologies, get your free @xrid community i-name here.

(Note: you may be curious as to why @xrid. Well, XRID was an earlier incarnation of the XRD which is a recursive acronym for “XRI Descriptor”. Later, it was decided that we don’t want to tie the XRDS document format to just being used in XRI’s (e.g. Yadis uses XRDS documents.)

Did I mention that you can login with an OpenID too?

No related posts.