[cl-openid-devel] What happens after verification?

[Maciek Pasternacki]

On Sat, 2008-07-19 at 16:11 +0200, Leslie P. Polzer wrote:
> Suppose I'm a relying party and send a HANDLE-OPENID-REQUEST
> to the appropriate provider. This function returns an URI
> which I'm going to redirect the user to.

The URI contains "openid.return_to" address, referring to the Relying
Party endpoint URI (or to what the HANDLE-OPENID-REQUEST thinks it is).

> The user authenticates himself.
> 
> What happens then?

User is redirected to the return_to address, which contains the key
that maps to the specific login process -- it's an indirect reply.  The
assertion received via the reply is examined (by the very same
HANDLE-OPENID-REQUEST function called by Hunchentoot handler), and --
currently -- only HTML describing the status is returned.

> I know that I can specify a return URI (which possibly contains
> some secret key that maps to the login process), but isn't
> CL-OPENID supposed to take care of this?

Remember it is just a working prototype, the proof of concept, not an
actually usable library.  Yes, CL-OpenID will take care of this.
Functions for registering the handler will -- most probably -- take a
callback argument that will receive authentication status as an
argument.  It will be able to set authorisation cookies, display actual
error message specific for the service, redirect user to his dashboard,
and so on.

Please, don't look at current state of project as anything fixed.  I am
working bottom up: from internally functional proof of concept up to
actual API.  The RP is still a proof of concept.  It will undergo major
refactoring that will aim to provide an actual API (it will be CLOS
oriented, I have some initial ideas already).  However, before the
refactoring, I wish to do also a proof of concept OP, to have good grasp
on the common part of functionality (coding/decoding messages,
associations etc).

Regards,
Maciej.

-- 
-><- Maciej 'japhy' Pasternacki -><- http://www.pasternacki.net/ -><-