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

On 31.03.2008 17:10:42, Dan Brickley wrote:
>It will be hard to recruit the right security expertise without getting 
>a characterisation of the problem space (and the constraints we have, 
>and the technical opportunities) that is clearly separated from 
>candidate technical solutions.
Oh, right. And after re-thinking things a bit, it may well be that we're
throwing the wrong technology at the problem. Maybe even at the wrong 
problem.. ;)

We're clearly beyond a "rough consensus" state and waste time on 
discussing details of a potential spec, while the *actual* problem we'd
like to explore is RDF/SPARQL/Rule-based serving of content. Do we
need a spec for that serving aspect? Probably not. There are a number 
of ideas on the table (like Danbri's thoughts on modeling/identifying 
group memberships using SPARQL queries). So, what holds us back from
implementing these ideas?

Do we really need an equivalent/alternative to OAuth? I tend to
say No, because it's optimized for a different use case. 

OAuth's core use case:
   * user U has multiple accounts at services S1 and S2
   * S1 (on behalf of U) should be able to access data on S2,
     following rules defined by U on S2 ("S1 may access my photos")

Our core use case (or mine, at least) differs:
   * user U1 has an account at service S1, user U2 has an account
     at service S2.
   * S1 (on behalf of U1) tries to access data on S2,
     following rules defined by *U2* ("my friends can see my photos")

For simple, running code, we don't need a content exchange mechanism,
because we can use straight HTTP(S). We also don't need a content 
encoding mechanism, because we have RDF formats. And we don't need
a standard content/functionality selection mechanism, because 
"my friends can see my photos" can be defined locally on the resource
server, via SPARQL or whatever. (It may make sense to model AC in RDF,
but for now we don't really need it.)

OK, when we don't need OAuth (yet), what do we need then? 
We need a way to identify U1 on S2. Nothing more (once we know who is
requesting data, we can fire our internal, RDF-based authorization 
scripts), nothing less (the requesting app has to identify its user). 

OpenID? OpenID!
The obvious technology option here is OpenID. Now, why do we think 
OpenID doesn't work? Because it's optimized for humans using a web 
browser. The usual OpenID consumer (e.g. at S2) doesn't send headers
that allow S1 to detect the availability of an OpenID sign-in. 
(That's something TimBL mentioned a while back in the context of 
Tabulator[1]. You'd have to scrape a page to know how to send in an 
OpenID before you can initiate the redirect dance.) Likewise, OpenID
does not pre-define/standardize how logging into an Identity Provider
should happen, i.e. even if S1 was able to catch the redirect URL
from S2, it would still have to log into the IdP. Also, there's
usually some sReg (simple registration) stuff going on that users 
have to confirm before the IdP redirects S1 to S2. 
However: There is code for both OpenID Server and Consumer 
implementations freely available for all sorts of environments. 
Almost a year passed since we mapped up the token-based RDFAuth 
idea for knowee, things have changed a lot: Writing a basic OpenID 
consumer is really not that hard (the one I wrote for my framework 
has 160 LOC). 

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


OpenID is a distributed technology. As long as our OpenID
endpoints support the OpenID spec, it can happily participate
in the growing OpenID party. IOW, we are solving several problems
at once:
 * we don't have to worry about the security stuff, the OpenID
   folks did that already
 * any of our OpenID-enabled sites can be accessed by web browsers,
   in-browser apps like Tabulator, and also by remote services or
   desktop apps. The extended funtionality is transparent, it *can*
   be used, but it can also simply be ignored.
 * we actively support a technology that deserves to be endorsed,
   instead of competing with it

   
Ok, trying to fill in danbri's form:

>   1. What is the problem, why is it hard?
Distributed user identification on the Web. It's hard because
we need a standardized mechanism to log into sites that may
not have a username/password for requesting clients.

    2. How is it solved today?
OpenID: Personal identifiers are -together with pointers to 
Identity Providers- encoded into web pages. The "Prove you
are Alec Tronnick" is transformed/simplified into "Prove that
you have write privileges on alectronnick.com/me"

>   3. What is the new technical idea; why can we succeed now?
Standardize the interaction with OpenID-accepting and -verifying
services so that the login/verification process can be automated
by (Semantic) Web clients.

We can succeed because we don't have to dig too deeply into the
security stuff, don't need an OK from external groups, and don't 
need to change existing specs or other people's infrastructure. 
Instead, we can offer an upgrade path ("Hey, if you used an IdP
that supports the "auto-login" extension, you could grab this 
funky widget data using server-side scripts"). As long as we play 
nicely with the OpenID spec, we can both benefit from and support
OpenID's current deployment success.

>   4. What is the impact if successful?
It could help spread OpenID in the RDF community even more. The 
RDF community can focus on the (more interesting) RDF/SPARQL-driven
access control possibilities. We might be able to contribute our 
solution back to OpenID implementors and the dataportability 
effort (restricted access to FOAF profiles, RDF dumps, SPARQL 
endpoints, widgets etc. made easy)

>   5. How will the program be organized?
 * We identify and spec out the headers needed for our use case
 * We hack some of the existing open source implementations
 * we install a demo IdP and a number of demo consumers
 * We tweak our personal homepages/profiles to point at the
   server-friendly IdP
 * We define some simple rules on the services behind the demo
   consumers
 * We try resource access via a browser
 * We try resource access via a remote script or desktop app
 * we improve our access rules (but that's another program then)

>   6. How will intermediate results be generated?
>   7. How will you measure progress?
See 5. above. We can check if/how things work after each milestone.

>   8. What will it cost?
A couple of person days to set up an enhanced IdP, hosting costs 
for the IdP, a person week or so for the consumers and demo 
functionality.



I'm not sure, but couldn't this be something that even we 
consensus-resistent RDFers could find an agreement on? ;)

Cheers,
Benji

[1] http://arc.semsol.org/community/irc/logs/2008/01/04#T14:49:03Z


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



>cheers,
>
>Dan
>
>--
>http://danbri.org/
>
>
>_______________________________________________
>foaf-dev mailing list
>foaf-dev@lists.foaf-project.org
>http://lists.foaf-project.org/mailman/listinfo/foaf-dev
>

Received on Tuesday, 1 April 2008 10:33:52 UTC