OpenID feature bugs

[Emmanuel MEIER]

Hello,

I worked on OpenID within QualiPSo project last year in spring.
But I did not used it as a simple website.
I used it within a servlet as an OpenID consumer... Below my explanations :

Considering OpenID philosophy, an OpenID client/consumer should be able 
to use an existing server avoiding the problem of installing your own.
Actually everyone should be able to authenticate itself using any 
existing OpenID client/consumer against any OpenID server.
But to allow communication between the consumer and the User-Agent, the 
OpenID specification use a negotiated secret.
This shared secret has to be encrypted (Diffie-Hellman-negotiated 
secret). It's only used in the associate mode.
But some OpenID server does not support the same version of the 
encryption algorithm.
It was a major blocking issue as an OpenID client would be unable to 
authenticate against some OpenID server.
Each OpenID server actually provide an openID client (consumer) that 
would accept the communication mode of its server.
For example, a consumer of “joid” (Java Open Id) did not run with 
clamshell (as OpenID provider).

In addition to this, when the user is not already authenticated, the 
response of the OpenID provider is not normalized .
It consist of a HTML page where a XML (machine readable) response would 
be appreciated.
As the user could use any openID server, it is impossible to handle the 
many possibilities.
Furthermore, an automated system using XML communication and OpenID to 
authenticate users transparently
with no user interaction is out of question (technical web service 
providing for example).

As a result, I submit the following request for features:
- standardisation of the version of the encryption algorythm for the 
negotiated secret;
- the possibility to have a normalized XML response for unauthenticated 
users.

Regards,
Emmanuel Meier.