To explore that question, first one must understand what the Google API
provides. In order to use the new Google API, you need to create a Google
account in order to obtain a license key. That license key must be
passed on every Google API call. This key is passed in the clear.
What can happen if somebody captures this key? Well, I guess they can
issue queries. Perhaps they can even deny you service for the rest of the
day. If they do so, this likely will be noticed, and if repeated, they are
in danger of being caught. To many, the risks are acceptable, and a simple
key is an adequate solution.
All this time, your usage is limited to the Terms
and Conditions. What they essentially say is experiment, play, and
develop; but if you want to create a commercial service, you need to get prior written
consent from Google. Fair enough.
Now lets assume that somebody pursues this. At this point, the game
changes. Neither party will be particularly amused if the key that is used
for other purposes by a third party.
There are alternatives that may be more appropriate for commercial use than a
simple user key. Alternatives such as X.509 certificates, Kerberos
tickets, and security tokens from mobile devices. It may even be
appropriate to have these tokens cryptographically signed by a third party.
yesterday was the WS-Security
The stated goal of WS-Security is to enable applications to construct secure SOAP message exchanges.
It does this by providing three main mechanisms: security token propagation, message integrity, and message confidentiality.
the most important sentence is the document is as follows:
This document supercedes existing web services security specifications from IBM and Microsoft including SOAP-SEC; Microsoft’s WS-Security and WS-License; and IBM’s security token and encryption documents.
By standardizing on a common vocabulary, we can achieve
interoperability. The result is a loosely-coupled,
language-neutral, platform-independent way of linking applications.