OpenID in PEAR

Hi all, First up I'd like to express my appreciation for the review process here. After proposing three not exactly simple packages, people took the time to go through them all and provide some very valuable feedback in a very short time frame. Many thanks! As some of you are aware, my current three proposals are externalised portions of a proprietary library for OpenID 2.0 Authentication I pieced together last year. In February, I got around to refactoring parts of it so I could push out an open source release. Originally this was heading for the Zend Framework (PEAR already had an OpenID proposal during last year), but Zend determined they should reply to my request for feedback in June (started proposing this in February on the mailing lists) by announcing their own in-house effort. I won't bore you with my response - Greg found me, noted that JanRain had pulled their proposal, and PEAR was seeking an OpenID library. I hadn't realised that JanRain had pulled out, so it was a pleasant surprise and I ended up here. I'll see where the Zend process goes - my proposals are still around for the ZF, but PEAR is the priority. I expect to propose an OpenID Consumer (sans the Server segment for now) over the weekend. Before doing so I had a few questions. First up, I'm unsure of class name. OpenID 2.0 is geared up for authentication (Auth!) but allows for Server querying, and intra-Server data exchange (Services!) and doesn't enforce any external data storage/method of operation. The services element isn't essential, so I've written code just from a base "OpenID" classname, rather than "Auth_OpenID" (still categorised under "Authentication"). Not sure if this works, is permissable, or should be put elsewhere. Secondly, the proposals (OpenID Consumer, OpenID Server) are not two distinct packages as such. Since both the Consumer and Server likely depend on and share code (notwithstanding the already extracted Crypt/Yadis packages) they are located in the same source tree. So, for example, OpenID_Consumer and OpenID_Server both utilise OpenID_Nonce - there's no other class depth, i.e. no OpenID_Consumer_Nonce and OpenID_Server_Nonce. So, both proposals would refer to the same source code tree. The reason for two proposals, is mainly to split up the review process. I'd much prefer to get the Consumer reviewed, and then integrate the Server after all comments have been accounted for. The Consumer Thirdly, all OpenID proposals will be proposed in an incomplete stage. This isn't to say they won't work, but they will lack features which I've given a low priority, and will therefore not be implemented inside the proposal timeframe. I'd prefer to concentrate on the main elements first, and leave things like a "Stateless Mode" alone for now. Afterall, with Sessions available, statelessness is a rarely used mode for OpenID. This also keeps the code in a simpler state which will make review that much easier. This has been a longish email for a Friday ;). For those who are keen to get their mitts on some sample code (totally undependable in progress stuff), I finally got around to slapping a New BSD License notice on the source code and putting it in a public repository. http://svn.astrumfutura.org/pear/trunk/OpenID/ This is about 95% of the necessary code for an OpenID Consumer - the other 5% is why it's incomplete and may fail the moment you stray from the beaten track. I guess the funny thing with specifications is that it's always the last 5% of code that makes it work - the rest is all useless until then. Regards, Paddy Regards, Paddy Pádraic Brady http://blog.astrumfutura.com http://www.patternsforphp.com ____________________________________________________________________________________ Park yourself in front of a world of choices in alternative vehicles. Visit the Yahoo! Auto Green Center. http://autos.yahoo.com/green_center/