Re: OpenID + auto-login, was: Re: [foaf-dev] Re: RDFAuth: an initial sketch

On 1 Apr 2008, at 12:33, Benjamin Nowack wrote:
> So, here is a new proposal that I personally think makes more sense
> than inventing a whole new protocol:
>
> We write/tweak
>
> OpenID consumers so that they
> * send headers to advertize their OpenID support
> * follow an agreed-on pattern WRT signing in or that
>   provide (possibly again via an HTTP header) a hint how to
>   initiate the redirect
> * standardize the session instantiation/re-detection (e.g. an
>   agreed-on cookie name) after a successful login
>
> and OpenID Servers that
> * have a standardized and simplified login and redirect-back
>   mechanism

I think the idea of allowing connections via OpenId is a feasible one,  
though clearly a hack on a hack. But why not? This would be a good way  
to show why something like the RDFAuth_Sketch spec [1] is also needed.

So using OpenId will require the client (in Knowee's case the server)  
to know the OpenId username and password, and be entitled to  
automatically fill it in. (I wonder why/how that is more secure than  
having access to a private key?)

It will require us to develop a simple RDF vocabulary so that public  
foaf files can say things like "for more info log in here with your  
openid".

<protected> openid:login <login> .
<login> cookie:name "cookie".


then the client will be able to capture and replay the two redirects  
as a normal web browser would:
    - from the server via the client to the Identity Provider (IdP)
    - from the IdP via the client to the openid login service <login>
then the extra verification from the <login> to the IDP


so the number of connections we have are like this:
   1. client GETs public foaf file
   2. client finds protected resource and requirement to login via  
openid for more info
   3. client sends form with info to <login endpoint> (over SSL)
      and gets a redirect to the IdP endpoint
   4. client sends redirected request to IdP endpoint and received a  
form for username/password (over SSL)
   5. client fills in user name password and send to IdP and gets  
redirected to <login> (over SSL)
   6. client redirects to login  (over SSL)
   6.1 server sends verification request to IdP which returns IdP ok  
response (over SSL?)
   6.2 server sends cookie to client
   7. with session cookie client now asks for the requested resource

There are a lot of TCP requests, 8 to be precise, most of which are  
over SSL, which is a complex protocol, itself involving a lot of  
encryption handshakes. The RDFAuth_sketch [1]  may need only 3 (with  
only one over SSL) and after caching may only need 1 SSL connection  
(no need to fetch the public key or the foaf file again).

In order to reduce the need for clients to make unnecessary  
connections, it would help to have an RDF vocabulary to describe who  
can log into protected resources, so that clients could make some  
estimate of whether they should bother following a link.

 From what is described here, this requires servers to know OpenId,  
and to put this information in their RDF files. Is that all?
Clearly servers that later implement and RDFAuth_Sketch protocol will  
be much faster to interact with.

Henry


[1] http://blogs.sun.com/bblfish/entry/rdfauth_sketch_of_a_buzzword