Re: OpenID + auto-login

On 01.04.2008 19:23:27, Story Henry wrote:
>
>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".
rdfs:seeAlso should be just fine for now, the client app will notice
if a resource is protected, and a site that supports the OpenID extension
to protect it's resources can easily send an HTTP header to indicate 
"more content after login", or point at its login endpoint (but even 
that may not be necessary, see below)

>so the number of connections we have are like this:
[...]

It's a little different. We have access to the openid consumer code and
also to the IdP code, so we can implement things like this (I'm using 
"autoID" as a shortcut for "OpenID + auto-login"):

r1.   the [client app] requests a resource from the [server] and sends
      an autoID header for (possibly protected information)
r1.b  the [server] serves content in case of non-protected resources, 
      or, in case of a protected resource:
r2.   it auto-discovers the IdP via a GET on the OpenID, which is provided
      by the autoID header(s). (The [server] may already have RDF information
      about the requesting app's user, then it can re-use that.)
r1.b  The [server] sends a redirect-to-IdP header to the [client app]
r3.   the [client app] logs into its [IdP] (this needs only to be done
      once a day/week/IdP session lifetime, btw, and only if the [client
      app] is not an IdP itself)
r4.   the [client app] requests the redirect-URL from the IdP (if
      the [client app] is not the IdP as well)
r4.b  The IdP returns the target URL
r5.   The [client app] requests the target URL from the [resource server]
r6.   The [resource server] validates things against the IdP
r5.b  The [resource server] returns the protected content and a session 
      cookie

So, that's 7 request worst-case (the client app didn't send an autoID
header in the first place), 6 requests if the client app is not logged
into it's (remote) IdP, 4 requests when the client app acts as the IdP,
and 3 requests, if the server knows the IdP URL of a given OpenID.

But counting HTTP requests (even if it's 7) is not really the way to 
decide on this, but whether an approach can be successfully implemented 
and deployed (try counting the # of requests in OAuth, and yet will it 
become the standard in Web 2.0 land. My browser needs 50+ requests when
I'm visiting a widget-filled web page). OpenID + auto-login can be 
implemented w/o the need for security experts, by riding the widely 
successful OpenID wave, and w/o much upfront spec discussion (well, 
maybe not if we continue like this..).

>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.
That's premature optimization, I think.

> From what is described here, this requires servers to know OpenId,  
>and to put this information in their RDF files. Is that all?
Servers are compliant OpenID Consumers that also support auto-login
as described above. They send a pre-defined header for protected URLs.

>Clearly servers that later implement and RDFAuth_Sketch protocol will  
>be much faster to interact with.
Again, premature optimization. They will indeed be much faster on the
web because most servers will just say "I don't support PGP".

I'll try to drop out of this discussion here and better try to 
implement a prototype first (not before mid-april, though, as I'm
buried in other work). Things will be easier to explain when there's
running code. 

Oh, and let's please stop calling anything "RDFAuth", for the reasons
that danbri mentioned, and because I think I just dropped the idea. 

Best,
Benji

--
Benjamin Nowack
http://bnode.org/

Received on Tuesday, 1 April 2008 19:43:23 UTC