I was driving home from PHP Appalachia the other day and was thinking about how web services and web APIs in general are somewhat limiting. I’ve had some discussions with David at our local tripug.org group, and his company is currently putting together an API for their customers to use. He’s facing a lot of decisions to make in building that, but I’m confident they’ll ultimately do a good job of it. That was probably a bit of a tangent, but it crossed my mind as I was thinking of flickr and other similar web-based services that ultimately hold a lot of your data. We’d talked about (ah yes, that’s why it crossed my mind) the issues of the various web services offering different ways of authenticating external apps through their APIs.
One of the key drawbacks *seems* to be that for most systems, I have to give my username/password to an application to then connect on my behalf. I was putting together a blog publishing system some months back and wanted to be able to connect to various services (blogger, livejournal, xanga, wordpress, etc) to publish from one source (my app). The frustration I had was enormous because all the services were so grounded in ‘years ago’ thinking (yes, I’m getting on a high horse here) but they all required my app to connect with the direct username/password of the author’s blog – effectively, my service had to *become* that person. Ben Ramsey discussed a similar project he was thinking of doing and came across the same inherent limitation.
So, on the drive home I was thinking that the key is having multiple authenticated accounts associated with a main account which are allowed discrete leves of access (read/write/edit/whatever) to discrete islands of data (everything/only archive data/etc). In actuality, this was something that had crossed my mind about a year or so ago, but it wasn’t anything I bothered to write about. Frankly, I’m not sure I could even articulate it as well as I just did above, and I know I didn’t even do a great job there! Let me try again, with a concrete ‘possibility’ example…
My wordpress blog has an area in the control panel for ’3rd party access’. There I can describe which third party apps have access to read/contribute/edit/delete posts or comments on my blog. A third party app ‘permission request’ would be lodged when I or someone else hit a ‘ask permission’ URL on my wordpress blog, identifying itself with a particular key and perhaps a URL, and a description of what it is. In mosts cases, these requests would come in because of something I’d initiated at another service directly.
Once approved, my wordpress blog would allow xmlrpc or SOAP requests with certain payloads to act on the agreed upon pieces of data in my blog. Activities would be logged, and I could revoke or cancel access at any time via my wordpress control panel.
Well, as I was putting together some podcast show notes today, I found that Yahoo! just announced something they call ‘BBAuth’ – browser based authentication – which will allow third party apps to register with Yahoo to gain ‘seamless’ access to Yahoo user’s data, with the permission of the Yahoo user. It’s pretty close to what I was thinking, except that the third party apps have to register first with Yahoo, describing what areas of a Yahoo user’s data they’d want, probably sign/agree to some terms of use, then get a registration key. The BBAuth part comes in to play when a user on a third party service site wants to grant the app access to the Yahoo user’s data. They’d log in to the Yahoo site from the third party site, agree to a data sharing terms of service agreement (probably very CYA in Yahoo’s favor!) then the originating web app is allowed programmatic access to data for that user. More info is at http://developer.yahoo.com.
It’s a nice first idea, but is still something I’d like to see become a common development pattern for more apps. CMS apps would benefit greatly from this sort of thing, I think, as would blogging tools and ecommerce apps. Explicitly granting limited access to discrete third parties (through discrete user/pass) for discrete pieces of data, controlled through a user-oriented web interface, will likely be the direction of the next generation of web services, and I say it’s long overdue already! 
There are more ways to authenticate to web services than just username and passwords. It seems that a lot of the PHP developers think web services are black magic and they do not investigate them as much as other platforms. Honestly, haven written web services in PHP I can’t say that I blame you. The whole purpose of publishing a WSDL is so another langugage can interpret the service, yet the way it is handled in PHP is completely moronic. As a developer you have no idea what is going on. Your only recourse is to print_r($soap) and see what the heck is in it. Definitely lacking features comparitively speaking.
IBM, Sun, Micrsoft and others are working today to solve for such problems and have already solved for them. Today we know these efforts as web services enhanced. SoapHeader authentication is used a lot along with PKI Certificates, X509 certs and Kerberos authentication which supports signing, encrypting and then signing of a SOAP message. Look into Web Services Enhanced 3.0. Docs are published on Microsoft’s web site. All of this is standards based so it doesn’t matter which technology you use. Micrsoft has just jumped out as the front runner of this since they have so much invested in SOAP services (probably becuase they are so easy to build in .Net along with Vista supporting what is known as Windows Communicate Foundation).
In terms of additional authentication take a look at “InfoCard”. It is a new technology that is going to be baked into Vista. The concept is pretty strong and lots of banks and sites are already getting ready to adopting it looking at stronger authentication than just a username and password (it is 2006 for crying outloud and we still use username/passwd’s !)
My $.02.
For end users, without extra technology, the ‘user/pass’ combination will likely be the predominant way forward for the foreseeable future, as they are the easiest for end users to understand. On an app to app basis, others technologies will probably gain traction to the extent that the benefit they provide is greater than the effort required to implement. Just because something is ‘standards based’ doesn’t necessarily help, unless there are no ambiguities in the ‘standard’ as documented. Look at HTML, CSS, and RSS for examples of ‘standards’ which are interpreted differently.
Your only recourse in PHP is *not* to just print_r – you can have a step by step debugger do it for you
Perhaps David could speak to his issue(s?) having to interoperate with .NET-generated created SOAP interfaces to his client’s data. I don’t remember the specifics, but it wasn’t pretty.
For the long lost record, I had considered calling some method like this ‘Remote Permission Framework’ mostly cause ‘RPF’ is a cool acronym
I just want to clarify that this is _not_ a rant. I have only worked with two or three .NET web services, I think C# is an awesome language, and I don’t have any experience programming in .NET on which to base any founded opinion. The below results are most likely the result of an incompetent programmer, but are proof that however tight the abstraction, someone can poke a hole through it.
I did have the occasion to work with a .NET SOAP service which we attempted to consume in Perl and PHP. The WSDL that the service produced was 1) invalid and 2) didn’t list the calls we were instructed to use. On occasion, the service would return error messages that were textual, non-XML and not in SOAP envelopes. Things like ‘OK BOB’ would come back from a call made to the service.
The main part that bothered me was that the WSDL was automatically generated and incomplete and wrong. Secondarily, the need to parse data manually on the return and catch exceptions the SOAP library threw was unnecessary at best. Worst of all, the service in question dealt with processing financial transactions.