The current implementation of binding-gdata (binding-gdata and
binding-gdata-runtime modules) work like this at SCDL file:

*<binding.gdata uri="..." username="..." password="..." serviceType="..."/>*

I have some considerations about that:

1) Obviously, it is not a good idea let the user provide his password as
plain text. Do someone suggest something here to improve the security?

2) The serviceType attribute specifies the type of service that is accessed.
Some possible values are "cl" to Calendar, "mail" to GMail, and "blog" to
Blogger.
The current implementation uses some classes of GData API to access the
services, and this attribute is necessary. However, as the aim of SCA is to
make the user's life easier, I believe that the user should not worry about
which abbreviation matches with which service.

The Google Authentication API for installed applications [1] says that it is
necessary obtain an authorization token for a service by sending a HTTP post
like this:

*POST /accounts/ClientLogin HTTP/1.0*
*Content-type: application/x-www-form-urlencoded*
*accountType=HOSTED_OR_GOOGLE&[EMAIL PROTECTED]
&Passwd=north23AZ&service=cl&source=Gulp-CalGulp-1.05*

So, with the token in your hands, you can interact with the service. But, as
can be observed, it is necessary to know the service type since it is
specified in the header.

On the other hand, when someone access the Gmail, it is required an
authentication, but after that the user can use other google services like
calendar, docs, or blog, without authenticating again. How is it possible?
Or the google uses a unique authorization token  for all services, or for
each service accessed it invokes a new token.

So, one way to eliminate the serviceType attribute from the binding.gdata
tag is deduce the type of the service by the uri given. But, I am not sure
if the uri is a sufficient condition to do it.

Thoughts?


[1] http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html

-- 
Douglas Siqueira Leite
Computer Science Master's degree student of University of Campinas
(Unicamp), Brazil

Reply via email to