[foaf-dev] 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
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
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
Oh, and let's please stop calling anything "RDFAuth", for the reasons
that danbri mentioned, and because I think I just dropped the idea.