[OpenID] Is there interest in such a Perl module

[Martin Foster]

While looking at the OpenID 1.x spec, I sought out Perl modules that 
would do the necessary tasks necessary to get the job done.  This 
included things like:

   Crypt::DH
   Crypt::DSA
   Digest::HMAC_SHA1
   Net::OpenID::Consumer
   Net::OpenID::Server

The list is fairly extensive (and that's not all of them) and no single 
module provides the coder with all the tools necessary.  e.g. Crypt::DH 
handles a good part of the key calculations and extraction but fails to 
provide key generation.  Crypt::DSA on the other hand, generates the 
keys but does not do the extraction and while similar as the former, 
they are not compatible even if they are from the same author.

As a result, I cobbled together my own module called Crypt::OpenID which 
is a collection of tools necessary to run a 1.x implementation with SHA1 
HMAC and of course DH key exchange.

So what does Crypt::OpenID do?

   - Provides functions in clear names such as 'make_shared' and 'btwoc'
     to work in conjunction with the spec;
   - Heavily commented so changes can be done without having to decipher
     the code;
   - Generates keys using OpenSSL, pre-defined PEM files, Crypt::Random
     or falls onto the spec default;
   - Manages the keys, converts them to big ints and does
     extraction/generation of shared keys;
   - Performs the BTWOC function as specified by the spec with optional
     Base64 encoding and decoding;
   - Creates HMAC signature files based from parameters received; and
   - Does all of this from one module that is pure Perl with very few
     module requirements.

What Crypt::OpenID is not however is simple.  This module is not a 
consumer/server implementation nor does it attempt to be.  Instead it 
provides the user with all of the tools necessary to build an 
implementation that works around their needs.

While I plan to include an example implementation that would guide users 
into the integration of Crypt::OpenID into their systems it would not be 
drop in.  However, it does allow them to have a starting base and 
integrate into systems that have database back-ends, their own deeply 
rooted authentication system to work against and so forth.

My site for example, had a lot of workarounds that other modules did not 
necessarily make easy to work with.   I also had a preference for 
putting associations, identifiers and other information into the 
pre-existing database.   There was also a desire to make use of the 
Simple Registration Extension 1.0 and no module seemed to make that 
aspect easy to work with.

So based on the above, would such a module be a welcomed addition?  Or 
should I just keep it as part of my sites code?

	Martin Foster
	Creator/Designer Ethereal Realms
	martin at ethereal-realms.org