Archive for the 'identity' Category

Advantages of User-Centric Identity

Sunday, March 23rd, 2008

In a world of increasing openness and user-centric -ness (user-centric identity, increasing user-choice, user-controlled data), how do you convince enterprises to give up the data that they guard so dearly? One way to put it may be “it’s happening whether you like it or not, so you might as well go with the flow”. While companies can certainly go with the flow, more forward-thinking corporations may decide to do it more pro-actively, rather than being forced to react.

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?

Monday, January 29th, 2007

From the innovative mind of Simon Willison comes IDProxy:, 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 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!

Browser-based mitigation of phishing attacks

Monday, January 22nd, 2007

The OpenID phishing issue is a hard one to solve, particularly because it aims to:

  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 research1 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 and

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

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

  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

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 becomes just, and it will correctly work for things like, which returns instead of

A sample dialog might look like:

You are submitting a password to a site that may not be safe. Click “continue” to trust this site forever, or “cancel” to return to the current page.

Password will be sent to:
Password will be sent in the clear (unencrypted).


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.

1 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.

Security Restricted Domains Database

Monday, January 22nd, 2007

This was going to be a “Dear LazyWeb” request, but after some research I found what I wanted.

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,, etc.

Well, it turns out that the Mozilla folks needed this list in order to disallow web sites setting cookies for the entire or similar domains. Currently, they block just the TLDs so 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 *, 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.

New site:

Monday, January 15th, 2007

I really shouldn’t blogging that much now that I have three weeks left to pack up and move to Virginia. That’s another story if I get around to blogging it.

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 wiki.

In my little way, I have also created a site ( 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 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?

This blog is OpenID enabled!

Monday, January 15th, 2007

OpenID logo

One thing led to another. After reading my previous entry on “mod_python OpenID Access Control”, Nate Olson contacted me to ask if I tried Alan Castonguay‘s WordPress OpenID plug-in. To which I replied, “no, but I will try it out!”

After upgrading my wordpress to the latest and greatest, and then installing the plug-in, this blog is now OpenID enabled!

You’d need to first get yourself an OpenID URL (better yet, an i-name). There are many OpenID providers out there. Once you have that, you can then comment on this blog (and many other sites) by logging in with your OpenID. If you stay logged in at your OpenID provider, there is no need to type in your password in pesty registration forms as you move across various OpenID enabled sites (Zooomr is one such early adopter.)

mod_python OpenID Access Control

Monday, January 15th, 2007

Since XRI is pretty much in bed with OpenID and NeuStar is an XRI shop, I get to play around with it quite a bit.

Here’s a little success report about using JanRain‘s mpopenid module to protect certain restricted resources served by Apache. It works somewhat like your basic HTTP authentication, but instead of returning a 401 Authorization Required response causing the browser to prompt for username and password, it redirects you to the OpenID login page. Pretty neat eh?

So, here's how we go about doing it.

My ingredients:

Following the recipes in this README file, I was able to set it up with one caveat: Python ElementTree module is a dependency of the Python Yadis library and you need to first install that.

Did I mention that you could login using an I-name?


The following patch for is needed to make i-name login work:

--- mpopenid-1.2.0-pre5/     Tue Nov 21 20:24:53 2006
+++ mpopenid-1.2.0-pre5-wil/ Sun Jan 14 16:12:16 2007
@@ -157,10 +157,17 @@
         url = s.strip()
         if not url:
-        parsed = urlparse.urlparse(url)
-        if not (parsed[0] and parsed[1]):
-            url = 'http://' + url
-        urls.append(urinorm(url))
+        if (url[0:6].lower() == "xri://"):
+            url = url[6:] # strip "xri://"
+        if (url[0] not in "=@!$+"): # doesn't look like an XRI
+            parsed = urlparse.urlparse(url)
+            if not (parsed[0] and parsed[1]):
+                url = 'http://' + url
+            url = urinorm(url)
+        urls.append(url)

     return urls

sxore commenting

Saturday, August 12th, 2006

sxore logo

sxore is an identity and reputation system for blog authors, readers and commenters developed by sxip. As with any respectable web 2.0 services, it is in public (perpetual?) beta. I’ve heard of them before via TechCrunch but have not tried it. With so many new services being reviewed daily, where would you find time for that unless that’s your full-time job?

Our work on XRI somehow introduced me to Keith Grennan at Sxip who mentioned that they’ve successfully integrated i-name authentication in their sxore service – so I decided it to try it.

Everything works as advertised. The sign-up process was a breeze; just entered my i-name =wil, it brought me to my i-broker which authenticated me and kicked me back to where I filled in the URL, an alias and email address. There I am, instantly logged in, without having to stir brain juices to construct yet another password! Such is the power of XRI and OpenID.

Now I’m logged in, it tells me to download and install the sxore WordPress plug-in. Ok, wasn’t expecting that (in fact, I had no idea what the service did before I started!) I followed the instructions to install the plug-in and activated it with the code that was given to me and “claimed my blog”. There were a few manual steps involved there, but you’ve got to appreciate how smooth and pain-free it was. A lot of things actually happened behind the scenes and I’m sure I can’t do it justice. For example, sxore detected my blog publishing platform and provided instructions tailored just for me.

And that’s it! I can assure you that all that took less than 10 minutes.

When you click on the “Leave a comment” link below, you’ll be brought to sxore where you can leave your comment. You can also provide an email address to track replies to your comment, not only on this blog but others that use the sxore commenting system.

UPDATE: Was told that the sxore plug-in will eventually put the comment handling responsibility back into WordPress to take advantage of Akismet for spam filtering. The sxore plug-in will concentrate on the identity and trust instead. Having just gone through the pain of migrating posts and comments from the old blog, I have decided to turn off the sxore plug-in for a while, simply because I want my comments to stay in my database. The plug-in is great though, especially the feature for a commenter to track replies and the reputation system may really help the comment spam problem too but let’s wait for a new version. See the sxore plug-in roadmap for more information.