Background
At the Carson Workshops "Future of Web Apps Summit", Joshua Schacter made a comment in the closing plenary in which he questioned the need for requiring a login ID/password interaction to gain access to web apps, suggesting instead that a model based on the user entering their email address and then having an 'access link' mailed to them with which they could gain access to the site.
This doodle, written on the way home from the summit, runs with that idea, and another idea picked up from the Summit, specifically that a neat app should be good/useful for every other service on the web...
Note that I've bounced this idea around with a couple of other people, and developed it on considerably from the ideas listed here. However, I still haven't managed to persuade anyone to build a demonstrator for me...:-(
If anyone's keen to know more, mail me from the link on the OUseful blog homepage. I'll also try and distill some of the email conversation I've had on the subject and pop it into anopther blog post, err, next weekend probably...
Concept: many web apps require a user to register with them. Frequently, to confirm the identity or existence of the user, a confirmation URL is emailed to the user, which the user must then click on to complete the registration process. This idea is taken one step further in that rather than log in to a service, once registered, using a login ID and password couple, the user simply enters their email address, to which a 'this will log you in' URL is sent. Clicking on that URL, which can only be retrieved from the user's mailbox, then effectively logs the user in to the original app. For convenience, I shall refer to this as a clickIn (" click in") rather than a login. By clickIn into a site, you are logged in to it, as you would be if you had used a login/password means of entry.
Note - the clickIn URL should only be good for a time limited period.
Doodle 1 - Can We Do It With GMail?
Could we use a Gmail RSS feed to somehow implement a system whereby:
1. when the user wants to login to a particular web app, they enter their email as a login ID;
2. the app sends link to this email address, possibly tagged in some way (e.g. with a clickIn tag, via e.g. my.name,clickIn@gmail.com ??), and perhaps with the URL to click on to gain access to the site in the header or in a custom
3. the app opens a window onto GMail, or, better, onto a representation of the RSS feed item corresponding to the clickIn URL?
Doodle 2 - Can We Do It With del.icio.us?
del.icio.us offers third parties users the ability to send (private?) links using the for:username tagging convention. (For this to work, the senders links tagged fro someone need to be private, as do the links in an individuals for:received box.)
Ifhe contents of the for:inbox are private to the user, and can only be viewed by a user who is currently 'logged in' (using a cookie) to del.icio.us. ?Can the API be used to post for:username tagged links.??
1. When a user want to login to a particular web app, they enter their del/icio.us username as login ID;
2. the app posts the clickIn URL to the user's del.icio.us Inbox by tagging it for:username;
3. the app opens a window onto the users del.icio.us Inbox; the user clicks on the clickIn URL that will have appeared there and gains entry to the site.
Doodle 3 - Clicking In
Example snippet from the web app login page:
The logo shows that clickIn is supported.
The app knows how the user wants to clickIn from their user profile (see Doodle 4).
Doodle 4 - Provide Choice
Provide several ways of clickIn-ing(?!). On a 'customer app'. the user preferences need to be augmented with clickIn preferences that can be checked against during a login.
Example snippet from the web app user profile page:
The Login details row would be hidden unless the checkBox was ticked, at which point the details would be revealed.
The place where a clickIn URL is sent to is the clickIn-pit.
Doodle 5 - Generating Revenue
Creating a service in the hope that someone will buy it is stupid - so ways need to be identified early on for monetising any service site.
Several things come to mind:
* Google Ads on every clickIn page - when a user is sent to a clickIn page, they see related ads; 'cusotomer' web apps might not like this...
* ...so make the apps pay for you not to have ads on their clickIn page; or even better...
* ...offer the apps the chance to pay for a customised clickIn page, e..g predominantly styled with their branding.
* Licence clickIns or sell batches of (completed) clickIns to to the web app provider. First n'000 per day are free, to encourage small players to adopt the system.
Doodle 6 - Where's the API?
clickIn as a standalone service could implement a facility very similar to the delicious for tag. The utility arises from providing a single site (i.e. clickIn) that can act as a base for receiving clickIn URLs - i.e. act as a clickIn-pit.
Note that there are two things to distinguish now - firstly, a clickIn URL, which can be sent anywhere (to an email box, to a del.icio.us inbox, for example); and secondly a clickIn-The App web site/web app, which might act as a single location for a particular user to receive their clickIn URLs.
There are a couple of things that need defining here, I think: firstly, a clickIn protocol to regulate how the passing of clickIn URLs works. Secondly, an example clickIn app that could indeed have its own API (more on that later).
The clickIn-The App site itself would require a login, but should maintain a login state in a particular browser via a cookie (as presumably, for example, in the case of del.icio.us) that gets the user into their space within the clickIn site seamlessly (if they have been in there recently enough - the cookie will get renewed each visit).
Doodle 7- Using ClickIn-The App as a Gateway to Web Apps
Aggregation is a feature of Web 2.0, and ClickIn-The App could indeed offer an aggregation service, for example listing all ClickIn-The App registered sites the user has registered with. (Note the revenue opportunity here - advertising an app a user isn't registered with to them...)
1. The user goes to their ClickIn homepage and is presented with logos of the services they are known to be registered with*;
2. The user clicks on a logo or a 'Get ClickIn URL' and a request is sent to that app site with the user's clickIn ID for a clickIn URL;
3. The URL is returned and a login/clickIn option presented to the user;
4. Tais king the clickIn option (either pressing a button, or clicking a link that is conjured up with a bit of DOM manipulation etc.) logs the user into the target app site.
* How would clickIn-The App know what services a user was registered with? This would require collecting preferences from the user. There is an API function here, I think - when a user on a 'customer' web app site registers their details, and sets clickIn-The App as their clickIn URL pit, the customer web app should send a clickIn confirmation URL to clickIn-The App which will on the one hand all the customer app to confirm the clickIn-pit identity of the user (when they click the confirmation link) and on the other register the fact that the user has just subscribed to another service using clickIn.
Doodle 8 - clickBack
The clickIn service does not need to store any personal user information. It simply provides a single site that minimally confirms the clickIn identity of the user. What if clickIn-The App were to store user details, though? Could this then be used to speed up the registration process when the user wanted to register with a new web app?
Imagine storing name information on the clickIn-The App site. If a user wanted to register on a new web app, by entering their clickIn-The App ID in early on, the customer web app could poll the user's clickIn-The App account for personal data.
How would this be done? Using clickBack. clickBack is an area ripe for APIs. in a clickBack scenario, a web app, say, makes a request to clickIn-The App for personal name information about a particular user. The request appears as an enhanced clickIn URL - a clickBack URL - in the user's pit.
The URL that is sent to the pit has an API defined request appended to the end of the URL (e.g. ?rq=personalName). clickIn-The App parses the clickBack URL and spots that info is being requested, If the user clicks on this clickBack URL, the data that was requested is sent back to the polling web app via https (perhaps as a POST - the API would define that).
So - a clickBack URL is then actually a parsed clickIn URL (i.e. parsed by clickIn-The App for example).
When the user goes to their pit and sees the clickBack URL, they may be shown what is being requested and then choose to click it back, or not. The API would define the fieldnames of data that could be sent back etc.
Doodle 9 - The Logo
It's supposed to look a bit like a keyhole...and play with the C and I...!
Doodle 10 - Dregs...
Okay - last thoughts: this service would have to be up 24-7; in the first phase (no clickBack) there is no need to store any user data at all; the service does not guarantee you are who you say you are (i.e. clickIn-The App could be very low down on the Trust stakes, e.g. if you didnlt reuiqre anything for a user to get a clickIn-The App account) - all it does is allow you to use one site to act as a pit for a clickIn URL from another. It would be good to offer potential customer sites example functions/routines in a variety of languages to put clickIn requests easily into their sites (and generate clickIn URLs etc.). There is scope for expansion with clickBack. The service would be of use to large numbers of web apps/sites and users. The data storage requirements are minimal. The user base would grow with the number of web sites/apps that signed up. Users could contribute "I'd like siteX to join up" votes to clickIn-The Project that could be used to put pressure on sites to join up. There are probably precedents (I assume there is an Identity 2.0 group out there?) and lots of good reasons why it wouldn;t work etc. But - it's a low tech solution, not very trustable, but okay for sites where you use low low quality passwords when you want to try them out etc.
As mentioned at the start, the above is pretty much a stream of consciousness typed out on my way home from the summit. It spawned some intersting email threads for the day or two after, and stalled as anything but an idea.
In particular, the discussions through up interesting lines of thought relating to available channels for communicating clickin links (email, bookmarking accounts, chat/IM, widgets and gadgets etc.), anonymity (no need to submit personal info to get a clickin account), usability, spam, growing the userbase, and most of all openness (via an API. In fact, that's all Open Clickin has to be at first - an API. No website is even required. The service is the API...). And a whole lot more...
If anyone has any thoughts/comments on this as something worth prototyping, I'll run the gauntlet of the spammers and leave comments open for a day or two, just in case....
OpenClickIn, aka Login 2.0 - no (other) password required