Monday, July 03, 2006

Google Account Authentication and Identity Web Services

Recently Google announced the release of their account authentication API for web applications. In a nutshell, they allowed other web apps to use their account information to login, which is very similar to Single Sign-On.

But the different part of this service from just SSO is Google is providing not only their authentication system, but also their application service endpoints to 3rd parties.

Here I describe simplified sequence of Google's authentication system. First, a web app receives a one-time-valid token from Google through an accessing user. Using this token, the web app queries Google to get further token to access application services. Finally, the token enables the web app to access the user's private information (inbox, schedules), which are kept by the Google's web application services (Gmail, Google Calendar).

Of course it is important to make sure there's a process to obtain user's consent before sending tokens to the web app. In this process, user can check the web app is trustworthy or not, and if he find it is trustworthy, he can allow the accesss to his private information with limited priviledge (e.g. READ ONLY, WRITE is NOT allowed)

In fact, as the words of "service endpoints to 3rd parties" implies, this story is far more related to "mashup" story, rather than "identity" story.

Nowadays almost all mashup services are public. For example, Amazon's search service returns same results if the given conditions are the same. Google Maps doesn't change its map information according to login user. They are only providing non-restricted public web services, whose service interface is not HTML but XML or JavaScript.

Of course some mashuppers which have their own users might mashup their information to the public web services, but the user private information itself is rarely opened to the others so far.

I think this situation is partly caused by the decision of the top exective which regards their user space as their own property, and partly caused by the difficulties to implement privacy system in these services.

Liberty Alliance and other identity federation standards offered to leverage this technical issues. Putting standard protocols, supporting vendors to implement their products, finally they are approaching executives to convince them to adopt their standards.

Although this approach is suceeded in some part of the market - like European mobile careers or American B2B services - their first big picture was "to be an identity infrastructure in all of the web world", and current situation is far from it. They may insist that they're still in the middle of the way, but they are doing same activity already for 5 years. Liberty itself seems no more vivid and not having any passion to change the world.

Let's go back to slight older days. I remember the first company who did want to dominate the web identity world - Microsoft. Their passport is now branded as a failure, but their primary purpose was just same as that of current Google - to offer identity web services to the 3rd parties, over the Microsoft (Google) platform. Passport failed without any strong supports by users. It is maybe because they couldn't offer solutions to the existing privacy concerns (maybe explanations are not sufficient), or because their excessive constration - this fault was later overcomed by Liberty - was not suitable to any existing services.

If Google is doing totally same as Microsoft, why they should repeat this failure history ? Some blogger says "it's like deja vu". But by following reasons I think this service will be supported in certain people.


  1. It is a platform provided by service provider

    • Google already has many attractive services. Developers are definitely going to have an interest in mashuping them. Owing to Google's massive user space, 3rd partiy contributers will receive many incentives.

    • Microsoft, I think, was originally much like platform-oriented, rather than service-oriented. Their services were going to be supplied afterward, benefits obtained by adopting their platform were not so clear for both end users and 3rd parties.



  2. It is a developer-oriented service

    • Different from existing enterprise-oriented authentication services, developers can use the service freely even if they are individuals. By disclaiming service fees essentially and delegating trust resolution to the users, it solves the complex problem around contracts. These openness will attract so many developers, it may cause big explosion in Internet level.

    • Liberty was a little messy for developers. The specification establishment process was open, but actually it was dominated by the famous software vendors. And Liberty promoters took so much focus on topdown approach. While they were eager to conceive conservative exectives, other identity standards or proprietary identity web services had spread in the web world.



  3. Other service providers will follow it

    • Google is now becoming a rare brand which can effect c-level only by its name, at least, in some enterprises which is based on the same profit model as Google (= Ad.). For these companies, Google is not only a threat but also an important reference model. Actually, Yahoo! U.S. has already announced the plan to introduce authentication service.

    • As a result of newcomers in open identity platform field, the business model of that platform will be recognized by other service providers, possibly establishing certain market.





It might be an irony for the people who has been saying that the unicentrism is evil, like Liberty Alliance or recent user-centric identity supporters (they are saying that even Liberty is not giving "liberty" for end users). But the user-centric identity is some kind of emerging one, so they might merge (or absorb) it in the future.


Friday, June 02, 2006

Google AJAX Search and JSON Web Sevice Calling

In this blog I've mentioned about remoting technology using JSON in dynamic script loading (JSONP). It's great because it doesn't require any app server for mashuping services, and scales well.

Among major service providers, first, del.icio.us noticed that and widely introduced for the developers, and then Yahoo implemented same feature but even more sophisticated one. Amazon's xslt feature enables same service. However, the giant google didn't have any service interface for browser applications (except Google Maps) so far.

But finally they introduced 'Google AJAX Search'.

This enables you to embed Ajax-style search box in your site. No proxy server is needed. Static html would be enough to host the service.

I've checked how the Ajax search is working, and found that they are also using JSON with padding technique. Here is a url that is used in background communication (be sure that it is not XMLHttpRequest call!) :

http://www.google.com/uds/GwebSearch?callback=GwebSearch.RawCompletion&lstkp=0&context=0&rsz=small&hl=ja&q=Google&key=internal-documentation&v=0.1


This is a good news for me because I can add this google service to my JSON with padding test page. I'm offering Yahoo, Amazon, del.icio.us, and generic rss2json service test. But while implementing Google's JSONP test, I found that the response interface is a little different from others. So I've slightly modified JSONP stub javascript class with caution, not to affect other services.

This is my JSON with padding test page.
http://www.geocities.jp/stormriders999/jsontest.html



Technorati tags: , , ,

Monday, May 22, 2006

dojo 0.3.0 supports JSONP

Dojo 0.3.0 has released a few days ago (? actually I'm not sure exactly when), and it is said that the release supports JSONP callback style in ScriptSrcIO.

http://archive.dojotoolkit.org/nightly/tests/io/test_ScriptSrcIO.html


So, if you are dojo toolkit user, your AJAX applications can easily connect to the several data sources in the internet - like Yahoo, del.icio.us, Amazon, and Google (Reader) - without consuming your server resources. Yes, it is completely cross-domain AJAX.

Technorati tags: , , ,

Monday, May 01, 2006

Del.icio.us brows.er

I've created another tool : del.icio.us brows.er .

Interface looks like del.icio.us direc.tor, but brows.er has so much difference from direc.tor.

  • No bookmarklet. Just access to the page linked above.

  • No server hosting environement. You can run even in your local PC. Please check it by saving the site as a html doc.

  • No api authentication. All data is gotten via JSON public feeds.

  • Not restricted to your posts. All del.icio.us users' posts are browsable.



Technorati tags: , ,

Friday, April 14, 2006

JSON Feeds of Google Reader

You may know "Google Reader" - kind of online RSS reader - are providing publishing feature for your labeled and publicly opened feeds. You can copy the code and paste it to your blog.

For example, this is my feeds about web 2.0.




If you can check the source HTML code of this page, you might notice that this is some kind of JSON with padding (JSONP) call. Actually, you can check what feed data is sent from Google via following URLs :

http://www.google.com/reader/public/javascript/user/03853986730064725171/label/web2.0?n=5

http://www.google.com/reader/public/javascript/user/03853986730064725171/label/web2.0?n=5&callback=hello

The most intuitive way to see the JSONP services, I think, is to use my JSON with Padding Tester. Arbitrary JSONP services (including Yahoo, del.icio.us, or Amazon with xslt) can be visualized using this tester. Of course it is useful for this Google's JSON service.


Technorati tags: , , , ,