Google created a new API. Now what?

   Print.Print
Email.Email weblog link
Blog this.Blog this
Sam Ruby

Sam Ruby
Apr. 12, 2002 08:16 AM
Permalink

Atom feed for this author. RSS 1.0 feed for this author. RSS 2.0 feed for this author.

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.

Announced yesterday was the WS-Security specification.  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.

Arguably 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.  Securely.

Sam Ruby is a prominent software designer who has made significant contributions to many of the Apache Software Foundation's open source software projects and to the standardization of web feeds via his involvement with the Atom web feed standard and the popular feedvalidator.org web service. He currently holds a Senior Technical Staff Member position in the Emerging Technologies Group of IBM.