Google Account Authentication API and Google Calendar GData API enable us to integrate private schedule information with our applications, but they still requires us to deal with their own authentication protocol and host the program in some application server infrastructure.
Although it is read-only access, we can lookup remote feeds directly from browsers if it is provied in JSON style. JSONP is a well-known technique for this kind of JSON remoting.
But we currently don't have any JSON feeds in personalized contents, as far as I know. All JSON feeds in the internet are public - not personalized, accessible from everyone in the world.
Maybe it's because there're some security/privacy concerns. But I'm currently thinking that it would be OK to feed private data in JSON when some appropriate opt-in/out mechanizm is provided.
So, I've implemented JSON feed services for private data - Google Calendar schedule. Now 3rd party applications can get visitors' private calendar information so easily, as far as it is allowed to do that by them.
Please check out the site bellow :
Google Calendar JSON Proxy Service
http://gcal2json.ning.com/
Also there's a sample client application program.
http://www.geocities.jp/stormriders999/gcal_json_client_sample_e.html
Do you think this is really a good personalized web 2.0 service, don't you?
Wednesday, August 30, 2006
Thursday, August 10, 2006
del.icio.us network JSON
del.icio.us has released network badge.
And also we can get JSON data.
http://del.icio.us/feeds/json/network/stomita
JSONP is also supported.
http://del.icio.us/feeds/json/network/stomita?callback=handleNetwork
This feature is not officially announced, though.
And also we can get JSON data.
http://del.icio.us/feeds/json/network/stomita
JSONP is also supported.
http://del.icio.us/feeds/json/network/stomita?callback=handleNetwork
This feature is not officially announced, though.
Thursday, August 03, 2006
Custom Calendar App using Google Authentication API for WebApp
About 1 month ago, Google announced that they opened for 3rd party web apps to access their private data (of cource under the end user's allowance). But somehow I couldn't create any valid apps to access their actual service data. Maybe because Google had a service bug, or I misunderstood their protocol. However, today, I finally found the way to grab the private schedule feed entries from Google Calendar.
http://googleaccount.ning.com/
Click "Your private schedules in Google Calendar", and please say "Accept" when prompted by Google. I'm simply showing your calendar feeds. Not inserting, updating, deleting, and not evilly storing the retrieved information.
You can see the source code if you are a member of ning.
http://googleaccount.ning.com/
Click "Your private schedules in Google Calendar", and please say "Accept" when prompted by Google. I'm simply showing your calendar feeds. Not inserting, updating, deleting, and not evilly storing the retrieved information.
You can see the source code if you are a member of ning.
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.
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.
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.
- 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.
- 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.
- 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
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
Subscribe to:
Posts (Atom)