The Difference between Twitter as Utility and Twitter as IdP

The buzz, and confusion, around the Twitter-iOS integration is incredible, especially among the identirati. It’s created some very interesting twitter discussions, and some huge claims about what this means for Twitter, Apple and the social landscape in general. I’ve now seen a number of articles that equated the WWDC announcement as confirming that “Twitter is now the Identity Provider for Apple“. Since so much of what we’re hearing seems to be speculation, I’m going to wait for today’s debriefing on the integration to provide details before I comment on the implications of the integration (Phil Hunt will be my Bob Woodward on this, doing all the investigative reporting from the event). But I do want to explain the difference I see between Twitter as Utility and Twitter and IdP.

TWITTER AS UTILITY is very similar to how “Email Photo” works when you’re in the Photos app. When you click on the button, the Photos app knows how to call the iOS API to send the picture to the Mail app. From that point on, it is the Mail app that deals with how to send it out as an email, including knowing which account on which email provider (out of many even) to use. The Photos app neither knows nor cares about this. In the Flickr app, an app backed by an online service, when I click on “Email Photo”, the app simply pulls down the URL for the photo and sends that (via the iOS API) to the Mail app. My Flickr service saw nothing about which email provider was used. This is how the “Tweet Photo” button could end up working (except that it doesn’t launch an app but rather an in-built interface to writing up the tweet). Through and after all this, no relationship exists between my Flickr account and my Twitter account. Implication = there is nothing to revoke either.

TWITTER AS IdP is much more involved in not only the app, but in the online service the app represents. The first time I download and launch an app like the LivingSocial app, it will want to associate that app with an account in the LivingSocial service. In a scenario where I’ve never LivingSocial before, it will want me to register for an account. In the current pre iOS 5 world, this involves the app showing me 3 options – “Register for Account”, “Sign In with Twitter”, “Sign In with Facebook”. Clicking on “Sign In with Twitter” would send me through the OAuth dance. If Twitter truly were an IdP in iOS, then this experience would change radically. (Hypothetically) I would instead get the option to “Sign Up with You Twitter Identity” or “Other Options”, and clicking on the first would just get me in, without having to go through the OAuth dance. In fact, if there were an iOS setting that allowed me to set my preference to  always register for services with Twitter (provided the service supports that), then I may never even see the sign up screen. And the backend service now relies on Twitter as my IdP, maybe even being authorized (OAuth permissioning) to interact with it even outside of when I use the app (like if I sign up for a deal while interacting with the website on my computer).

The implications of the latter are pretty vast, in terms of what controls iOS would need to provide users over how to authorize, permission and revoke access. This would be no easy undertaking, and like the Facebook privacy settings we all love to hate, could get very messy and complicated to understand and manage.

Your thoughts? And like I said, I look forward to learning more in today’s event.