Since "client" is to be understood as "client software" (not human), I 
think we could give the client the obligation to log out.
In view of increasing complexity, I also tend to put the burden of 
obtaining a token (which is actually not so much) on the client.
That way, existing services would have to add a field "subjectid" (which 
I propose to name the token field) and hook calling routines to the 
OpenSSO service into the workflow at the appropriate places (before the 
actual service calls).

Regards
Andreas

Luchesar V. ILIEV wrote on 06/17/2010 06:07 PM:
> Let's decide who will handle the authentication process:
>
> 1. The service.
> OR
> 2. The client/user.
>
> (1) means that an OT service will expect only a valid OpenSSO token
> with each request. It will be up to the user to acquire such token:
> whether by directly communication with the OpenSSO server or via some
> client application.
>
> (2) means that an OT service will expect username and password
> provided with each request. It will then try to get a valid token from
> OpenSSO, and if that fails, will have to report back to the user.
> Obviously, this relieves the client applications from the burden of
> authentication, but at the expense of increased service complexity.
> Furthermore, the services still have to be able to parse requests
> accompanied by a token (as opposed to username/password), because
> that's how cascading requests (from one service to another on behalf
> of a user) work.
>
> Please keep in mind as well that whoever does the authentication must
> also handle log-out.
>
> Cheers,
> Luchesar
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>

-- 
http://www.maunz.de

             According to my calculations the problem doesn't exist.