I was thinking specifically about browsers authenticating to a Restlet-based Web site (so that would mean a little code for doing the necessary redirects, cookie settings, and response interrogation -- probably plugging in the sxip library).
But now that you mention it, it would be really neat if we could work with the OpenID community to find a way to implement the *client* side of the protocol in Restlet (and other REST client libraries). As far as I know, the only major missing piece is exposure of a standardized authentication mechanism by the provider. Correct me if I'm wrong ... but I think that there is intentionally no standard whatsoever for how the provider authenticates you -- except that there is a URI where humans using browsers are sent to be authenticated. So there isn't a way to standardize submission of credentials. If there were a convention for exposing an HTTP Basic over SSL authentication URI at the provider (or a form with standard parameters, or any other convention), the client library could take care of all the mechanics of the protocol. While in concept, it is neat that OpenID providers could authenticate you by certificates, biometrics, facial recognition, or smell, in practice they generally employ userid and password pairs and therefore offer nothing stopping one from mapping that to HTTP Basic on a resource whose URI is advertised. I'm just thinking out loud ... but most likely I am not the first one to go down this road and there may be a body of opinion or work on this topic already, or what I'm describing may already exist in some form ... I will do some more research. On 1/3/08, Stian Soiland <[EMAIL PROTECTED]> wrote: > > Just a note, although OpenID should work good for a user with a > browser, it will not currently work good for any REST clients, as it > is based on cookies and javascript. > >
