- From: Benjamin Nowack <bnowack@semsol.com>
- Date: Tue, 1 Apr 2008 12:33:16 +0200
- To: Semantic Web <semantic-web@w3.org>
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