As an alternative to ASDF-Install, a CL-Librarian shelf definition for dependencies is provided. To use it, run following shell commands in CL-OpenID directory:

darcs get http://www.pasternacki.net/repos/cl-librarian/ lib
cd lib
sh bootstrap.sh
cd ..

Then start your favourite Lisp implementation and call:

(load "shelf")
(cl-librarian:download-shelf 'cl-openid.deps) ; for the first time or when new dependency is added
(cl-librarian:use-shelf 'cl-openid.deps) ; when libraries are already downloaded
(asdf:oos 'asdf:load-op :cl-openid)
(asdf:oos 'asdf:test-op :cl-openid) ; run 5am unit tests

Relying Party class.

Name of HTTP GET parameter, sent in return_to URI, which contains AUTH-PROCESS object unique handle.

Initiate authentication process by relying-party for identifier given-id received from user.

If immediate-p is true, initiates immediate authentication process.

The extra-parameters is an optional key-value list to be added to the authentication request message. The list format is the same as for the MAKE-MESSAGE function. This parameter is needed for OpenID extensions, for example OAuth or Attribute Exchange.

Returns multiple values:

• the URI to redirect the user's browser to;
• Unique handle (string) identifying the started authentication process;
• the AUTH-PROCESS structure identified by the handle.

The latter two values are useful if the client code needs to track the process.

Handle indirect response message for relying-party, coming at request-uri, concerning authproc.

authproc can be a literal AUTH-PROCESS object, or a string (unique authproc handle, sent earlier by Relying Party). When authproc is NIL or not supplied, its handle is taken from message field named +AUTHPROC-HANDLE-PARAMETER+.

Returns claimed ID URI on success, NIL on failure. As second value, always returns AUTH-PROCESS object.

Error signaled by Relying Party when indirect response cannot be verified correctly.

Data structure gathering information about an ongoing authentication process.

OpenID Provider server abstract class.

This class should be subclassed, and specialized methods should be provided at least for HANDLE-CHECKID-SETUP (preferably also for HANDLE-CHECKID-IMMEDIATE).

HTTP code recommented to use for indirect responses sent via HTTP redirect.

Handle request message for OpenID Provider instance op.

secure-p should be passed by caller to indicate whether it is secure to use unencrypted association method.

allow-unencrypted-association-p specifies whether it is allowable to use unencrypted association method. Set it to NIL unless your OP endopoint uses HTTPS. See OpenID Authentication 2.0 - Final, section 8.4.1. No-Encryption Association Sessions (http://openid.net/specs/openid-authentication-2\_0.html#assoc\_sess\_types).

Returns two values: first is body, and second is HTTP code.

On HTTP redirections (the second value between 300 and 399 inclusive), the primary returned value will be an URI to redirect the user to.

Returns the URI of the Relying Party to redirect the user's browser to. The URI parameters tell the Relying Party that the authentication failed. auth-request-message should be the oritinal OpenID authentication request message that was received from the Relying Party previously and passed to the HANDLE-CHECKID-SETUP.

Returns the URI of the Relying Party to redirect the user's browser to. The URI parameters tell the Relying Party that the authentication was successful. auth-request-message should be the oritinal OpenID authentication request message that was received from the Relying Party previously and passed to the HANDLE-CHECKID-SETUP.

Handle checkid_immediate requests.

This generic should be specialized on concrete Provider classes to perform immediate login checks on MESSAGE. It should return at once, either true value (to indicate successful login), or NIL (to indicate immediate login failure).

Default method always fails.

Handles checkid_setup requests.

This generic should be specialized on concrete Provider classes to perform login checks with user dialogue, that would (possibly after some HTTP request-response cycles) end by redirecting the user's browser either to SUCCESSFUL-RESPONSE-URI, or to CANCEL-RESPONSE-URI.

This generic is called by HANDLE-OPENID-PROVIDER-REQUEST, and the values returned by this function are then returned by HANDLE-OPENID-PROVIDER-REQUEST. I.e. it must return two values: response \"body\" and HTTP status code. That way HANDLE-CHECKID-SETUP can either redirect user's browser somewhere, or just show him something. (With hunchentoot, HUNCHNTOOT:REDIRECT may also be used, which is a non-local transfer control).

Default method just returns (VALUES (CANSEL-RESPONSE-URI …) +INDIRECT-RESPONSE-CODE+).

Messages passed between OpenID Provider and the Relying Party are composed of key-value pairs. Natural Lisp representation of those, and the one used in CL-OpenID, is an association list. A handful of conveniense function is provided to avoid tweaking messages on cons level.