As a follow on from my previous entry about OpenID in the Zend Framework, I’ve been in brief contact with Dmitry Stogov across a scattering of emails. Dmitry posted his OpenID proposal for the framework over at the Proposals Wiki earlier in the week. I’ll be passing comments on this whenever possible (i.e. whenever the phone stops ringing this weekend ;) ).

The main differences between Dmitry’s code and my own are hard to really explain. Dmitry’s sample code is very brief, to the point, and gets OpenID 1.1 done. There is no OpenID 2.0 compatible consumer since the code omits Yadis, but it should catch most HTML based discovery elements from an OpenID alias. It doesn’t capture everything perfectly however, and there’s still a ton of coding and test work required to get it working robustly. The difference to my library is pretty big as a result. I do a lot of abstraction in my coding so I don’t have a single Consumer class – I have about 5 classes working in unison handling various authentication stages. I also have the cryptographic and math logic split into free standing components (see the PEAR proposals below for example). It’s a heavier set of code which evolved over a much longer time and so naturally covers a lot more of the specification and it’s edge cases.

It’s actually very hard to comment constructively rather than simply handing over my code which probably says a lot more all by itself. I really really need to get my code refactored fully at the weekend so I can slap a New BSD License on it and hand it over – I can’t keep referring to empty air ;) .

Now what’s this about PEAR?

After my weekend blog entry I took onboard Greg Beaver’s prompting in the comments. Greg noted that PEAR was looking for an OpenID implementation. One of the reasons I had for not going to PEAR before was that JanRain (the maintainers of PHP OpenID – a PHP4 library) had a proposal over there. It looks like that proposal has now stalled and JanRain are no longer interested in persuing a PEAR route. Among the listed reasons are the PEAR Coding Standards and the difficulty of migrating the library to PHP5. I think their reasons are a bit odd, but their choice. The PEAR conditions make a lot of sense if you intend setting a high quality standard for code.

Anyway, I’ve agreed to port my OpenID library to PEAR as a PHP5 package. I checked with the mailing list, and the approach I’ve taken in splitting the library across a number of freestanding components hasn’t seen any objections. On the flipside, it does help by providing upgrades to existing PEAR Encryption packages which are not yet migrated to PHP5 versions.

To get the process rolling I have proposed two packages so far: Crypt_HMAC2 and Crypt_DiffieHellman. These are the two cryptographic areas an OpenID Consumer must implement. The code is fairly intact from what would have been the Zend Framework Zend_Crypt_* proposals.

The next PEAR proposal will likely be the heavyweight Services_Yadis, a reflection of a similar proposal for the Zend Framework. Yadis is an XML based service discovery protocol – required for OpenID 2.0 Consumers. In my OpenID implementation it’s also the component solely responsible for managing and validating XRI identities and finding their OpenID required CanonicalID values.

In using PEAR for years, I’ve never proposed a package before. It was quite a pleasant surprise to find out how easy it was. Following the PEAR Coding Standard is already a habit and building example installable packages for a proposal just requires minimal reading of the PEAR_PackageFileManager documentation, which is useful in generating those package.xml files which tells PEAR about the package and install locations of files. I also seem to have joined up to PEAR just in time for a future announcement regarding PEAR2. Travis Swicegood already blogged about this earlier.