A common practice among social networking sites is to ask users to import their contacts from one of the big email service providers (e.g. Yahoo! Mail, Hotmail or Gmail) as part of the sign up process. This is often seen as a way to bootstrap the user's social network on the site by telling the user who in their email address book is also a user of the site they have just joined. However, there is one problem with this practice which Jeremy Keith described as the password anti-pattern and I quote

The problems start when web apps start replicating bad design patterns as if they were viruses. I want to call attention to the most egregious of these anti-patterns.

Allowing users to import contact lists from other services is a useful feature. But the means have to justify the ends. Empowering the user to import data through an authentication layer like OAuth is the correct way to export data. On the other hand, asking users to input their email address and password from a third-party site like GMail or Yahoo Mail is completely unacceptable. Here’s why:

It teaches people how to be phished.

The reason these social networks request login credentials for new users is because they log-in to the user's email account and then screen scrape the contents of their address books. For a long time, the argument for doing this has been that the big email services have not given them an alternative and are thus holding user data hostage.

This may have been true once but it isn't anymore. Google has the Contacts Data API, Yahoo! has their Address Book API and Microsoft has the Windows Live Contacts API. Each of these is provides a user-centric authorization model where instead of a user giving their email address and password to random sites, they log-in at their email provider's site and then delegate authority to access their address book to the social network site. 

The only problem that remains is that each site that provides an address book or social graph API is reinventing the wheel both with regards to the delegated auth model they implement and the actual API for retrieving a user's contacts. This means that social networking sites that want to implement a contact import feature have to support a different API and delegated authorization model for each service they want to talk to even though each API and delegated auth model effectively does the same thing.

Just as OAuth has slowly been increasing in buzz as the standard that will sweep away the various proprietary delegated auth models that we have on the Web today, there has been a similar effort underway by a similar set of dedicated individuals intent on standardizing contacts and social graph APIs on the Web. The primary output from this effort is the Portable Contacts API.

I've read been reading latest draft specification of the Portable Contacts API and below are some of the highlights as well as some thoughts on them

• A service's Portable Contacts API endpoint needs to be auto-discoverable using XRDS-Simple (formerly YADIS).

• The API supports either direct authorization where a caller provides a username and password as well as delegated authorization where the caller passes a delegation token obtained by the application out-of-band. The former MUST support HTTP Basic Authentication while the latter MUST support OAuth. My initial thinking is that there must be some kind of mistake and the spec meant to say HTTP Digest Authentication not HTTP Basic Authentication (which is described as insecure in the very RFC that defines at it).

• The API defines a specific URL structure that sites must expose. Specifically /@me/@all which returns all of a user's contacts, /@me/@all/{id} which returns the contact with the given ID, and /@me/@self which returns contact info for the user must all be supported when appended to the base URI that is the Portable Contacts API end point. In general being prescriptive about how services should structure their URI space is to be discouraged as explained in Joe Gregorio's post No Fishing - or - Why 'robots.txt and 'favicon.ico' are bad ideas and shouldn't be emulated but since the service gets to control the base URI via XRDS-Simple this isn't as bad as the situation we have today with robots.txt and favicon.ico

• The API defines a set of query parameters for filtering (filterBy, filterOp & filterValue) and sorting (sortBy & sortOrder) of results. The API wisely acknowledges that it may be infeasible or expensive for services to support these operations and so supporting them is optional. However services MUST indicate which parameters were ignored/not supported when returning responses to requests containing the aforementioned parameters. I definitely like the approach of having services indicate which parameter was ignored in a request because it wasn't supported. However it would be nice to get an explicit mechanism for determining which features are supported by the provider in a without having to resort to seeing which parameters to various API calls were ignored.

• The API also defines query parameters for pagination (startIndex & count). These are pretty straightforward and are also optional to support.

• There are query parameters to indicate which fields to return (fields parameter whose value is a comma delimited list) and what data format to return (format parameter can be either JSON or XML). The definition of the XML format is full of errors but seems to be a simplistic mapping of JSON to XML. It also isn't terribly clear how type information is conveyed in the XML format. It clearly seems like the having the API support XML is currently a half baked afterthought within the spec.

• Each result set begins with a series of numeric values; startIndex, itemsPerPage and totalResults which are taken from OpenSearch followed by a series of entries corresponding to each contact in the users address book.

• The API defines the schema as a contact as the union of fields from the vCard data format and those from OpenSocial. This means a contact can have the basic fields like name, gender and birthday as well as more exotic fields like happiestWhen, profileSong and scaredOf. Interesting data models they are building over there in OpenSocial land. :)

Except for the subpar work with regards to defining an XML serialization for the contacts schema this seems like a decent spec.

If anything, I'm concerned by the growing number of interdependent specs that seem poised to have a significant impact on the Web and yet are being defined outside of formal standards bodies in closed processes funded by big companies. For example, about half of the references in the Portable Contacts API specs are to IETF RFCs while the other half are to specs primarily authored by Google and Yahoo! employees outside of any standards body (OpenSocial, OAuth, OpenSearch, XRDS-Simple, etc). I've previously questioned the rise of semi-closed, vendor driven consortiums in the area of Web specifications given that we have perfectly good and open standards bodies like IETF for defining the Open Web but this led to personal attacks on TechCrunch with no real reasons given for why Web standards need to go in this direction. I find that worrying. 

Now Playing: Madonna - Don't Cry For Me Argentina