Nouncer is a web service, and that all it is. Nouncer is not a web site, as in a destination people go to interact and get information. It has no human accessible pages and is only useful for developers building their own solutions. Of course, it is not the only or first of such facility, but it is unique in that it is trying to use OpenID and OAuth without actually offering any user interface.
The problem is, that both protocols require some level of user interaction, if it is to capture their credentials or request their approval. The challenge is to offer an API that is truly customizable while still using open identity technologies. I have found my way to OAuth when I realized that my plan to use OpenID for Nouncer wasn’t trivial. There was no API way of handing over your OpenID the way you do with HTTP Basic authentication. OAuth solves that.
But still, both protocols are not yet ready for a scenario in which the service provider does not wish to interact with the end user at all. Not even a little bit. Ideally, all this will be done by someone else such as the consumer (the site using Nouncer to build their own site) or the OpenID provider.
For the consumer to provide this, Nouncer must trust it to properly represent the user’s interest, and allow the user real control over their data. Even though Nouncer’s goal is to stay behind the scenes, it is built with the fundamental idea of users owning their own data, regardless of the services built on top of the platform. So trusting the consumer is acceptable, but not in every case. It also adds development cost and complexity to the consumer.
For the OpenID provider to handle use interactions, new extensions are needed to relay more information to the user such as granting access to resources other than identity.
An interesting example is OpenID Simple Registration (SREG). Nouncer uses SREG to update information when the user logs into the service through the consumer. It also uses SREG to fill in some of the blanks when signing up a new user. But while sites with their own user interface can very simply provide a form for any missing information not provided by SREG, Nouncer have to inform the consumer which fields are still missing. This is where Simple Registration stops being simple.
The easy solution, which I consider cheating, is to host a few pages over on the Nouncer side, and perhaps allow the consumer to customize them to look like their own pages. So for example, Nouncer providers a simple page asking for OpenID in case the consumer did not provide it as part of the OAuth flow (in a custom field).
Extensions will go a long way to fix both the user experience and deployment of OpenID and OAuth in new scenarios. There aren’t many services today with the goal to have no user interface components to their platform, and even less APIs using OpenID. Nouncer might just be the first API using OpenID over OAuth as its sole authentication mechanism. But while OAuth extensions are a private matter between the service and its developers, OpenID extensions create a larger issue.
Building solutions that require certain OpenID extensions will create a problem when a user is trying to use an OpenID provider that does not support that particular extension. Such situations will break the fragile interoperability of OpenID and cause real problems in getting it adopted. And let’s not even try to imagine the error codes and how to explain all of this to the end user trying to use their OpenID.
This is not about removing the user from the flow. The users’ presence is critical to ensure they stay in control and manage their own resources. The question is, how do we delegate the delegation interface? For now, I’ll cheat.