The project will be divided into the following modules:

1. Web-facing code that handles the OpenID protocol: accept request from remote site for authentication, hand off actual verification to a backend module, and if verified, contact remote site to indicate verification, then forward user back to remote site. The OpenID spec at OpenID.net explains this in better detail. An existing OpenID implementation may be used and is recommended. Apart from OpenID, this module should may support challenge-response authentication if, for whatever reason, the remote site already has collected a password or cannot use OpenID. (Kushal Das and I have an existing implementation of challenge-response in Python with CGI that we can contribute.)

   This module should be capable of working over CGI, FastCGI, or with an internal web server. If implemented in Python (recommended), WSGI should be used, with preferably the Twisted web server.

2. Database backend modules, all with a common API, talk to any of MySQL, PostgreSQL and LDAP server to retrieve user details. Note that this API only handles retrieval. It does not handle either password verification or user interaction. This module will require configuration by the server administrator on database, table and column details.

3. Password encryption module deals with backend passwords stored as plain text, SSHA (SHA-1 with salt) or MD5 (recommended reading: RFC 2307 section 5.3 on the userPassword attribute). The implementer is advised to watch out for complications when using SSHA (the recommended storage format) with challenge-response. This module only handles password encryption and comparison between two samples (one from user, one from storage). It does not handle storage or user interaction. Note that there may be more than one password string for the same user, arising from the use of mixed authentication mechanisms such as password and biometric (up to 10 fingerprints, facial scan), so this module essentially deals with (a) authentication key type, (b) subtype, and (c) data string. For example, if (a) is “password” and (b) is “plain text”, then (c) may be handled by simple string comparison.

4. Authentication module API, by far the most complicated, handles interaction between the user and database backend using a variety of means. The most straightforward is a web-based interface, wherein the OpenID enabled site presents a login and password dialog, with a confirmation checkbox that the user wants to pass their credentials to the remote site. A slightly more advanced implementation would use cookies or session variables to record the user’s login, thereby avoiding asking for the password again.

   Our ultimate goal, however, is to make authentication seamless with the desktop interface metaphor, using one of two more advanced Authentication API modules (both out of scope of this proposal). With one, the auth request is handled over XMPP (Jabber). To illustrate: user goes to a certain website and attempts to login with her OpenID. The website contacts her OpenID site and asks for verification. The OpenID site does not present a login screen. Instead, it sends a message over XMPP asking if he wants to login to the given site. If the user is logged into XMPP, thereby confirming her identity, she sees the request and types “yes” in return. This confirms her identity to the remote website.

   The second advanced implementation uses a dedicated desktop client that hides in the dock/tray when not in use. It uses XMPP to maintain a listening channel to the server (separate from the user’s IM client) and when it sees a request, pops up a dialog asking for simple confirmation, password plus confirmation, or biometric authentication (fingerprint, otherwise). This method produces the cleanest user interface, without resorting to kludges like ActiveX for access to biometric devices.

Details of implementation of the desktop client or of authentication over XMPP will be handled under a separate proposal to NRC-FOSS, based on progress with this project. It is estimated that this project will require one good Python programmer six weeks to implement.

While Python is the preferred language for the implementation, the team is free to work with any open source language. The final implementation must include extensive unit tests (Python: doctests preferred) for all functionality. The tests will be required to function outside of the implementation environment. The software must be usable on Linux or any other POSIX-compliant operating system. Preferred license is BSD/MIT; LGPL/GPL is also acceptable.